shouldn't require careful publisher run when cloning new released distrorelease
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Medium
|
Jeroen T. Vermeulen |
Bug Description
<Kinnison> cprov: why do you think you need to careful?
<Kinnison> cprov: you prepare dapper.0, and set it FROZEN, then a normal run will apt-ftparchive it
<Kinnison> cprov: then you mark it released and compare
<cprov> Kinnison: uhm, the FROZEN trick must do, good point
<Kamion> ah
<Kamion> seems like a bug - if it doesn't exist, it should be apt-ftparchived no matter what state it's in, surely
<Kamion> well, possibly except for obsolete
<cprov> Kamion: currently the part that creates inexistent directoris in archive is not smart enough to transmit such situation to the a-f runner ... we could do it. File a bug on soyuz, please
(We ran into this when attempting to create dapper.0 from dapper prior to a point release. It wouldn't be a problem when creating normal non-released distroreleases.)
Related branches
- j.c.sackett (community): Approve
-
Diff: 1351 lines (+300/-628)10 files modifiedlib/canonical/config/schema-lazr.conf (+0/-10)
lib/lp/archivepublisher/interfaces/createdistroseriesindexesjob.py (+0/-26)
lib/lp/archivepublisher/model/createdistroseriesindexesjob.py (+0/-155)
lib/lp/archivepublisher/scripts/publish_ftpmaster.py (+82/-15)
lib/lp/archivepublisher/tests/test_createdistroseriesindexesjob.py (+0/-309)
lib/lp/archivepublisher/tests/test_publish_ftpmaster.py (+214/-55)
lib/lp/archivepublisher/zcml/configure.zcml (+0/-12)
lib/lp/soyuz/interfaces/distributionjob.py (+0/-8)
lib/lp/soyuz/scripts/initialise_distroseries.py (+0/-12)
lib/lp/soyuz/scripts/tests/test_initialise_distroseries.py (+4/-26)
tags: | added: new-release-cycle-process |
tags: | added: derivation |
Changed in launchpad: | |
milestone: | 11.05 → 11.06 |
tags: |
added: qa-untestable removed: qa-needstesting |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
It will be addressed after ArchiveRework tasks, by adding restricted arguments only to the publishing API.
IMO, it's not really required by now, since we have a simpler manner to ship DotReleases.