From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 2008-10-13
F10 Snapshot 1
- regression in installer so no DVDs
- cd-rom media testing fix didn't make it and dhcp was broken again
- 500 tracked downloads of live images
- concerns about torrent performance
- DECISION: f13 will work with dgilmore and nirik to get additional seeders in place for the next snapshot release
F10 Snapshot 2
- Goes out end of this week
- ACTIONS:
- create F10Snap2 tracker
- migrage F10Snap1 issues to F10Snap2
- produce full install tree and get pre-testing on it
Package Signing
- rough sketch of signing appliance:
- Networkless appliance connected via serial/usb/whatever
- Send data to system, it returns signature for data from given key
- Use of multilevel pins, one for admin, one for use of keys
- Upload new firmware via usb/serial, not network.
- Interact with gnupg and one I'm still not quite sure about
- Sign binaries approved to use in automated ways with system for signing
- in essence we need a box that isn't connected to anything else but our signing host
- ACTIONS:
- f13 to document current setup
- sgrubb to coordinate resources to start scoping out
- sgrubb to rediscuss at next meeting
MinGW Repos
- reviewed the amount of work necessary to support MinGW built packages in their own repo and determine whether it's "worth" the work
- built packages are installable and usable under fedora (with wine, or if you're compiling something that BuildRequires them)
- CONCLUSION:
- A lot of work to get these packages in their own repo with little perceived benefit
- Report back to Fedora Board:
- Release Engineering believes the return on investment for making a separate repo for MinGW built packages is too low and the amount of work too high at the present time.
- Release Engineering believes this issue would be worth revisiting in the future if space becomes an issue in the future
Open Discussion
- See IRC Transcript
IRC Transcript
| f13 | ping: jeremy warren wwoods lmacken rdieter poelcat | 10:03 |
|---|---|---|
| f13 | notting said he'd be missing the meeting | 10:04 |
| rwmjones | f13 you asked so I'm here | 10:04 |
| * lmacken | 10:04 | |
| f13 | right, I've invited a couple guests. | 10:04 |
| f13 | rwmjones so that we can talk about releng requirements for mingw | 10:04 |
| f13 | and sgrubb so that we can talk about the future of package signing. | 10:04 |
| * poelcat here | 10:06 | |
| * dgilmore pokes head in | 10:06 | |
| f13 | light set of people today :/ | 10:07 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora releng - Snapshot1 | 10:08 | |
| f13 | I got snapshot 1 out, late Friday. | 10:08 |
| f13 | It was live images only due to ongoing issues with installer. | 10:08 |
| f13 | We managed to regress installer since Beta :/ | 10:08 |
| f13 | over 500 tracked downloads of the various live images for snapshot1 according to the torrent tracker, so that's a fair amount of consumption | 10:09 |
| dgilmore | f13: i pushed out nearly 30gb via my torrent | 10:09 |
| dgilmore | the i686 images were most popular | 10:10 |
| f13 | they typically are | 10:10 |
| f13 | hopefully by this thursday we'll be in a better shape for having installer images too | 10:11 |
| f13 | There was a long thread about the torrent performance though, and I'm curious if there was any action items off that thread | 10:11 |
| dgilmore | f13: i think we need to make sure we have at least 2 seeders | 10:12 |
| dgilmore | to free it up i grabbed the iso's and started seeding them | 10:12 |
| * nirik would be happy to seed them from his mirror here. | 10:12 | |
| dgilmore | things happend much quicker then | 10:12 |
| f13 | yeah, but I'm still concerned that our seeder didn't do the right thing | 10:12 |
| f13 | IE hand out random chunks to clients instead of what seemed like the same chunks | 10:12 |
| dgilmore | f13: i think it did whats its supposed to do | 10:12 |
| dgilmore | f13: i think it was doing random chunks. but it was trying to serve them to everyone | 10:13 |
| f13 | was it just handing out the random chunks so slowly that everybody on teh torrent picked up those chunks from eachother immediately and were left waiting for more random chunks from the slow seed? | 10:13 |
| dgilmore | thats what it seemed like to me | 10:13 |
| f13 | ok. | 10:15 |
| f13 | so the problem with snapshots is that we're so so so time sensitive | 10:15 |
| f13 | we originally were just doing snapshots internally where there was lots of internal bandwidth to sync it around, and high concentration of testers where we were doing the snapshots | 10:15 |
| dgilmore | f13: nirik and i will both gladly help seed them | 10:15 |
| f13 | so we could do them on nearly daily basis | 10:15 |
| f13 | making them public has introduced a big problem, where often we don't complete a snapshot until late afternoon on say Friday | 10:16 |
| f13 | not to mention that getting them from either BOS of PHX to the torrent server takes a good chunk of time. | 10:16 |
| f13 | I'll have to look into if there is a way to get it from BOS -> RDU and from RDU -> torrent via internet 2 | 10:17 |
| * wwoods here | 10:17 | |
| dgilmore | f13: i wonder if we can do something with torrent to help those on I2 to get it faster. | 10:18 |
| dgilmore | and let them help with the commercial links | 10:18 |
| rwmjones | y | 10:18 |
| rwmjones | oops, wrong window sorry :-( | 10:18 |
| dgilmore | i know at least one person on i2 complained that they got it slowly | 10:18 |
| f13 | dgilmore: yeah, no idea there. I don't know if the torrent seeding software is smart enough | 10:19 |
| * nirik might also be able to offer it via http/ftp... we have lots of BW now I think... | 10:19 | |
| f13 | I know that seth has had lots of issues getting trackers to just be stable, let alone do anything smart. | 10:19 |
| dgilmore | yeah | 10:19 |
| f13 | nirik: syncing it to http points is going to add lag, + the dogpile would quickly consume all the bandwidth you have | 10:19 |
| dgilmore | i doubt there is a tracker smart enough to say oh your on a i2 link you get unlimited speed | 10:20 |
| nirik | yeah... ;( | 10:20 |
| f13 | but I can easily have the bits on a place where seeders could pick it up via http / rsync to help out in teh seeding | 10:21 |
| f13 | to be fair, the snapshot bits are currently available by http and rsync, I just didn't advertise the location as to avoid the dogpile. | 10:21 |
| dgilmore | f13: i think we should do just that | 10:22 |
| dgilmore | f13: thats how i got them to fix the seeding issue | 10:22 |
| f13 | poelcat: Decision: I'll work with dgilmore and nirik to get additional seeders in place for the next snapshot release. | 10:22 |
| f13 | wwoods: did you have anything to add releng wise regarding snapshot1? | 10:22 |
| * rdieter wakes up | 10:22 | |
| wwoods | not really; it was kind of unfortunately timed | 10:23 |
| wwoods | there was nothing rel-eng could have done to prevent it, though | 10:23 |
| wwoods | future snapshots should be better, which will bring the average quality back into line with expectations | 10:23 |
| wwoods | but yeah - cd-rom media testing fix didn't make it, and dhcp was broken again. alas. | 10:24 |
| wwoods | we'll want to make sure that snap2 gets poked a little harder. but the rel-eng side seemed to execute flawlessly, so no worries. | 10:25 |
| f13 | yeah, I'm rather dissapointed in that from a QA stand point. Going backwards is never good | 10:25 |
| f13 | alright lets move on. | 10:25 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora Releng - Snapshot 2 | 10:25 | |
| f13 | it's right around the corner! | 10:26 |
| f13 | We should throw up a F10Snap2 tracker bug and start throwing issues on it we know about | 10:26 |
| f13 | the issues currently on F10Snap1 woudl be good candidates | 10:26 |
| jwb | f13, did jeremy ask you to do an XFCE live snap? | 10:26 |
| f13 | I'll produce a full media set hopefully today or tomorrow for some initial testing. | 10:26 |
| f13 | jwb: rahul did, and there was one done, I just haven't uploaded it to the torrent server yet | 10:27 |
| f13 | it can be found on alt. if you look close | 10:27 |
| jwb | thanks | 10:27 |
| f13 | I guess Action Items: create F10Snap2 tracker, migrage F10Snap1 issues to it, produce full install tree and get pre-testing on it. | 10:28 |
| f13 | anything else on snapshot 2? | 10:29 |
| f13 | alright moving along. | 10:29 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora Releng - Package Signing | 10:29 | |
| f13 | I wanted to talk a bit about package signing, and this is why I invited sgrubb here today. | 10:30 |
| f13 | The current setup is thus (and it needs to get documented): Package signing happens on a xen guest in the PHX infrastructure. | 10:30 |
| f13 | It does not have sshd running, and it only allows a select few to login at the console. | 10:31 |
| f13 | what I do when I need to sign is I use xm to xen console login, I fire up sshd on a non-standard port, I then ssh out to create a tunnel to that port on another host. | 10:31 |
| f13 | I ssh in from that other host to the sign box, subsequently killing the sshd process and loggign out of the xm console | 10:31 |
| f13 | this leaves me with an ssh connection (in screen) but no way to create new connections, and no login hanging around on the xen console. | 10:32 |
| f13 | I use similar tricks to upload the gpg keys I'll be using for the signing run, import them and proceed with signing the desired packages. | 10:32 |
| f13 | the sign process involves passing builds (n-v-rs) into koji, querying for existing cached gpg sigs for the rpms, and any written out versions. Anything not cached is copied locally to the sign system, and rpm --sign is used to sign the local rpm | 10:33 |
| f13 | After the local rpms are signed, koji is used to import the signed headers into the database/filesystem. | 10:33 |
| wwoods | (wow that's complicated) | 10:33 |
| f13 | after that, anything that is cached but not written out for those n-v-rs is requested to be written out to the filesystem. | 10:34 |
| * rwmjones sure hopes the xen dom0 is secure, since xen dom0 can trivially read/write any guest's memory or disks | 10:34 | |
| f13 | once all the signing/writing is done, I purge the gpg keys from the filesystem, and consider that signing run "done". | 10:34 |
| f13 | rwmjones: "secure" is nice and vague. If you have specific concerns, I'd really like you to bring them to the Infrastructure team. | 10:35 |
| f13 | wwoods is correct in that it is "complicated" | 10:35 |
| rwmjones | f13, as in, no one you don't trust has root on the xen dom0 (or could get root) | 10:35 |
| f13 | however we (releng/infrastructure) feel it's the best balance we can strike right now between security, and actually being able to use the thing. | 10:35 |
| f13 | rwmjones: I'd have to fully confirm with infrastructure, but only select few are allowed to even log into the xen host, and even fewer of those have sudo rights that would lead to them being root | 10:36 |
| f13 | I do believe that the 'select few' is a larger number than who have login rights to the signing guest | 10:36 |
| f13 | our choices at the time were basically to use a xen guest and trust the dom0 security, or use real hardware and trust serial console security. | 10:37 |
| f13 | (and we didn't exactly have a lot of real hardware to spare, particularly with the storage requirements necessary) | 10:37 |
| f13 | now, I think we can all agree that this isn't ideal. | 10:37 |
| f13 | it's (as wwoods puts it) complicated, it's inefficient, it's not super secure, etc.. | 10:38 |
| f13 | it also continues to rely on a set of scripts we have to interact with koji and rpm --sign (gpg) that requires somebody punch in the gpg passphrase manually each signing run | 10:39 |
| f13 | often multiple times due to shell argument length restrictions. | 10:39 |
| dgilmore | f13: AFAIK only sysadmin-main can sudo and only sysadmin-main and sysamin-noc have access | 10:40 |
| f13 | We certainly don't want to stash the passphrases somewhere on the filesystem, and to this day, even with the hardware set that Red Hat uses in it's signing server, the best you can do with rpm --sign/gpg is an 'expect' setup. | 10:40 |
| f13 | What we want in the future sounds easy, secure, isloated, automated. | 10:41 |
| f13 | but it's far from easy. | 10:41 |
| sgrubb | selinux can enforce a pipeline of work | 10:41 |
| f13 | right now it takes 2 sets of credentials to sign packages. | 10:41 |
| sgrubb | labeled networking can also assure you that you are talking to the right processes | 10:42 |
| f13 | 1) proper FAS credentials to get logged into the right systems to get shell on the signing server | 10:42 |
| f13 | 2) the gpg private keys and passphrases. | 10:42 |
| f13 | in the future, we really want to remove package signiners from having specific knowledge of the gpg passphrases, as well as from having copies of the private key | 10:42 |
| f13 | that has a huge benefit, given our open project and turnover, but it does have a side-effect in removing one of our layers of credentials to signing packages. | 10:43 |
| f13 | To this end, I have been researching available opensource tools for gpg signing content without knowing a passphrase. | 10:43 |
| f13 | the only one I've really found is the OpenPGP smartcards | 10:44 |
| f13 | and even those are a bit nebulous wrt open source (I still can't find the source code to what's actually on the smartcard :/) | 10:44 |
| f13 | however testing with these has led me to believe it would not be suitable for our use. The first and main issue is that each card can only hold a single signing key, and that key can only be a relatively small bit key | 10:45 |
| f13 | given our future world where we're going to have different gpg keys for each release (and testing included with that) at the worst time when we're doing updates for 3 releases at once that would be 6 different GPG cards hanging off a machine somewhere. | 10:46 |
| f13 | not very ideal. | 10:46 |
| f13 | instead I've been thinking about what would be ideal, if we had to create it ourselves. | 10:46 |
| f13 | So I wrote down some thoughts I had about a signing appliance. | 10:47 |
| f13 | * Networkless appliance connected via serial/usb/whatever | 10:47 |
| f13 | * Send data to system, it returns signature for data from given key | 10:47 |
| f13 | * Use of multilevel pins, one for admin, one for use of keys | 10:47 |
| f13 | * Upload new firmware via usb/serial, not network. | 10:47 |
| f13 | * Interact with gnupg | 10:47 |
| f13 | and one I'm still not quite sure about | 10:48 |
| f13 | * Sign binaries approved to use in automated ways with system for signing | 10:48 |
| f13 | in essense we need a box that isn't connected to anything else but our signing host | 10:48 |
| f13 | and there is no communication with it aside from via the signing host | 10:48 |
| f13 | ideally it would work the way the smartcards work, integrated into gnupgp so that existing tools like rpm --sign don't have to be modified. They hit up gpg to get a signature, gpg interacts with our box and boom everybody is happy. | 10:50 |
| f13 | this is mostly focused on the ability to do signing without knowing a key | 10:50 |
| f13 | and keeping the device that /does/ have knowledge of the key secure | 10:50 |
| f13 | erm. | 10:51 |
| f13 | replace key with 'passphrase' in those last two sentences. | 10:51 |
| f13 | going beyond that, IE software that signers would interact with, that's a whole other realm of stuff to secure | 10:52 |
| f13 | as well as authenticating users to use this software. | 10:52 |
| f13 | as much as we trust FAS, just having a single credential (FAS) being all that is needed to sign packages seems a bit weak to me | 10:53 |
| f13 | lmacken: I seem to recall you have some thoughts in this area? | 10:53 |
| lmacken | FAS + yubikey would be pretty nice, that way it ensures that only people with a physical key would be able to sign | 10:53 |
| f13 | sgrubb: at one time you had offered resources from your team to assist in our efforts to secure our signing process. Does that offer still stand, and do you think your team would be better suited at creating the device, or securing the software we use to interact with the device? | 10:54 |
| lmacken | I recall one of the bigger issues being that the most secure setup entails physical access, and that isn't something we can have considering we would need it to be in a colo | 10:54 |
| lmacken | but I'm interested in this selinux pipelining and network labeling stuff :) | 10:55 |
| sgrubb | f13, yes I have one developer that was assigned to working on this | 10:55 |
| f13 | lmacken: can you explain a bit how the yubikey setup would work? | 10:55 |
| f13 | rwmjones: I apologize, it looks like this topic is going to go a bit long :/ | 10:55 |
| sgrubb | I can get another one or two depending on what his assessment is | 10:55 |
| sgrubb | f13, there were a couple points about the threat model | 10:55 |
| sgrubb | what are you trying to protect against and how do you know what you are signing? | 10:56 |
| lmacken | f13: well, their web site can best explain the security benefits of the key itself. But essentially, we can guarentee that the person is who they say they are (and that they pressed it at that moment) based on the one-time key generated by the device | 10:56 |
| sgrubb | I think the how do you know what you are signing can be addressed with an SE Linux enforced pipeline | 10:58 |
| rwmjones | f13, ah don't worry, just ping me when you get to mingw | 10:58 |
| sgrubb | labeled networking can assure that remote connections really are the processes you expect them to be | 10:58 |
| f13 | sgrubb: to be honest, I haven't thought much about verifying what is being asked to sign. | 10:59 |
| sgrubb | we have | 10:59 |
| f13 | sgrubb: verifying who is asking to sign it is vastly more important (: | 10:59 |
| sgrubb | I think that the build system would create a file with one kind of label | 10:59 |
| sgrubb | the key signer can only read that type of file | 11:00 |
| sgrubb | it changes the type to something else after signing | 11:00 |
| sgrubb | and policy written to block everything else to those types | 11:00 |
| lmacken | not only verifying what is being asked to sign, but also verifying that what you're signing is what is being asked for... eg: also verying koji checksums, incase someone can tamper with koji's tree | 11:01 |
| f13 | that may work for rpms comeing out of the buildsystem, but not for SHA1SUM files coming out of composes, or email messages being prepared for sending | 11:01 |
| sgrubb | people use selinux for email pipelines too | 11:01 |
| f13 | lmacken: right, that feels like the task of the software users interact with, simply checksumming the rpm it copies locally against what koji db says. | 11:02 |
| -!- Irssi: #fedora-meeting: Total of 106 nicks [1 ops, 0 halfops, 0 voices, 105 normal] | 11:02 | |
| sgrubb | mta gives it one type, virus scanner changes type, mta delivers new type to mail boxes now that its readable | 11:02 |
| f13 | perhaps I should add a comment here. | 11:02 |
| f13 | I want this system to be usable, soon, and hopefully fairly light weight. I don't want this to be a "look what we can do with selinux! isn't this awesome?" and be so cumbersome that nobody can use it. | 11:03 |
| sgrubb | :) | 11:03 |
| f13 | no offense (: | 11:03 |
| lmacken | security > usability :) | 11:03 |
| f13 | lmacken: sure, you make it so secure that nobody can use it and there is no possible way to use it incorrectly. | 11:04 |
| sgrubb | the thing is that depending on your threat model, it may require adding some barriers | 11:04 |
| f13 | there is a goal here, of allowing /more/ people into the signing party than we currently have. | 11:04 |
| sgrubb | are you wanting completely automated or only on demand ? | 11:04 |
| f13 | if we wanted to just be absolutely secure, we'd move it back into RH infrastructure, private systems, lock it down, etc... | 11:04 |
| f13 | sgrubb: both. | 11:04 |
| f13 | sgrubb: We want to automate signing of packages that are built in koji | 11:05 |
| f13 | but also do on-demand signing of packages and content. | 11:05 |
| sgrubb | as they come out? or on cron job? | 11:05 |
| f13 | ideally as they come out, so that it's a generally lighter load on the system. | 11:06 |
| sgrubb | ok | 11:06 |
| f13 | and doesn't introduce huge delays into the nightly rawhide compose process | 11:06 |
| f13 | that and people do consume packages directly from koji, it'd be nice to be able to gpg sign them adding to the trust model | 11:06 |
| sgrubb | sure | 11:07 |
| sgrubb | f13, I gave these requirements to mitr | 11:07 |
| sgrubb | I'll ask him to dig into this and ask questions if something is not clear | 11:08 |
| sgrubb | do you want him to attend next meeting and talk about his proposal? | 11:08 |
| f13 | sure, and he can chat with me/us at any other time too, waiting until the meeting hour need not be necessary. | 11:09 |
| sgrubb | any place he should look for you in case its needed? | 11:09 |
| f13 | #fedora-devel is likely the best place. | 11:11 |
| sgrubb | ok, got it | 11:11 |
| f13 | that's another goal too, whatever we develop, we need to do it openly, and available to comment/query/etc.. | 11:11 |
| sgrubb | agreed 100% | 11:12 |
| f13 | cool. | 11:12 |
| f13 | the only real immediate action item I see here is that we need to document the current signing process somewhere in the wiki, as ugly as i tis. | 11:12 |
| f13 | I suppose that falls to me | 11:13 |
| poelcat | f13: are there security concerns with doing that? | 11:13 |
| f13 | poelcat: if there are, we need to change what we're doing. | 11:13 |
| poelcat | okay :) | 11:13 |
| f13 | security through obscurity isn't a real valid strategy (: | 11:13 |
| f13 | at least, not in my opinion, I"m often wrong though | 11:13 |
| f13 | anything else on package signing before we move on to mingw? | 11:14 |
| * rwmjones bac | 11:14 | |
| rwmjones | back | 11:14 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora Releng - MinGW repos | 11:15 | |
| f13 | https://hosted.fedoraproject.org/fedora-infrastructure/ticket/807 is the ticket in question. | 11:15 |
| rwmjones | danpb gives his apologies -- he's basically always travelling home at 6/7pm in the evening (here) | 11:16 |
| f13 | essentially we need to look at the amount of work necessary to support MinGW as it's own repo and determine whether it's "worth" the work | 11:16 |
| f13 | (worth it to do on the side, rather than just treat mingw packages as if they were any other Fedora package) | 11:16 |
| rwmjones | here's another link you might want to take a look at: http://www.annexia.org/tmp/mingw/ | 11:17 |
| f13 | in comment #18 there is a set of questions I posed | 11:17 |
| f13 | well, and statements. | 11:18 |
| f13 | #1 has to do with buildsystems. MinGW wants to target both EPEL and Fedora right? | 11:18 |
| rwmjones | f13, errrmm, well ... if it was just EPEL-6 (which I guess will be based on koji) then we could live with that | 11:19 |
| rwmjones | certainly Fedora is our primary target | 11:19 |
| dgilmore | rwmjones: all of epel will switch to koji when poosible | 11:22 |
| rwmjones | sooner the better, koji's much better than plague :-) | 11:22 |
| dgilmore | f13: so you would need to duplicate the whole signing process. with new keys ? | 11:23 |
| f13 | not quite there yet dgilmore | 11:24 |
| f13 | #2 was bodhi | 11:24 |
| f13 | rwmjones: as I understand it, you'd want to be able to use bodhi to issue updates to the packages in your repos, correct? | 11:24 |
| rwmjones | f13, yes, really we'd like to do the whole thing as "normal" | 11:24 |
| rwmjones | so the whole koji/bodhi thing like we do with any other package | 11:25 |
| dgilmore | f13: so bodhi will need to learn about a new product? | 11:25 |
| dgilmore | how involved is that? it will need doing when koji supports epel | 11:25 |
| f13 | that's why lmacken is here. | 11:25 |
| f13 | lmacken: ? | 11:26 |
| f13 | right now we're talking about a few new koji tags/targets, inheriting from the Fedora brothers | 11:26 |
| lmacken | I don't think it will be very difficult, although we'll have to actually do it to find out, but it should be as easy as just creating a new release in bodhi (which can be done with 1 command) | 11:26 |
| f13 | some fun to be played with trying to build MinGW updates against Fedora updates that are in -candidate, or -testing | 11:26 |
| lmacken | If we want different email templates, I may need to add some configurability there, but I cannot think of anything else off the top of my head that would require changes | 11:27 |
| f13 | lmacken: does bodhi generate mash configs on it's own? | 11:27 |
| lmacken | f13: yep | 11:27 |
| f13 | ok, we'd need a new rsync script too to move the output into place | 11:27 |
| dgilmore | f13: and cvs branches to match the koji tags | 11:27 |
| f13 | dgilmore: right, CVS branches | 11:27 |
| f13 | now to #3 | 11:28 |
| f13 | package signing | 11:28 |
| f13 | *sigh* | 11:28 |
| dgilmore | and pkgdb needs to know also. which should be pretty doable as it does EPEL already | 11:28 |
| f13 | as I stated in the ticket, if mingw is it's own repo, it likely should have it's own key | 11:28 |
| f13 | so we'd need to throw more keys at our 'complicated' process | 11:28 |
| * lmacken & | 11:28 | |
| rwmjones | why can't the packages be signed with the ordinary key? | 11:29 |
| dgilmore | we would need at least 2 keys if we do EPEL also | 11:29 |
| f13 | but really, just getting bodhi to output requests on a per-target basis, and adding a few more keys to the keyring, that doesn't add much. | 11:29 |
| * rwmjones doesn't know much about this ... | 11:29 | |
| dgilmore | rwmjones: different products should have different keys | 11:29 |
| f13 | rwmjones: compartmentalization | 11:29 |
| f13 | rwmjones: same reason why we sign secondary arches with a different key | 11:29 |
| dgilmore | same reason epel is a different key | 11:30 |
| rwmjones | I assume we're still going to have the same f8/f9/f10 release schedule as for fedora? | 11:30 |
| rwmjones | & branches | 11:30 |
| dgilmore | id probably suggest not doing F-8 | 11:31 |
| f13 | rwmjones: isn't that up to you to decide? | 11:31 |
| dgilmore | but thats your choice | 11:31 |
| f13 | the last question I had was on the composes. | 11:31 |
| rwmjones | f13 I'm quite happy to keep in step with Fedora ... in fact our tools at the moment try to keep our specfile versions & patches in synch with the equivalent "native" Fedora packages (where they exist) | 11:31 |
| rwmjones | so gnutls & mingw32-gnutls are supposed to be roughly in synch | 11:31 |
| dgilmore | f13: what specifically? | 11:32 |
| f13 | at first glance, it looks like a mingw compose is essentially copying rpms into appropriate directories and running createrepo on it. | 11:32 |
| rwmjones | f13 that's what I do at the moment with that temporary repository | 11:32 |
| dgilmore | f13: im guessing it would be like doing updates and updates-testing composes | 11:32 |
| f13 | is there group metadata for MinGW? | 11:32 |
| * rwmjones didn't know there was any other way :-) | 11:32 | |
| rwmjones | ermmm ... | 11:33 |
| rwmjones | no, or at least, don't know | 11:33 |
| f13 | that would be a comps file | 11:33 |
| rwmjones | no, not one that I've set up anyway | 11:33 |
| f13 | that would be used to organize the MinGW packages into logical groups | 11:33 |
| rwmjones | they're all basically development tools & libraries | 11:33 |
| f13 | that'll add a wrinkle to the composing, just in that it's different than our other targets | 11:34 |
| rwmjones | in fact, the SIG charter is only to package dev tools & libs | 11:34 |
| dgilmore | i would think there should be comps. whicich i mentioned in a comment | 11:34 |
| f13 | dgilmore: well, adding compos means adding translations too | 11:34 |
| f13 | more work. | 11:34 |
| dgilmore | f13: yes. but i did mention that. in the ticket | 11:34 |
| f13 | k | 11:34 |
| dgilmore | forgot to mention comps will need to be setup with translations also. | 11:35 |
| dgilmore | :) | 11:35 |
| f13 | rwmjones: and I assume you want a rawhide repo too, just like Fedora? | 11:35 |
| dgilmore | at the leats you would want a mingw group that lives under development | 11:35 |
| f13 | and thus a nightly rawhide compose | 11:35 |
| rwmjones | f13 yup | 11:35 |
| rwmjones | f13 also we have to follow any security issues that appear in the native packages | 11:35 |
| f13 | sure. | 11:35 |
| rwmjones | since they'd presumably also be a security risk to our users | 11:35 |
| * dgilmore just thought of the imact of having two seperater devel trees in CVS | 11:36 | |
| f13 | rwmjones: in CVS, it would be branches of the existing apckage, or could you just have your own package at the srpm level, mingw-foo ? | 11:36 |
| f13 | as dgilmore noticed, trying to have two "devel" branches in CVS is going to... be difficult. | 11:37 |
| rwmjones | f13 that's a very good question, and one we don't know the answer to ... at the moment we set it up so that they'd be completely separate packages (ie. mingw32-*/devel etc) | 11:37 |
| rwmjones | but early on we did some investigation into doing it the other way, and even with combined specfiles & subpackages | 11:37 |
| dgilmore | f13: it would almost need to be its own cvs tree | 11:38 |
| dgilmore | mimiking /cvs/pkgs | 11:38 |
| dgilmore | /cvs/mingw | 11:38 |
| rwmjones | certainly the subpackage approach was felt to be a non-starter since it means two maintainers managing a single specfile | 11:38 |
| dgilmore | rwmjones: other than devel we could make a M-9 branch of the F-9 branch | 11:39 |
| f13 | for simplicity, I think having mingw specific srpms (and thus cvs modules) would be the easiest way to go | 11:40 |
| dgilmore | devel would be something not resembling fun | 11:40 |
| f13 | that way they can have their own devel/ F-10, F-9 branches | 11:40 |
| dgilmore | f13: i think so to | 11:40 |
| f13 | although | 11:40 |
| f13 | crap | 11:40 |
| dgilmore | f13: you need logic somewhere to know what tag to build against | 11:41 |
| rwmjones | here's a typical package from our current development repository: http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=12dbbe9a53163be7b03af0b65ff58df7feeef6c9;path=/gnutls/ | 11:41 |
| f13 | we'd have to have some logic in those specific modules or Makefile.common to send those builds to the mingw targets instead of the Fedor atargets. | 11:41 |
| dgilmore | f13: probably both | 11:41 |
| dgilmore | f13: have a file in the branch saying im a mingw package | 11:41 |
| f13 | at what point can we just say "too much work, put it in Fedora proper" ? | 11:41 |
| dgilmore | and have Makefile.common looking for it | 11:41 |
| rwmjones | there's a few duplicate packages, but currently: $ du -sh fedora-9/ | 11:42 |
| rwmjones | 435M fedora-9/ | 11:42 |
| dgilmore | f13: i think that to do it as a seperate release/product is too much work for us to handle. | 11:42 |
| rwmjones | that's i386 + x86_64 + srpms (and a few dups) | 11:43 |
| dgilmore | f13: i estimate that its probably going to take at least a week of my time to do. | 11:44 |
| dgilmore | plus time from everyone else to get the other bits done | 11:44 |
| f13 | yeah. | 11:44 |
| f13 | I also feel like it's a lot of work for limited gain. | 11:44 |
| f13 | Proposal: Report back to Board that from Releng POV the tradeoff of work for output is too high at this moment. If whatever the board has against the mingw packages being in Fedora proper ever comes to fruition, we can revisit moving mingw into it's own repo space. | 11:45 |
| f13 | +1 from my obviously | 11:45 |
| dgilmore | +! | 11:46 |
| f13 | wwoods: spot: lmacken: warren: rdieter: jeremy: I'm looking to you for votes too | 11:46 |
| dgilmore | +1 not that i really get a vote | 11:46 |
| rdieter | +1 | 11:46 |
| warren | huh | 11:47 |
| * nirik wishes his net had not fallen down in that fesco meeting. :( | 11:48 | |
| warren | net? | 11:48 |
| nirik | the fesco meeting where it was decided to use a seperate repo for mingw. | 11:48 |
| warren | but releng's recommendation is that the work/benefit ratio is too high? | 11:49 |
| warren | "If whatever the board has against the mingw packages being in Fedora proper ever comes to fruition" means what? | 11:49 |
| f13 | warren: it is if you vote for it. | 11:49 |
| wwoods | so we're talking about.. like 50 packages? | 11:52 |
| wwoods | less than that, really | 11:52 |
| rwmjones | wwoods, here's what we've done so far: http://hg.et.redhat.com/misc/fedora-mingw--devel/?mf=12dbbe9a5316;path=/ | 11:52 |
| wwoods | "so far" - so what's the planned scope? | 11:53 |
| poelcat | f13: proposal isn't clear to me... what is the "tradeoff of work for output"... what is the "output" ? | 11:53 |
| rwmjones | wwoods, libraries and development tools only. And only ones that people want. | 11:53 |
| f13 | poelcat: the output is the mingw package set. | 11:53 |
| f13 | poelcat: the package set we'd be doing work to segregate from the rest of the Fedora package set. | 11:53 |
| rwmjones | this is an application, which is _not_ in scope, but it should give you an idea of how much work it is to port each package: http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html | 11:53 |
| rwmjones | ie it's by no means a straight recompile | 11:54 |
| poelcat | f13: got it | 11:54 |
| wwoods | I admit a lot of ignorance of the mingw stuff, so forgive me if you've covered this stuff before. | 11:54 |
| f13 | wwoods: we haven't, and all we're really supposed to do is estimage the amount of work necessary | 11:55 |
| wwoods | But as I understand it we're talking about adding ~40-50 packages (possibly expanding over time here and there) | 11:55 |
| f13 | it's quite a lot of work, ongoing work, for a small package set. | 11:55 |
| f13 | from a resource consumption POV, I feel that we'd be consuming too many releng resources to try and save some mirror resources | 11:56 |
| wwoods | so we're providing a build stack for people using Fedora as a dev platform. and all it takes is a few dozen extra packages. | 11:56 |
| wwoods | and.. FESCo's objection is.. mirror space? purity? | 11:56 |
| rwmjones | FESCo don't really object, it's the board that asked FESCo to look into it | 11:57 |
| wwoods | but FESCo's recommendation was: okay sure, but keep it segregated from the main repos | 11:57 |
| wwoods | and I don't understand why | 11:57 |
| poelcat | so end result would be cross-compiled packages (not installable on Fedora) would be part of the regular repos | 11:58 |
| poelcat | ? | 11:58 |
| wwoods | poelcat: no | 11:58 |
| rwmjones | poelcat, no ... these packages are installable & even usable under fedora (with wine, or if you're compiling something that BuildRequires them) | 11:58 |
| wwoods | if I understand correctly, the end result is a toolchain/libs that you can use to build Windows stuff | 11:58 |
| poelcat | got it | 11:58 |
| rwmjones | poelcat, http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html is the sort of thing that end users could do with this feature | 11:59 |
| f13 | rwmjones: as a side not, would mingw be usable to build software drivers for Windows, like paravirt drivers? | 12:00 |
| rwmjones | f13 funny you should say that ... yes, BUT the licensing of the windows DDK would (probably) forbid it in practice | 12:01 |
| wwoods | I don't understand the rationale of FESCo's recommendation. Without that, I can only agree with f13: keeping them in a separate repo would be far more work than it's worth | 12:01 |
| rwmjones | I actually look at this problem last week | 12:01 |
| wwoods | but that's because.. I don't know what it's worth | 12:01 |
| rwmjones | DDK = driver dev kit | 12:01 |
| rwmjones | & if you even look at the DDK, be prepared never to write linux kernel patches for the rest of your life ... | 12:02 |
| poelcat | rwmjones: thanks. sorry to create confusion | 12:02 |
| f13 | rwmjones: yeah, thankfully I'm not involved in writing the drivers, although that is rather troublesome. My team inside RH is involved with producing the builds though. | 12:02 |
| rwmjones | wouldn't want you to steal any M$ super-sekrits of how to write a secure, reliable OS after all ... | 12:03 |
| f13 | ok, so rdieter and wwoods and I have voted, dgilmore offered his vote from a bystander. | 12:04 |
| f13 | any other votes, or are we just going ot assume this passed ? | 12:04 |
| f13 | </dictator> | 12:04 |
| rdieter | pass, move on, most benevolent dictator. | 12:05 |
| f13 | lol | 12:05 |
| f13 | poelcat: Decision: from Releng POV the tradeoff of work for output is too high at this moment. | 12:06 |
| poelcat | f13: okay.. mind if it state it in more plain terms in the recap? | 12:07 |
| f13 | sure | 12:07 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora Releng - Open Floor | 12:07 | |
| wwoods | so, one thing about the mingw stuff | 12:07 |
| f13 | rwmjones: thank you very much for showing up today and discussing these things with us. Sorry it took so long to get on our radar | 12:07 |
| rwmjones | ok np | 12:07 |
| f13 | wwoods: shoot | 12:07 |
| rwmjones | wwoods ask away? | 12:07 |
| wwoods | as I understand it, certain mingw-* packages will end up with .exe binaries in 'em? | 12:08 |
| wwoods | like, since you want to build against mingw's libvirt.. building that gives you virsh.exe | 12:08 |
| rwmjones | wwoods, yes, but only for development & debug tools (the canonical examples being certtool, virsh) | 12:08 |
| rwmjones | wwoods, have a look in the %files section of http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=f0ee5d27d597;file=libvirt/mingw32-libvirt.spec | 12:09 |
| rwmjones | as an example | 12:09 |
| wwoods | okay. and those will run under WINE? | 12:09 |
| rwmjones | wwoods, oh yes | 12:09 |
| wwoods | I mean at this point the difference between shipping mono/java binaries and windows binaries is just what the VM looks like | 12:09 |
| rwmjones | with binfmt_misc, they even work without specifying wine (modulo some bug in rawhide at the moment that causes them to fail about 1 time in 10) | 12:09 |
| wwoods | but you're shipping some unspecified bytecode in a non-ELF format that needs a special interpreter to run | 12:10 |
| rwmjones | not sure what that means ... they're i386 machine code | 12:10 |
| rwmjones | in a COFF/PE wrapper | 12:11 |
| wwoods | it's just a handwave - java / mono binaries aren't gonna be i386 machine code | 12:11 |
| wwoods | we still ship some | 12:11 |
| wwoods | nobody complains | 12:11 |
| wwoods | you ship a windows .exe.. people get wiggy | 12:11 |
| rwmjones | we've certainly had a lot of wigginess to deal with | 12:12 |
| poelcat | can anyone from the releng team help with my email list request to extract data on package changes from koji? | 12:12 |
| wwoods | but yeah, so long as this never descends into the realm of RPMs that contain windows-only binaries | 12:12 |
| wwoods | then I don't feel that particular objection carries a lot of weight | 12:12 |
| rwmjones | wwoods, I don't even use windows here ... even testing is basically wine | 12:12 |
| rwmjones | I actually installed winxp here virtually in order to test the installation really works, but basically I can't be bothered to fire it up because it's so much pain | 12:13 |
| f13 | wwoods: don't tell anybody, a lot of mono packages have .exe and .dll files in them. | 12:14 |
| wwoods | f13: OMG FLIP OUT | 12:14 |
| wwoods | anyway, I just wanted to talk through that and get it on the record: | 12:14 |
| f13 | wwoods: I think the main "wiggyness" comes from the thought that MinGW helps people create software for a non-free platform. | 12:14 |
| wwoods | yes, some windows-only .exe files will be shipped. yes, this is OK. | 12:14 |
| f13 | (which, please disregard any mono applications, java applications, python applications, etc..) | 12:15 |
| wwoods | right | 12:15 |
| wwoods | interoperability works both ways | 12:15 |
| rwmjones | our interest is to spread the libvirt API to as many different places as possible, to avoid people using competing proprietary APIs | 12:15 |
| rwmjones | and we don't want to use windows at all | 12:15 |
| rwmjones | so we have come up with an environment that let's us stay inside Fedora as much as possible (in fact, 100% of the time) | 12:16 |
| f13 | poelcat: I think we still have casey doing part-time intern work, maybe you could steal some of his time slices from notting | 12:16 |
| f13 | rwmjones: surely your QA people test on the actual target platform? | 12:16 |
| rwmjones | f13, not for windows - we test on our platform, namely RHEL & Fedora | 12:17 |
| rwmjones | I mean, no one pays us to get virt-manager on windows | 12:17 |
| f13 | ok, sure, but if virt-manager on Windows was a RH Offering, we'd have QA test on Windows right? | 12:18 |
| rwmjones | I guess if we sold the virt-* tools on windows as a supported offering, then we'd have to test on (real) windows | 12:19 |
| f13 | I'm on a wide tangent here. | 12:20 |
| wwoods | power outage! | 12:20 |
| f13 | ok, if there is nothing else, I'd really like to go get lunch | 12:20 |
| poelcat | f13: +1 | 12:21 |
| wwoods | power's back. and, yes, food | 12:21 |
| f13 | thanks all! long, but good meeting. | 12:21 |
| rwmjones | ok bye everyone, thanks | 12:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!