diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 34 |
1 files changed, 17 insertions, 17 deletions
@@ -123,7 +123,9 @@ properties: ** information how many packages in other suites are in front of the first package in queue of this suite (so show a table of package, build_scheduled info and not just package names) ** information when new scheduling was done the last time for this suite * once experimental is fully tested, the scheduler should schedule 10% as many packages from experimental as from other suites, as all other suites are ten times as big -* graph average build duration by day +* more graphs +** graph average build duration by day +** graph oldest build age - in days * pkg sets related: ** new package set: kde/plasma @@ -141,15 +143,14 @@ properties: ** http://www.bstern.org/libuname/ - add "-ldl" to the linker flags... ** lunar suggests to use qemu with -r and -cpu and -rtc flags ** https://wiki.debian.org/qemubuilder - part of cowdancer - < Lunar^> I would rather say we do not do full uname and CPU variation that use an unreliable LD_PRELOAD - < Lunar^> because as soon as the package unset or reset the variable it won't be there anymore - * | h01ger nods. its also ok to leave some variations for when we go "for real" (aka rebuilds in the field) - <h01ger> | Lunar^: if that happens. if that doesnt we still get some more variations - <h01ger> | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete - <h01ger> | but we will find more problems "before going into the fields" - * | h01ger guesstimates that we would go from 300-600 builds per day to 100-200 with qemubuilder - <h01ger> | but those qemubuilders would only get 4 or 8gb ram... maybe 6. and that will have a huge impact - + < Lunar^> I would rather say we do not do full uname and CPU variation that use an unreliable LD_PRELOAD + < Lunar^> because as soon as the package unset or reset the variable it won't be there anymore + * | h01ger nods. its also ok to leave some variations for when we go "for real" (aka rebuilds in the field) + <h01ger> | Lunar^: if that happens. if that doesnt we still get some more variations + <h01ger> | so i'd say such an LD_PRELOAD would be useful, even though it wouldnt be complete + <h01ger> | but we will find more problems "before going into the fields" + * | h01ger guesstimates that we would go from 300-600 builds per day to 100-200 with qemubuilder + <h01ger> | but those qemubuilders would only get 4 or 8gb ram... maybe 6. and that will have a huge impact * misc ** show package status (briefly) on https://reproducible.debian.net/issues/*html @@ -158,16 +159,15 @@ properties: ** "fork" etc/schroot/default into etc/schroot/reproducible ** include no js header in the css ** use one css for all, not two minimally different ones -** graph oldest build age - in days ** restore the "find packages which have been removed from sid" part of reproducible_maintainance.sh ** re-enable the IRC notification for status changes, once the Pod::Man issue with timezone is fixed ** enable people to upload test packages, to be built in jenkins: - [17:27:51] <mapreri> h01ger: another wild future request by me: allowing us to upload something and let jenkins test it. rationale: I sent (another) patch for debian-keyring, to fix a timestamp issue in debian control files (due to not_using_dh-builddeb), but there is also a umask issue. I don't want to bother me to setup the very same things jenkins tests locally (I already did too much in this regards, imho), but really people can't tests everything - [17:27:51] <mapreri> jenkins tests. - [17:29:42] <h01ger> mapreri: please add the feature request to the todo. i'm thinking now that it maybe should just be a jenkins job not integrated into the rp.d.n webui, but... maybe we find a nice way to do it - [17:31:16] <mapreri> h01ger: I'm instead thinking about a repo defining a reproducible-specific suite or something on that line, that integrates well with the current setup. but this is really something wild. - [17:33:39] <h01ger> well, and everybody in debian-keyring from sid can uplood? :) - [17:34:37] <mapreri> that would be wonderful. + <mapreri> h01ger: another wild future request by me: allowing us to upload something and let jenkins test it. rationale: I sent (another) patch for debian-keyring, to fix a timestamp issue in debian control files (due to not_using_dh-builddeb), but there is also a umask issue. I don't want to bother me to setup the very same things jenkins tests locally (I already did too much in this regards, imho), but really people can't tests everything + <mapreri> jenkins tests. + <h01ger> mapreri: please add the feature request to the todo. i'm thinking now that it maybe should just be a jenkins job not integrated into the rp.d.n webui, but... maybe we find a nice way to do it + <mapreri> h01ger: I'm instead thinking about a repo defining a reproducible-specific suite or something on that line, that integrates well with the current setup. but this is really something wild. + <h01ger> well, and everybody in debian-keyring from sid can uplood? :) + <mapreri> that would be wonderful. === qa.debian.org* |