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:
    1. create F10Snap2 tracker
    2. migrage F10Snap1 issues to F10Snap2
    3. 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:
    1. f13 to document current setup
    2. sgrubb to coordinate resources to start scoping out
    3. 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:
    1. 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.
    2. 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!