ReleaseEngineering/Meetings/2009-feb-16

From FedoraProject

Jump to: navigation, search

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

Mass Rebuild

  • rebuilding every package for three features:
    1. https://fedoraproject.org/wiki/Features/ArchitectureSupport
    2. https://fedoraproject.org/wiki/Features/gcc4.4
    3. https://fedoraproject.org/wiki/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 https://fedoraproject.org/wiki/Features/ArchitectureSupport 10:08
f13 https://fedoraproject.org/wiki/Features/gcc4.4 10:08
f13 and 10:08
f13 https://fedoraproject.org/wiki/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 - https://fedoraproject.org/wiki/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 https://fedoraproject.org/wiki/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 - https://fedoraproject.org/wiki/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 - https://fedoraproject.org/wiki/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 https://fedoraproject.org/wiki/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 https://fedoraproject.org/wiki/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!