From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 2009-02-16
Mass Rebuild
- rebuilding every package for three features:
- 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!