ReleaseEngineering/Meetings/2009-feb-16

Fedora Release Engineering Meeting :: Monday 2009-02-16

Mass Rebuild

• rebuilding every package for three features:
  1. Features/ArchitectureSupport
  2. Features/gcc4.4
  3. Features/StrongerHashes
• no changes needed to koji for i586 target
• rpm does not need patching--changes will be done in redhat-rpm-config
  • to be completed by dgilmore and jcm no later than Friday (hopefully earlier)
• Decision: dgilmore will handle koji config changes for ArchitectureSupport, and work with jonmasters to get redhat-rpm-config in shape. Requirements before building.
• Decision: jakub will get gcc 4.4.0-0.19 into rawhide, which is necessary before beginning Rebuilds.
• Decision: mitr will work with jonmasters to get correct checksum setting into redhat-rpm-config
• Decision: mbonnet and mitr will work together to get koji changes ready by the outage this weekend. mitr and jonmasters will work on the redhat-rpm-config changes to land after the outage. Then builds can commence.
• Decision: Allow the creation of a cvs file to opt-out of the scripted build, unless a manual build isn't done / attempted by the 26th. At such time, the scripted rebuild will override the opt-out and try to build anyway.

IRC Transcript

mbonnet	here	10:06
* notting is here		10:06
f13	ping: notting jwb rdieter wwoods lmacken spot warren poelcat	10:06
_bukaj_	here	10:06
* jwb here		10:06
f13	I do believe poelcat is on vacation, but will post the logs when he gets back	10:06
spot	here	10:06
jwb	_bukaj_, nice way to hide in plain sight :)	10:06
mikem23	not pinged, but here anyway	10:07
f13	We've also invited a bunch of people to talk about our first topic, the mass rebuild.	10:07
* dgilmore is here		10:07
-!- f13 changed the topic of #fedora-meeting to: Fedora Releng - Mass Rebuild		10:07
* ffesti is here		10:07
_bukaj_	jwb: been very long since I've been on freenode and all my favourite nicks are registered by others :(	10:07
f13	So this is the rebuild, every package....	10:07
f13	for 3 features.	10:07
dgilmore	f13: for rpm every package including noarch :)	10:07
f13	Features/ArchitectureSupport	10:08
f13	Features/gcc4.4	10:08
f13	and	10:08
f13	Features/StrongerHashes	10:08
f13	dgilmore: that is correct, every single package.	10:08
f13	First things first, who here is representing the ArchitectureSupport feature?	10:08
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - mass rebuild - Features/ArchitectureSupport		10:09
dgilmore	i guess me from a buildsystem perspective	10:09
f13	on this feature, from the rebuild POV, we need the rpm flags set right, and koji configured right	10:10
f13	the rpm flags I do believe are managed in redhat-rpm-config, is that correct?	10:10
dgilmore	kinda	10:11
_bukaj_	f13: both rpm and redhat-rpm-config, but the latter overrides	10:11
dgilmore	its a mix of rpm and redhat-rpm-config	10:11
dgilmore	in koji we need to change the arch list to "i586 x86_64 ppc ppc64"	10:11
mikem23	hmm, we may need code changes in koji if you want to build for i586 instead of i386 by default.	10:12
dgilmore	mikem23: we dont	10:12
mikem23	sure about that	10:12
mikem23	?	10:12
dgilmore	mikem23: yes	10:12
notting	dgilmore tested that last friday, afair	10:12
mikem23	keen	10:12
mbonnet	mikem23: dgilmore and I tested last week and changing the archlist appears to handle it fine	10:12
mikem23	however, that that works is mostly accidental	10:12
mbonnet	mikem23: tasks are still created i386 but i586 is set in the mock config	10:12
_bukaj_	will e.g. glibc swich to building on i586 and i686 from i386 and i686?	10:12
f13	so then the action items are: update rpm, update redhat-rpm-config, and update koji?	10:12
dgilmore	mikem23: its the same as building sparc sparcv9, and mbonnet and I both tested it building i586	10:12
_bukaj_	s/swich/switch/	10:13
notting	_bukaj_: yes.	10:13
notting	_bukaj_: is "-mtune=generic" the default?	10:13
notting	(in gcc)	10:13
dgilmore	f13: only changes needed is rpm and koji	10:13
_bukaj_	notting: it is if you don't specify -march	10:13
f13	dgilmore: don't have to touch redhat-rpm-config ?	10:13
notting	_bukaj_: and if you do?	10:13
dgilmore	f13: and rpm only to tell it that build arch for i586 and above is i586	10:13
_bukaj_	notting: if you specify -march=something, -mtune= defaults to something	10:13
dgilmore	f13: no	10:13
f13	interesting.	10:14
notting	f13: we need to rebuild redhat-rpm-config to add -mtune=generic in a couple of places	10:14
f13	what about mock?	10:14
_bukaj_	notting: so it is IMHO better to specify both -march and -mtune in rpmrc	10:14
f13	for people building outside of koji?	10:14
notting	(as _bukaj_ says)	10:14
f13	will they have to specify --target i586 ?	10:14
dgilmore	f13: we are not turning off support for people to build older releases	10:14
dgilmore	f13: yes mock will need changed	10:14
_bukaj_	notting: yeah, for i586 we don't pass -mtune=generic ATM, we only did that for i386 and i686	10:14
f13	ok	10:14
f13	who will own the action item to update the rpm config?	10:15
dgilmore	f13: i will	10:15
f13	dgilmore: you're going ot make the change to the rpm package?	10:15
f13	and is this going to be a patch, or an upstream setting?	10:15
dgilmore	f13: yep, i think it should be a patch	10:15
_bukaj_	dgilmore: do you think redhat-rpm-config can be changed already this week?	10:15
f13	ffesti: comments?	10:15
dgilmore	i dont know if upstream will want to change	10:16
notting	_bukaj_: should be trivial	10:16
f13	wait	10:16
f13	I thought redhat-rpm-config wasn't getting changed?	10:16
dgilmore	_bukaj_: ill get rpm and koji done. from what i looked at redhat-rpm-config did not need any changes	10:16
dgilmore	I will make sure that we have -mtune=generic though	10:16
ffesti	Panu, is probably the right person to comment on this	10:16
f13	Panu: shoudl this setting be a carried patch in Fedora, or should it be upstream?	10:17
f13	(and if its a carried patch in Fedora, why in rpm, and not set in redhat-rpm-config, you know, the place wherw we have our custom settings)	10:17
notting	r-rpm-config needs -mtune=generic in a couple of places	10:17
dgilmore	we need to make sure that as we go to i686 people can do i586 or other lower arches as secondary arches	10:17
Panu	well, in many ways redhat-rpm-config exists so that changes like this dont need to go to rpm itself	10:17
_bukaj_	Panu: yeah, I'd say the i386 -> i586 base arch switch is fairly Fedora specific	10:18
dgilmore	f13: we currently carry fedora specififc patches in rpm	10:18
f13	so?	10:18
Panu	not that it really matters where it goes, but I'm reluctant to change long-standing rpm upstream defaults for something that Fedora decides to do	10:18
f13	why aren't those moved over to redhat-rpm-config ?	10:18
f13	Panu: that's fine, I was just looking for upstream's thoughts.	10:19
notting	f13: our patches to rpm don't touch that bit	10:19
Panu	but whether the arch changes go to Fedora rpm package or redhat-rpm-config, doesn't matter much in practise	10:19
dgilmore	i have a patch for rpm already. i can redo it for redhat-rpm-config if thats the prefered location	10:20
f13	I'd just like to keep our config changes (which this sounds like) in one place	10:20
_bukaj_	Panu: as long as we have redhat-rpm-config providing rpmrc, the changes either need to be done in both places, or in just redhat-rpm-config, or redhat-rpm-config needs to be dropped	10:20
dgilmore	ok so rpm needs no touching, we can do it in redhat-rpm-config	10:20
f13	alright	10:21
* warren back		10:21
f13	so dgilmore owns updated redhat-rpm-config, and updating koji	10:21
f13	once those are done, we're clear to proceed with builds, as far as this feature is concerned, correct?	10:21
nirik	Panu / ffesti: don't suppose lzma will make it before this mass rebuild? still in upstream waiting limbo?	10:21
dgilmore	one issue we do have is where to make packages land on the mirrors	10:21
notting	dgilmore: still in i386/	10:21
f13	nirik: still waiting for stable upstream.	10:22
f13	dgilmore: at this time we aren't changing mirror paths	10:22
Panu	nirik: the XZ (formerly lzma) file format has been declared stable, but there's no stable release of the software yet so ... still waiting	10:22
dgilmore	we can continue to put them in i386/ but that will make mirrormanager and mirrors really had for secondary arches	10:22
f13	"i386" was a misnomer anyway.	10:22
warren	notting: will repomanage automatically remove i386 in favor of i586?	10:22
Panu	nirik: and I think we already have enough at plate for this mass-rebuild round :)	10:22
dgilmore	f13: thats fine until F-12 when we go i686 and chances of a i586 secondary arch is high	10:22
nirik	Panu: agreed. ;)	10:22
notting	warren: don't know, haven't tried. if it's keeping only the latest, it should	10:22
f13	dgilmore: then we can change the paths at that time.	10:23
dgilmore	ok	10:23
jnovy	nirik: lzma (xz) upstream has a stable fileformat only, not the whole utility yet	10:23
f13	back to the question at hand.	10:23
f13	once those are done, we're clear to proceed with builds, as far as this feature is concerned, correct?	10:24
* jonmasters is here		10:24
jonmasters	catching up with scrollback	10:24
* nirik likes 's/i386/x86/', but thats a bikeshead we perhaps shouldn't talk about color on.		10:24
notting	dgilmore: and to follow up f13's question - this isn't something that requires actual changes to the koji codebase, so it's not waiting on the outage this weekend?	10:24
mbonnet	notting: I have some questions about that	10:25
dgilmore	notting: it wont require any change sto koji	10:25
f13	jonmasters: we're going to have a change to make to redhat-rpm-config, dgilmore offered to produce the change, would be good to get it "upstream"	10:25
f13	notting: IIRC, for this particular feature, it just requires koji config changes, not code changes.	10:25
dgilmore	notting: we can build i586 today	10:26
f13	(trying to take this one feature at a time)	10:26
dgilmore	ill make that change now	10:26
f13	dgilmore: please wait	10:26
knurd_afk	nirik, x86 in kernel land is "x86 arch (32 or 64 bit), so using x86 for 32-bit only x86 is a bit confusing imho	10:26
dgilmore	notting: we need changes for StoringerHasnes and noarch subpackages	10:26
mbonnet	notting: I still haven't seen a package built with the stronger hashes support, I need to make sure that the header tags we use are still valid	10:26
f13	guys	10:26
f13	we're getting off the subject here	10:26
mikem23	stronger hashes changes landing in koji git later today	10:26
notting	mbonnet: was refering *solely* to i586	10:27
* f13 needs a gavel to pound.		10:27
mbonnet	notting: ok	10:27
jonmasters	f13, dgilmore: You already brought up the only change I thought was needed - just an arch flag tweak. Looks like you propose mtune=generic?	10:27
jonmasters	Why do we need to change build flags for this gcc/glibc update?	10:28
dgilmore	jonmasters: -mcpu=i586 -mtune=generic	10:28
notting	s/cpu/arch/	10:28
jonmasters	dgilmore: but that's only for kernel, right?	10:28
f13	jonmasters: for everything.	10:28
dgilmore	jonmasters: everything	10:28
jonmasters	wait	10:28
f13	jonmasters: welcome to the party.	10:28
jonmasters	you want to make i586 default now for everything?	10:28
dgilmore	jonmasters: we will be building all rpms .i586	10:28
jonmasters	oh	10:29
jonmasters	that I had missed, ok	10:29
f13	jonmasters: see Features/ArchitectureSupport	10:29
dgilmore	jonmasters: F-12 will be .i686	10:29
jwb	dgilmore, maybe	10:29
f13	(maybe)	10:29
warren	jonmasters: jakub's recommendation, plus fedora-devel-list and 2 weeks of deliberatoin	10:29
_bukaj_	jonmasters: i386 wasn't working anyway for a few years and i486 is now officially dead as well	10:29
_bukaj_	we haven't been shipping i486 kernels anyway	10:29
jonmasters	f13: I thought that was just going to repeat the kernel arch change so I didn't read it properly...serves me right ;)	10:29
* f13 tries to herd things back to the question at hand.		10:30
jonmasters	warren: again, I was only looking at the kernel view, didn't realize that also was generic.	10:30
jonmasters	ok, I'll shutup :)	10:30
notting	dgilmore: double check the sparc, ppc, and s390 flags while you're there, of course	10:30
f13	Once the koji config change, and the redhat-rpm-config change are made, does this feature require anything else before we can start building for it?	10:30
dgilmore	notting: will do, i know we use toe sparcv9 from rpm itself along with sparcv9v	10:31
jonmasters	f13: how do you handle deps - do you rebuild libs first then other packages?	10:31
dgilmore	f13: as soon as we change the arch list in koji we will get i586 rpms	10:31
_bukaj_	dgilmore: yeah, for s390 and s390x we are changing to -m	10:31
f13	jonmasters: not relevant atm.	10:31
_bukaj_	dgilmore: -march=z9-109 -mtune=z10	10:31
dgilmore	_bukaj_: cant do that	10:32
_bukaj_	dgilmore: ppc stays as is in Fedora	10:32
* warren leaves for doctor		10:32
dgilmore	_bukaj_: s390x fedora hardware doesnt support it	10:32
jwb	_bukaj_, as-is?	10:32
jwb	_bukaj_, i thought for ppc64, it was changing to -mcpu=power4	10:32
jonmasters	dgilmore: ping me after, we'll sort out what needs changing	10:32
_bukaj_	dgilmore: I was told d all our zStream boxes are at least z9-109	10:33
dgilmore	jonmasters: sure	10:33
_bukaj_	dgilmore: so what it is if not z9-109?	10:33
jonmasters	dgilmore, f13: I'm looking at r-r-c at the moment	10:33
dgilmore	_bukaj_: let me double check but i believe that what fedora is using is not	10:33
_bukaj_	jwb: for ppc64 it is not a big change, I think it can be done just in RHEL where it is added for both ppc and ppc64	10:33
dgilmore	_bukaj_: we can sort this out outside of here	10:34
_bukaj_	dgilmore: rawhide gcc already defaults to those flags...	10:34
jwb	_bukaj_, ok, if you wish. fwiw, i'm find with ppc64 (-m64) defaulting to -mcpu=power4. just ppc32 needs to be usable on ppc32 hardware, that's all	10:34
notting	ok, so: dgilmore and jcm wiill handle redhat-rpm-config updates, to be absolutely done by friday (hopefully earlier), and once that is done, we can enable i586 builds if we desire. correct?	10:34
f13	notting: that's what has been said	10:35
jonmasters	notting, dgilmore: As far as I can see, there's only a one liner needed	10:35
jwb	after the koji outage?	10:35
f13	Lets not make any changes immediately, until we get to the end of the topic list.	10:35
f13	jwb: can be done before outage.	10:35
jonmasters	notting, dgilmore: optflgs in rpmrc needs changing from:	10:35
mbonnet	f13: some links in the web UI may be wrong until after the koji upgrade, but it's not critical	10:35
jonmasters	optflags: i586 %{__global_cflags} -m32 -march=i586 -fasynchronous-unwind-tables	10:35
f13	this particularl feature does nto require koji outage.	10:35
jwb	f13, true	10:35
jonmasters	notting, dgilmore: to whatever you all want	10:36
f13	ok, lets move on.	10:36
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - mass rebuild - Features/gcc4.4		10:36
f13	_bukaj_: I do believe you're the owner of this feature yes?	10:36
dgilmore	f13: this can be started after the koji update	10:36
jonmasters	f13: I'll post email about the proposed flags etc. and leave that until later - sorry to disrupt :)	10:36
_bukaj_	f13: true, but that gcc is already in rawhide for some time	10:36
f13	_bukaj_: you had mentioned wanting some "soak" time before starting any mass rebuilds.	10:37
f13	_bukaj_: are you comfortable with the state of gcc to begin our builds?	10:37
_bukaj_	f13: I guess one to three bugfix nvrs will still land in koji this week, but other than that, it should be fine	10:37
_bukaj_	f13: yeah	10:37
f13	_bukaj_: well, should we wait for those or not?	10:38
f13	what are the hard requirements of what must be done before we can start building for this feature?	10:38
_bukaj_	f13: you said you'll start mass rebuild on Monday anyway	10:38
_bukaj_	f13: you should wait at least for 4.4.0-0.19, but I'm going to build that tonight or so	10:38
f13	_bukaj_: and if your bugfixes don't make it in by then?	10:38
f13	I don't like working from assumptions.	10:39
f13	ok, thank you.	10:39
f13	_bukaj_: you'll own getting 4.4.0-0.19 in, and we won't start any builds until after that is done.	10:39
_bukaj_	f13: there are just 2 or 3 bugs I'm aware of that are relevant for the builds, only one (already fixed upstream) might hit many packages	10:39
* f13 does some wiki log help		10:39
_bukaj_	f13: ok	10:39
f13	Decision: dgilmore will handle koji config changes for ArchitectureSupport, and work with jonmasters to get redhat-rpm-config in shape. Requirements before building.	10:40
f13	Decision: jakub will get gcc 4.4.0-0.19 into rawhide, which is necessary before beginning Rebuilds.	10:40
jonmasters	f13, dgilmore: I just sent email with proposed change, please followup with SPARC or other changes you would like to discuss.	10:41
f13	Moving along	10:41
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - mass rebuild - Features/StrongerHashes		10:41
f13	This is the more fun one.	10:41
f13	IIRC it requires a change in rpm, as well as changes in koji code.	10:41
f13	Panu: ffesti: where are we on the rpm changes?	10:41
mitr	No change in RPM - only a macro (so probably redhat-rpm-config)	10:42
Panu	From rpm POV, it just needs two configuration bits set, both of which could/should arguably go to redhat-rpm-config	10:42
f13	ok.	10:42
f13	so that's jonmasters again.	10:42
f13	who will work with jonmasters to get the right change ready?	10:43
mitr	I'll do that	10:43
jonmasters	f13: if panu of mitr tell me that config bits needed for rpm I'll shove it in there at the same time as the flags.	10:43
notting	does this r-r-config change need synchronized with the koji change?	10:43
jonmasters	s/of/or/	10:43
f13	Decision: mitr will work with jonmasters to get corret checksum setting into redhat-rpm-config	10:43
notting	(to avoid Weird Stuff) happening?	10:43
jonmasters	notting: can't see why it would matter	10:43
f13	notting: yes	10:44
f13	that's the next item.	10:44
f13	bit first	10:44
f13	well, n/m	10:44
notting	i.e., do we need koji changes live before we can flip these bits in r-r-config?	10:44
nim-nim	BTW, font packages will fail the rebuild till http://koji.fedoraproject.org/koji/taskinfo?taskID=1131125 is built	10:44
f13	notting: yes	10:44
jonmasters	notting: oh, I see	10:44
f13	Next is the koji side	10:44
nim-nim	and to build it requires rpm = 4.6.0-4 koji-side	10:44
f13	I understand that a few things need updating in koji code, but those are either done upstream, or near done, and just waiting for the outage?	10:44
nim-nim	according to jnovy	10:44
dgilmore	nim-nim: no it does	10:45
jonmasters	notting: the flags for arch on i586 can be done any time this week, so we'll do those today or tomorrow and wait on koji for the hashes	10:45
dgilmore	doesnt	10:45
jonmasters	f13: ^^^	10:45
dgilmore	one of the features in new koji is srpm in a chroot	10:45
f13	jonmasters: please wait.	10:46
dgilmore	so each srpm we be built with the rpm that is in its release	10:46
mbonnet	f13: mitr is getting me a StrongerHashes package later today. Until then I won't really know how extensive the changes will be.	10:46
dgilmore	the hosts rpm will no longer limit things	10:46
jonmasters	f13: nobody builds i586 today except kernel	10:46
nim-nim	dgilmore: that's the same thing for philistines like me	10:46
mbonnet	f13: in addition we'll probably need to ping Panu and ffesti about the semantics of the new hash support	10:46
jonmasters	f13: so changing what happens if you build an i586 package doesn't seem a big deal	10:46
f13	jonmasters: sure, I suppose.	10:47
f13	I just don't want anything unannounced to start happening to the ongoing builds	10:47
nim-nim	I just wanted to point out: please restart the build of this package as soon as koji is changed	10:47
nim-nim	font package builds will fail till it's done	10:47
mitr	mbonnet: Seen RPM_file_format_changes_to_support_SHA-256 ?	10:48
mbonnet	mitr: yeah, not specific enough	10:48
mitr	mbonnet: Feel free to ask :)	10:48
mikem23	mbonnet, f13: I've applied mitr's patch in koji and am testing it. Needed a small tweak but looks good overall. Going to push to git later today	10:48
* f13 tries to sort out the mixed signals		10:48
mitr	mikem23: Is that the gpg patch? I didn't prepare any patch related to the mass rebuild.	10:49
mikem23	sorry, yeah, gpg patch	10:49
mikem23	I guess I'm the confused one ;-/	10:49
mbonnet	mikem23, mitr: is rpm.SIGTAG_MD5 staying md5? If so, we're not really gaining anything on the koji side from stronger hashes.	10:49
mikem23	afaict, yes, sigtag_md5 remains the same	10:50
mitr	mbonnet: Yes. koji only needs to stop tracking TAG_FILEMD5S .	10:50
jonmasters	f13: agreed, dgilmore and I have a plan	10:50
mitr	(or make sure it handles the larger values, I suppose.)	10:50
mikem23	I'm not sure if there is a straight sha2 hash apart from the sigatures	10:50
mbonnet	mitr: ok, so filemd5s goes away? use filedigests now?	10:50
mitr	mbonnet: filedigests and filemd5s are the same tag, only a new name.	10:50
mbonnet	mitr: any idea if the python bindings still define RPMTAG_FILEMD5S ?	10:51
mbonnet	for backward-compat?	10:51
* mitr checks		10:52
nim-nim	dgilmore: anyway the current build problem is here http://koji.fedoraproject.org/koji/getfile?taskID=1131126&name=srpm.log	10:52
nim-nim	dgilmore: so I'll change my "it requires rpm ≥ 4.6.0-4 koji-side" by "it requires rpm ≥ 4.6.0-4 koji-side at the make srpm stage"	10:52
mbonnet	mitr: actually, it probably doesn't matter	10:54
mitr	mbonnet: AFAIK everything remains - but I'll make sure.	10:55
f13	so, mbonnet and mitr will work together on the koji changes necessary	10:56
f13	targetting the outage this weekend, correct?	10:56
mitr	ok	10:56
mbonnet	f13: so you can assume we'll have any necessary koji changes for stronger hashes in the koji update this weekend	10:56
f13	lets recap	10:56
f13	koji changes, this weekend, and redhat-rpm-config changes, which require the koji changes in place.	10:56
Panu	mbonnet: RPMTAG_FILEMD5S is still there and will give you a hash, if you actually care about the algorithm of the hash there's another tag that holds it	10:56
mbonnet	Panu: perfect	10:57
f13	aside from those two things, is there anything else required before we start building for StrongerHashes?	10:57
mitr	f13: Do you want to discuss package signing today?	10:57
f13	mitr: no, because that's different from rebuilding the packages.	10:57
mitr	Nothing more is necessary for the rebuild AFAIK.	10:57
dgilmore	f13: i think we will be ready to start the rebuild on monday	10:57
f13	alright	10:57
f13	Decision: mbonnet and mitr will work together to get koji changes ready by the outage this weekend. mitr and jonmasters will work on the redhat-rpm-config changes to land after the outage. Then builds can commence.	10:58
jonmasters	k	10:58
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - mass rebuild - recap		10:58
f13	Given all the decisions and work items, I agree with dgilmore that we should be ready to begin building by Monday	10:59
f13	before that starts, we should look at the existing list of fails to build from source	10:59
f13	_bukaj_: have you seen any progress with teh list of things you had that won't build?	10:59
* notting has one he hasn't cleaned up yet, needs to do that		11:00
f13	that's some loud crickets.	11:01
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - mass rebuild - mechanism		11:01
_bukaj_	_bukaj_: a bunch of people fixed stuff, but I haven't really tracked how many those were	11:02
_bukaj_	_bukaj_: so far I had a lot of work with stuff that got reported to me...	11:02
f13	Given the timing of the builds, and the amount needed to get done, I don't think we have the luxury of giving maintainers a window to do the builds themselves.	11:02
f13	However, I do want to give the ability for maintainers to "opt-out" of the mass build.	11:03
f13	I'm thinking the easiest way to accomplish this is to check a text file into the package module, like "dontbuild" that has a short reason as to why we shouldn't build it	11:03
jwb	f13, we need to be careful with that.	11:03
f13	that way my builder script will see such opt-out, and move along.	11:03
jwb	we don't want people opting-out because they think "oh, this is noarch. don't bother"	11:04
f13	of course, we'll have another script that will be checking to see what is or isn't build yet	11:04
f13	and people that opted out will continue to get nagged until they build their package.	11:04
dgilmore	f13: we could give them this week to opt-out,	11:04
dgilmore	then 2 weeks to build. if they dont we do it anyway	11:04
f13	right	11:04
f13	The goal is to have everything built before the FEature freeze	11:05
dgilmore	ok	11:05
dgilmore	so we want everything rebuilt a week before	11:05
f13	Feature freeze is March 3	11:05
dgilmore	that way there is some tim to look at failures	11:05
f13	if we start the builds on next Monday, that only gives us next week to complete the builds	11:05
f13	the following tuesday is the feature freeze	11:05
dgilmore	assuming we start 23rd we have 10 days	11:05
dgilmore	f13: i think we cant allow opt outs	11:06
dgilmore	if we do they have until the 26th	11:06
f13	dgilmore: I think we can, but those opt-outs will be overridden after the 26th	11:06
dgilmore	f13: ok that can work	11:06
f13	Proposal: Allow the creation of a cvs file to opt-out of the scripted build, unless a manual build isn't done / attempted by the 26th. At such time, the scripted rebuild will override the opt-out and try to build anyway.	11:07
f13	I'm +1 on this	11:07
f13	(releng folks, please vote)	11:07
dgilmore	+1 (not sure if im considered releng)	11:07
notting	+1, i like having a deadline	11:08
jwb	+1	11:08
f13	Guess that's all the votes I'm going to get, it passes.	11:11
f13	As for the actual script, as I described in email, I envision it doing a check out, look for the opt-out file, auto bump the spec, check in, tag, issue background build, move on.	11:12
f13	each step of the way will have a test for failure and build up some lists of packages that failed for one reason or another so that I can manually clean up	11:12
dgilmore	f13: sounds good	11:12
f13	as also mentioned, I'm going to write a script that will query dist-f11 to see what all has or has not been built, to start generating nag reports	11:13
f13	broken down by maintainer, etc etc	11:13
f13	That's basically all I have for this mass rebuild. Any further thoughts/questions/comments?	11:14
notting	there aren't any abi or other things that require ordering, correct?	11:15
f13	I'm hoping not	11:15
f13	because I'm certainly not planning on scripting for order and doing chains of any kind	11:15
ffesti	I'll launch Features/NoarchSubpackages as soon as koji is updated	11:16
notting	_bukaj_: do any of fortran/gcj/ada/whatever change ABI in 4.4?	11:16
ffesti	but I guess it will only affect a view hundred packages	11:16
ffesti	at best	11:16
f13	ffesti: right, that feature is more about the ability to do so, rather than doing so with as many packages as possible correct?	11:16
_bukaj__	notting: I think nothing that any package will hit	11:16
_bukaj__	notting: there might have been changes in decimal floating point arg passing or something like that	11:17
_bukaj__	notting: but nothing in the distro uses it	11:17
ffesti	f13, I compiled a set of lists. The first few hundred packages contain already the very most of the noarch content	11:17
_bukaj__	notting: especially not in APIs	11:17
ffesti	f13, the lists are now uploaded to the Feature page	11:18
f13	ffesti: sure, I just don't think we actually have to rebuild anything for noarch subpackage in order for your feature to be a success, as far as F11 is concerned.	11:18
f13	rebuilding can happen after feature freeze	11:18
ffesti	nope	11:18
_bukaj__	f13: so the only ordering that might be desirable is order packages that contain statically linked binaries last	11:18
_bukaj__	f13: or rebuild them w once again when everything is rebuilt, otherwise some oldish libfoobarbaz.a might be linked in	11:19
f13	hrm, interesting thought	11:19
* f13 wonders how many packages that would be		11:19
f13	or if we have any way to discover them besides the presense of a -static subpackage	11:20
jwb	it would be awesome if the ordering was done in roughly what it took to bootstrap a secondary arch	11:20
_bukaj__	f13: given that there are no ABI changes (that matter), it is not a big deal, but when we rebuild everything, it would be better to just ship everything rebuilt, not parts of F9 or how old libbarbaz-static-devel libs in F11 binaries	11:20
jwb	so that those people could steal from your script :)	11:20
f13	sure.	11:20
_bukaj__	jwb: well, we have all those fancy buildreq loops all around	11:20
f13	jwb: that's not likely possible without doing a lot of --without-feature builds, followed by later --with-feature builds.	11:20
jwb	i know. i was dreaming	11:21
f13	heh	11:21
f13	good dreams (:	11:21
f13	alright, anything else?	11:21
f13	Looks like no, thanks all for coming!	11:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!