ReleaseEngineering/Meetings/2008-oct-13

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)
  • example: http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html
• 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!