From Fedora Project Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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!

Retrieved from "https://fedoraproject.org/w/index.php?title=ReleaseEngineering/Meetings/2009-feb-16&oldid=472403"