14:00:26 <stickster> #startmeeting Workstation WG
14:00:26 <zodbot> Meeting started Wed Mar 30 14:00:26 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:26 <zodbot> The meeting name has been set to 'workstation_wg'
14:00:29 <stickster> #meetingname workstation
14:00:29 <zodbot> The meeting name has been set to 'workstation'
14:00:31 <stickster> #topic Roll call
14:00:34 <stickster> .hello pfrields
14:00:35 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:01:20 <mclasen___> .hello mclasen___
14:01:21 <zodbot> mclasen___: Sorry, but you don't exist
14:01:26 <mclasen___> bummer
14:01:32 <mclasen___> .hello mclasen
14:01:36 <zodbot> mclasen___: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:02:06 * otaylor is here
14:03:15 <ueno> hi
14:04:19 <otaylor> Hi ueno!
14:04:25 <stickster> #chair mclasen___ otaylor
14:04:25 <zodbot> Current chairs: mclasen___ otaylor stickster
14:04:43 <stickster> hi ueno!
14:04:56 <ryanlerch> .hello ryanlerch
14:04:57 <zodbot> ryanlerch: ryanlerch 'ryan lerch' <rlerch@redhat.com>
14:05:30 <stickster> #chair ryanlerch
14:05:30 <zodbot> Current chairs: mclasen___ otaylor ryanlerch stickster
14:05:42 <stickster> Heya Ryan! Thanks for being here during late hours
14:05:45 <mclasen___> ryanlerch: hey, good to see you
14:05:53 <ryanlerch> heya mclasen___ !
14:06:02 <ryanlerch> heya stickster!
14:06:12 * stickster notes we are missing quorum but this meeting is largely for discussion/strategy and not so much "decide yes/no to do <X>"
14:06:38 * mclasen___ is trying to get hold of various laggards
14:06:44 <stickster> #topic ostree based Workstation
14:07:14 <mclasen___> the relevant link is https://fedoraproject.org/wiki/Changes/WorkstationOstree
14:07:23 <mclasen___> if you hadn't seen it yet
14:07:26 <stickster> #link https://fedoraproject.org/wiki/Changes/WorkstationOstree
14:08:04 <mclasen___> I've made some edits to that page since the last meeting, to reflect things I've learned since then
14:08:26 <mclasen___> in particular in the scope section
14:08:51 <mclasen___> I think it is fair to characterize this as a stretch goal for f25; there's many things that are still up in the air
14:09:00 * stickster admits right up front, the thing that would help him most is having someone either demo or explain in a doc how xdg-apps work... I'm familiar with rpm-ostree to some extent after other demos and even trying it out in a VM
14:09:33 <stickster> mclasen___: I agree about this as a stretch goal, because in particular the rel-eng work isn't well scoped here, and AIUI they have a very full plate already for F25
14:10:01 * stickster also remembers to ping mattdm that this meeting is happening in case he wishes to lurk
14:10:21 <mclasen___> to some extent, this is riding on the coattails of project atomic - we will be able to benefit from rel-eng work for atomic
14:10:42 <mclasen___> but yes, that will likely be a bottleneck
14:10:54 <stickster> certainly for the rpm-ostree part... what I'm not certain about yet is tooling for xdg-apps
14:11:14 <stickster> But first thing's first
14:11:38 <stickster> mclasen___: Someone
14:11:40 <stickster> argh
14:12:00 <ryanlerch> mclasen___: for an end-user though, would there be much of a visible change between "traditional" and os-tree based?
14:12:12 <otaylor> stickster: You might want to look at http://hughsie.github.io/xdg-app-ng-website/ - it's Richard Hughes's attempt to make a nice slick website for the project
14:12:18 <ryanlerch> other than gaining features like rolling back after a release...
14:12:55 <otaylor> ryanlerch: I think it depends on what you mean by "end-user"
14:13:42 <otaylor> ryanlerch: for someone who is not installing software or dropping down to the command line, it looks identical
14:14:03 <otaylor> ryanlerch: for someone who is installing apps through gnome-software it looks pretty much identical (except for the set of available apps)
14:14:16 <mclasen___> ryanlerch: the visible changes are mostly in the way you install and update software
14:14:46 <mclasen___> we've somewhat anticipated the changes in the gnome-software ui - the atomic update for the os as one blob
14:14:46 <otaylor> ryanlerch: but if you are used to dnf installing random packages - it looks entirely different (and probably worse if this is how you mainly use fedora)
14:14:57 <cschalle> sorry to be late
14:15:06 <mclasen___> and separate app updates - with xdg-app we'll go back to allowing online updates, I think
14:15:06 <stickster> #chair cschalle
14:15:06 <zodbot> Current chairs: cschalle mclasen___ otaylor ryanlerch stickster
14:15:19 <ryanlerch> ah ok, so a developer that say, wanted to install a particular library "package" for development on their system, it will be a big conceptual change?
14:15:55 <stickster> ryanlerch: ^ better formulation than "random" :-)
14:16:22 <otaylor> ryanlerch: yes, it's a big change... basically the idea is that developers should work in isolated environments specific to their project and not mutate the OS
14:16:26 <stickster> For instance, I want to hack on Pagure. To do that I might need to install a set of packages peculiar to that project.
14:16:45 <stickster> But -- the alternative is to use python-virtualenv in which case IIUC all the requirements end up in my $HOME
14:17:04 <stickster> which is more "upstreamy"
14:17:10 <mclasen___> one premise here is that you shouldn't do development by installing stuff on your system, but instead embrace vagrant and other vm or container-based approaches
14:17:35 <stickster> mclasen___: Although doesn't that offload some work onto a principal project developer?
14:18:01 <stickster> "If you want developers to use Fedora to work on your project, you also need to set up a container for your project, not just the standardtree in github"
14:18:50 <otaylor> stickster: I think it's reasonably normal for develoepers to provide a vagrantfile with their project
14:18:57 <mclasen___> it is closer to the way developers work on other platforms, I believe; at least that is the approach that the cdk takes
14:19:11 <otaylor> stickster: probably more normal than providing a list of fedora packages to be installed
14:19:45 <otaylor> for python stuff, it's probably most normal to document setting up a virtualenv and pip installing into it
14:19:46 <ryanlerch> mclasen___: excuse my ignorance, cdk?
14:19:52 <mclasen___> in any case, I don't think we'll have this part of the story necessarily fully fleshed out for f25 - there's a lot of groundwork to be done first
14:20:11 <stickster> ryanlerch: Container Development Kit, but is that a Red Hat product thing?
14:20:24 <mclasen___> yes
14:20:32 <ryanlerch> thanks stickster, mclasen___
14:20:54 <stickster> otaylor: Python is one of the few areas I have any experience doing myself
14:21:13 <stickster> otaylor: So you guys are thinking about venv as among the vagrant/container-like use cases?
14:21:50 <otaylor> stickster: yeah. It's listed in https://fedoraproject.org/wiki/Workstation/AtomicWorkstation actualyl specifically
14:21:57 * stickster shuts up about the Python rathole after this :-)
14:22:10 <otaylor> But I think we've been talking about more vm/container solutions because they are more general
14:22:55 <stickster> otaylor: gotcha. I'm interested to know that e.g. Fedora Engineering team members could make use of this new Fedora Worsktation in their day-to-day
14:23:08 <stickster> sounds like +1
14:23:29 <otaylor> OsTree is *a way* of installing Fedora Workstation - in the short term it's definitely not *the way* - it's going to take a while to sort out everything that an abitrary existing Fedora user might want to do
14:24:28 <stickster> Right, one important thing to note is that F25 != only a new Workstation
14:25:39 <otaylor> stickster: Don't quite understand - Are you asking about OsTree for other variants?
14:25:45 <ryanlerch> otaylor: so, OStree doenst use packages at all, right? Does this mean that all the "end user applications", weather they be a CLI end user app or a GUI app needs to be "repackaged" for use in an OStree based system?
14:25:45 <stickster> #info The new ostree model Workstation will be an additive product at first and isn't expected to replace the existing Workstation right away; will need "field" data to see where we need to make changes or enhancements for use cases
14:25:49 <stickster> otaylor: ^
14:26:15 <stickster> let me know if we're not saying the same thing and I'll undo that
14:26:26 <otaylor> stickster: That sounds right
14:26:30 <stickster> coolio
14:26:40 * hughsie also wants to keep the support matrix as small as possible; supporting gnome-software-on-packagekit-on-librpm is totally different to gnome-software-on-xdg-app-on-ostree
14:26:56 <stickster> o/ hughsie!
14:27:07 * hughsie was summoned :)
14:27:21 <cschalle> well we are still using rpms to compose the OS tree build afaik? rpm-ostree?
14:27:42 <otaylor> ryanlerch: THere is no rpm installation on the end-users system
14:28:20 <hughsie> cschalle, sure, it's the same inputs, just very different ways of managing changes
14:28:27 <otaylor> (walters has plans to enable layering packages on top of rpm-ostree, but I think it doesn't really fit in with a no-sysadmin vision very well. It adds sysadmin back)
14:28:31 <mclasen___> ryanlerch: the answer is a bit different for the os image and xdg-apps
14:28:40 <mclasen___> the os image can just be populated by straight fedora rpms
14:28:46 <stickster> #info We need to be careful about support combinatorics, i.e. not making support matrix unwieldy by too many variations of underlying tech (PK/xdg-app; librpm/ostree; others)
14:28:51 <mclasen___> for xdg-apps, we need at least relocatable rpms
14:28:57 <hughsie> stickster, +!
14:29:01 <hughsie> +1 even
14:29:16 <stickster> I figure QA would say bravo too
14:29:27 <hughsie> stickster, for instance upgrading a live workstation to an atomic workstation is going to be hard
14:29:38 <hughsie> and vice versa of course
14:29:57 <otaylor> ryanlerch: GUI applications are installed by packages. Command line applications - we have no current plans to provide installation other than in a container/vm.
14:30:24 <stickster> hughsie: Although we may want a story for doing that so people can keep $HOME while doing so
14:30:36 <stickster> even if it's "install around /home"
14:30:47 <hughsie> stickster, story = "testing and QA" :)
14:30:47 <ryanlerch> otaylor: so if i wanted to run vim, i would have to run that in a seperate container?
14:31:08 <hughsie> otaylor, why not vim as an xdg-app?
14:31:08 <mclasen___> hughsie: stickster: I don't see us supporting that, other than backup/restore
14:31:11 <otaylor> ryanlerch: Probably - TBD
14:31:45 <otaylor> ryanlerch: It's certainly possible to have command line apps as unsandboxed xdg-apps with a little extra glue to get them to appear on the path
14:31:49 <hughsie> i mean, nobody said it has to be GUI apps only
14:32:01 <hughsie> and stuff like powertop won't like be run in a container or vm
14:32:03 <stickster> mclasen___: Ouch, with > 200 GB /home partitions out there that could be a disincentive
14:32:04 <cschalle> hughsie, I guess that is doable, but it would require us to design the portals to also work in command line mode
14:32:36 <hughsie> cschalle, or just say all command line stuff is unrestricted and unsndboxed?
14:32:37 <otaylor> ryanlerch: But there's some danger of breakingthe xdg-app story if we go off too far in that direction
14:32:52 <ryanlerch> cschalle: portals?
14:33:22 <cschalle> ryanlerch, portals are the method of which a sandboxed application gets access to stuff outside its sandbox, ie files in your Documents folder
14:33:36 <ryanlerch> cschalle: thanks :)
14:33:47 <stickster> otaylor: can you explain that last statement?
14:34:48 <otaylor> stickster: WHat I mean is that we are trying to be very clear that xdg-app is not a general container solution. It's for GUI applications launched from a desktop file via your app shell, that interact with the user through the windowing system and talk to the rest of the system via D-Bus portals
14:34:56 <cschalle> hughsie, but part of the 'story' here is supposed to be that library bundling is ok due to sandboxing mitigating the security concerns, if we switch to saying unsandboxed in the long term story for command line apps I guess we undermine that message
14:35:07 <stickster> otaylor: Ah, I understand. Thanks.
14:35:10 <hughsie> cschalle, true
14:35:11 <mclasen___> stickster: if it is a separate partition, you should be able to install over your traditional fedora install with an ostree one, I think
14:35:16 <alexlarsson> cschalle: well, a sandboxed vim is not very useful
14:35:23 <stickster> mclasen___: That's all I was hoping for :-)
14:35:30 <alexlarsson> cschalle: as in, you would not be able to open your files to edit them
14:35:31 <mclasen___> once we have an installer that can install the ostree variant, anyway
14:35:33 <hughsie> mclasen___, correct
14:35:39 <stickster> mclasen___: I don't think there's a clean solution without separate /home... just hoping we could at least make that work :-)
14:35:40 <cschalle> alexlarsson, agreed, which is why I mentioned needing command line portals to make that viable
14:35:43 <otaylor> stickster: Once we say "but also it's for running command line applications" then we have to be clear where the line is when someone asks "and what about httpd"?
14:36:00 <alexlarsson> cschalle: yeah, but portals are typically UIs...
14:36:09 <cschalle> alexlarsson, that was my comment exactly ;)
14:36:12 <otaylor> cschalle: In general portals imply application modification, and I think the main interest for command line tools would be existing tools
14:36:20 <alexlarsson> cschalle: i don't see how they could ever work on the terminal
14:36:58 <cschalle> alexlarsson, I don't have a clear idea either, which is why I leave it to you to figure these things out ;)
14:37:00 <stickster> otaylor: So one line might be anything designed to touch or be touched by a non-local resource/system
14:37:26 <alexlarsson> i would say
14:37:31 <alexlarsson> "anything interactive"
14:37:34 <stickster> i.e. vim's OK, but not httpd, and you should be using venv/vagrant for your web app
14:38:03 <alexlarsson> typically via X/Wayland, but possibly also via a terminal
14:38:29 <alexlarsson> Of course, none of the xdg-app desktop interaction as it now stands would work with the terminal
14:38:47 <alexlarsson> i.e. you can "xdg-app run org.vim.Editor the-file.txt"
14:38:53 <alexlarsson> but thats rather annoying
14:39:14 <mclasen___> alexlarsson: you'd need to have a way to export a pty slave instead of $DISPLAY
14:39:15 <alexlarsson> whereas the .desktop file integration makes it completely invisible to users of a graphical app
14:40:16 <ryanlerch> xdg-app runtimes are kept in ostree too right? is this a seperate ostree to what the workstation ostree will be?
14:40:19 <alexlarsson> actually its possible for the xdg-app to access its controlling terminal
14:40:33 <alexlarsson> ryanlerch: a different repo, yes
14:40:40 <alexlarsson> /var/lib/xdg-app/repo
14:41:01 <otaylor> ryanlerch: there are two repostories on the users system - on for the OS, and one for runtimes and apps
14:41:30 <otaylor> ryanlerch: then those point to remotes elsewhere
14:41:30 <stickster> otaylor: Is that restrictive or is it an arbitary number of repos for runtimes/apps?
14:41:57 <alexlarsson> Its actually two, one system wide, and one per-user
14:42:06 <alexlarsson> But there is no need for more than that
14:42:14 <alexlarsson> why would there be?
14:42:19 <otaylor> stickster: one repository locally, but can have multiple remotes. (Like you can have one rpm database with packages insetalled from multiple yum repositories)
14:42:19 <mclasen___> there's an dvantage to having fewer repositories, since we get transparent content sharing across all the things in the same repo
14:42:29 <stickster> gotcha
14:43:08 <otaylor> stickster: I'm guessing we'd have two repositories on the fedora infrastructure - one to host OS images, and one to host apps and runtimes
14:43:09 <mclasen___> installing the application checks out a revision from the repo to some other place on the file system
14:44:29 <alexlarsson> stickster: you don't need multiple repos to e.g. have multiple versions of an app/runtime (or different runtimes) installed in parallel
14:44:42 <stickster> alexlarsson: thanks, that's what I was looking for
14:44:53 <alexlarsson> If you don't know ostree well, think of it like git
14:44:58 <stickster> distinguishing between repos/remotes was the key
14:45:02 <alexlarsson> there is one local git repository
14:45:08 <alexlarsson> it has multiple remotes configured
14:45:21 <alexlarsson> and for each such remote it can mirror a set of branches
14:45:29 <alexlarsson> each such branch is an app (or remote)
14:45:40 <cschalle> just asked walters, his suggestion here is that package layering will mitigate some of the security issues around bundling when you are not sandboxing and that maybe fuse or something might be a solution, where you when running certain tools can map a directory into your container for instance
14:45:45 <otaylor> (Except that while you *could* have one local git repository for all your projects, you usually don't)
14:45:47 <alexlarsson> and gets checked out in a directory next to the repo, named by the sha1 hash
14:45:51 <ryanlerch> a not-really related question: will all the seperate runtimes for xdg app lead to the footprint of an install being bigger on my system (storage-wise) than a traditional package-based system?
14:46:25 <mclasen___> it could, if you install apps from a variety of places that depend on different runtimes
14:46:26 <cschalle> ryanlerch, probably, although ostree is doing some deduplication
14:46:29 <otaylor> ryanlerch: yes. Probably more from bundling of dependencies with apps than runtime duplication
14:46:39 <mclasen___> think of it like installing kde to try out kate
14:46:45 <alexlarsson> cschalle: that is how the document portal works, i.e. the fuse fs maps a single file into your app
14:47:04 <otaylor> ryanlerch: any file that is exactly duplicated will be shared
14:47:08 <alexlarsson> cschalle: but, you need the callout to pick the file outside the app so we can trust to give the app access to the file, and that a UI
14:47:30 <cschalle> alexlarsson, yeah, so colin thought that we might want some command line portals (which could probably be shared between docker and xdg-app for these kind of usecases)
14:47:58 <alexlarsson> ryanlerch: it depends, if you currently want to run a fedora 22 app on fedora 23 you need a vm or a chroot, which would likely be larger than having the f23 + f22 runtimes
14:48:12 <alexlarsson> ryanlerch: but yeah, doing so will take more space than f23 only
14:48:34 <alexlarsson> cschalle: but how do you "call out" into a portal from inside a terminal?
14:49:15 <otaylor> alexlarsson: the simplest case would be that the file passed on the command line gets portal'ed, but I think this falls over for anything complicated.
14:49:25 <alexlarsson> otaylor: yeah
14:49:54 <cschalle> yeah, it would clearly not be a 1to1 match of our 'UI' portals, and in some cases they might need to function so differently that calling them portals might be misleading
14:50:02 <mclasen___> xdg-app-portal print <pdf file> ?
14:50:41 <cschalle> maybe some of this is more like super priviledged containers?
14:51:07 <alexlarsson> xdg-app run org.vim.Editor `xdg-app export-file --app=org.vim.Editor ~/test.txt`
14:51:09 <alexlarsson> that would work
14:51:21 <alexlarsson> but its hardly easy to use
14:51:54 <stickster> So there's obviously details still to work out on the portal side
14:51:59 <cschalle> well I guess it is a discussing worth having with relevant parties, but maybe not something for us to hash out in this meeting?
14:52:05 <stickster> One other point is the release engineering tasks
14:53:13 * cschalle feels that stickster needs to follow that up with another sentence ;)
14:53:18 <stickster> I would like to un-subtly and expliclty make the point that this needs discussed *frequently* and *in detail* between the folks designing the working product and the Fedora release engineering team
14:53:49 <mclasen___> The Change page has a rough initial list of what we think we need
14:54:11 <stickster> mclasen___: Right, but the devil's in the details for things like "Tooling for building xdg-apps in Fedora
14:54:14 <stickster> "
14:54:27 <mclasen___> I will take the action to set up a meeting Owen, myself and 'rel-eng'
14:54:35 <hughsie> the hard bits for rel-eng would be getting the non /usr build target, right?
14:54:47 <hughsie> i.e. every rpm would need to be built multiple times?
14:54:51 <mclasen___> suggestions for who to reach out to ? Amanda Carter has been mentioned to me
14:55:15 <stickster> That's actually a good bit of work. Could involve rpkg/fedpkg or some other tooling, integration in the fedora-packager stuff, the tools to compose the product, and then also how do we expose those things in all the web services (koji, pkgdb, bodhi, others)
14:55:16 <mclasen___> hughsie: not every, only apps that we xdg-appify
14:55:55 <alexlarsson> and also, not those that are in the runtime
14:56:11 <stickster> mclasen___: Amanda has been organizing the work around Atomic and Docker layered images in Fedora, ISTM this is a similar project size/type
14:56:17 <hughsie> mclasen___, sure, but that would mean providing rel-eng with a list with all the apps, and all the non runtime deps, right?
14:56:17 <alexlarsson> only the leaf rpms, and whatever dependencies they need to bundle (that are not in our defined runtime)
14:56:25 <hughsie> seems "all" might be an easier thing to decide on
14:56:43 <alexlarsson> hughsie: Not really
14:56:53 <stickster> Don't we want contributors to be able to build xdg-apps for things they offer?
14:56:57 <alexlarsson> hughsie: because there will be fallout from things not rebuilding with a different prefix
14:57:08 <alexlarsson> hughsie: don't want to spend time on that for unused packages
14:57:16 <hughsie> what stickster said^^
14:57:28 <alexlarsson> stickster: ideally it should be rebuilt on demand
14:57:44 <otaylor> I think one of the main things is figuring out what we can help with- certainly things like adding xdg-app support to koji and rpkg are potentially things we can help out with.
14:58:01 <otaylor> alexlarsson: what do you mean by "on demand"?
14:58:06 <stickster> alexlarsson: by "on demand" you mean when a desktop-app package is updated, an xdg-app is auto-generated?
14:58:22 * stickster uses the stupid example of his pulsecaster package which is clearly a desktop app
14:58:42 <alexlarsson> otaylor: i mean, if and when you want to package foo, all the dependencies of foo are queued for a rebuild with a different prefix
14:58:53 <alexlarsson> package foo as an xdg-app i mean
14:59:01 <stickster> otaylor: re: helping with xdg-app support, that would certainly be useful and (I hope!) productive
14:59:28 <otaylor> alexlarsson: yeah, well, that's certainly raising the stakes
14:59:52 <stickster> that auto-packaging/rebuilding makes sense to me although yeah, it's definitely some retooling work
14:59:55 <alexlarsson> otaylor: yeah, i guess, in terms of infrastructure
15:00:22 <hughsie> i think it might be less confusing to rebuild everything to /app at package submission time
15:00:32 <hughsie> something like pulsecaster woul be easy to relocate
15:00:35 <hughsie> firefix less so
15:00:41 <stickster> But I think we can agree this isn't something to dump over the wall to rel-eng a month before release and expect it to be done... starting up some way to scope & track the work will help a lot.
15:01:02 <alexlarsson> hughsie: well, you don't want to rebuild things in the runtime
15:01:20 <hughsie> alexlarsson, did you do any work to try and guess how many apps would fail to relocate?
15:01:30 <alexlarsson> not really
15:01:33 <stickster> #info release engineering and service tooling component of offering xdg-app on top of Workstation is significant work; will need consistent outreach to rel-eng and infra guys
15:01:41 <alexlarsson> i know for instance the firefox wrapper script hardcodes /usr
15:01:43 <hughsie> alexlarsson, well, what happens if i'm targeting the fedora18 runtime, and i need a newer glib in my app bundle?
15:01:57 <stickster> We're over our hour, guys, and I have another meeting to attend. I can hand the gavel to someone else to #endmeeting when ready
15:02:12 <alexlarsson> hughsie: then you're not using a fedora 18 rpm to bundle, so you need to do something else, no?
15:02:20 <otaylor> stickster: maybe we just end the meeting and continue on #fedora-workstation
15:02:32 <stickster> mclasen___: I think Amanda is probably the person to contact and feel free to cc me/drop my name to discuss whether/how she might want to help track
15:02:36 <alexlarsson> i think we're talking about bundling the rpms from a single fedore release
15:02:38 <cschalle> yeah, we need to get both our internal and external tooling story polished. In some sense the external one is even more important in my eyes. I mean getting gnome-calculator as an xdg-app is a lot less value IMHO than getting github to offer an Atom xdg-app for instance
15:02:42 <alexlarsson> anyway, i gotta go
15:02:45 <mclasen___> stickster: ok, thanks
15:02:46 <stickster> alexlarsson: Thanks for being here
15:02:49 <stickster> hughsie: you too
15:02:53 <hughsie> alexlarsson, i'm thinking about the pathological case; e.g. vmware wanting to use a new glib and also wanting to work on fedora 18
15:03:06 <alexlarsson> hughsie: but they would not be using koji
15:03:12 <otaylor> hughsie: you don't need to target the fedora 18 runtime to work on fedora 18!
15:03:20 <alexlarsson> hughsie: they would take the f18 runtime and do whatever they want to jam in a new glib
15:03:27 <stickster> #action mclasen___ will contact Amanda and involve stickster so we can figure out how/where to discuss further with rel-eng and track work
15:03:27 <alexlarsson> hughsie: but it doesn't affect how we build our apps
15:03:30 <mclasen___> you just need to target the f18 kernel
15:03:55 * stickster hands gavel to mclasen___ and cschalle to #endmeeting when ready... I'll take care of sending notes out
15:04:01 <hughsie> alexlarsson, i guess; i just think everything is easier than having a dynamic number of apps opting in and out
15:04:21 <cschalle> stickster: where do we stand with 3rd party apps proposal
15:04:26 <mclasen___> well, and the f18 desktop shell
15:04:38 <alexlarsson> hughsie: well, the core stuff like glibc will be pretty hard to build relocated, and for no reason, because they will be in the runtime, not the apps
15:05:23 <stickster> cschalle: I still have some editing to do, have been a bit buried this past week with Alpha and some personnel issues
15:05:29 <cschalle> ok np
15:05:30 <stickster> but it's on my list for end of week
15:05:34 <hughsie> alexlarsson, "everything - a few things we know are going to fail"
15:06:15 <alexlarsson> hughsie: i guess we could queue the builds but not block if they fail
15:06:29 <hughsie> right; that would certainly work
15:06:58 <alexlarsson> then one would fix the relocated build when needed to package an app and the new rebuild would succeed
15:07:16 <alexlarsson> I guess that would work
15:08:03 <hughsie> alexlarsson, do you know if we have any non-blocking-build stuff in koji right now?
15:08:08 <cschalle> ok, do anyone got anything else for the working group? or should we endmeeting?
15:08:09 <hughsie> e.g. best effort builds
15:08:19 <alexlarsson> hughsie: yeah, non-important arches
15:08:33 <alexlarsson> tier 2 or whatever
15:08:34 <hughsie> if so, turning that on now would be a great step
15:08:47 <hughsie> and let us fix / exclude the easy stuff early
15:09:05 <alexlarsson> mips and ppc64 for instance
15:09:21 <hughsie> do we care about xdg-app i386 builds?
15:09:32 <alexlarsson> so, the entire thing could be handled as a secondary arch
15:09:35 <hughsie> i guess relocated arm and x64 is all we want
15:09:39 <alexlarsson> x86_64-app
15:09:39 <hughsie> i think so
15:10:12 * mclasen___ going to call it now
15:10:17 <hughsie> two new arches should be easy enough for rel-eng, considering they're just the same as existing witha custom build cflags
15:10:17 <mclasen___> #endmeeting