PPA-created SourcePackageNames appear to exist in Ubuntu too

[William Grant]

I uploaded an rdiff-backup1.1.9 package to my PPA. Not Ubuntu. However, the SourcePackageName that would have been created upon that upload seems to affect Ubuntu too, so https://launchpad.net/ubuntu/+source/rdiff-backup1.1.9 exists, and can even have bugs filed on it! Those bugs aren't going to go anywhere, don't belong there, and won't have a component assigned, so it's probable that they'll just sit there contributing to the Ubuntu bug totals without anybody seeing them.

[Christian Reis (kiko)]

Damn, the code that checked for this seems to not have been migrated to the guided filebug form.

[Julian Edwards (julian-edwards)]

RF 5110

[Christian Reis (kiko)]

To clarify, it will no longer be possible to file bugs in Ubuntu specifying PPA package names; the code that verifies that was broken. We still need to consider how to avoid traversal to the package page given checking for publication to render the page may mean it becomes inaccessible pre-publication for Ubuntu, too.

William, you constructed that URL manually, right?

[William Grant (wgrant)]

On Fri, 2007-10-26 at 20:15 +0000, Christian Reis wrote:
> To clarify, it will no longer be possible to file bugs in Ubuntu
> specifying PPA package names; the code that verifies that was broken. We
> still need to consider how to avoid traversal to the package page given
> checking for publication to render the page may mean it becomes
> inaccessible pre-publication for Ubuntu, too.
>
> William, you constructed that URL manually, right?

I did.

[Christian Reis (kiko)]

Landed in RF 5110.

[Christian Reis (kiko)]

This will need consideration in Soyuz to decide whether it's a feature or a bug. If it's a feature we should at least update the distro pages to say "this package has not been published in $distro yet".

[William Grant (wgrant)]

Nothing seems to stop people from reassigning a bug to the SourcePackageNames after a distro task has been created.

[Julian Edwards (julian-edwards)]

The bugtask code is calling the wrong method on IDistribution from inside validate_distrotask, which is inconsistent with its call to IDistribution.guessPackageNames when adding a new bugtask it seems.

The easy fix is to change validate_distrotask to use guessPackageNames instead, which will never return packages only inside PPAs.

[Gavin Panella (allenap)]

Malone functional changes in RF 5536. Sample data fixes are still needed.

[Gavin Panella (allenap)]

The rocketfuel sample data is inconsistent with the new validation introduced in the malone task. Specifically, bug 7 has an evolution in Debian task and bug 9 has a thunderbird in Ubuntu task, both of which would be disallowed. However, fixing the data causes widespread breakage in the test suite, and is thus it's going to be a Big Job to do properly.

[Gavin Panella (allenap)]

kiko and bigjools have suggested that the sample data could be fixed by adding publishing records for these packages. This will still cause some breakage but perhaps less than otherwise. The approach I took before was to change the bugtasks.

[Christian Reis (kiko)]

Once this is fixed, we should finish off bug 176171

[Christian Reis (kiko)]

What's the Launchpad task here for?

[Gavin Panella (allenap)]

It's to remind me to fix the sample data.

[Julian Edwards (julian-edwards)]

Removing the Soyuz task from any milestones for now since I'm not sure what we're supposed to be doing as Gavin already acknowledged he needs to fix the sample data.

[Christian Reis (kiko)]

This needs fixing for 1.2.5 -- can't slip this time.

[Christian Reis (kiko)]

Well, I guess it can. It'd be nice to fix this but given the constraints of 2.0, and the fact that it no longer implies incorrect bug-filing, let's just leave it for later.

[Celso Providelo (cprov)]

I guess there is nothing concrete missing from Soyuz domain to get this bug fixed.

Obviously one of us (soyuz-team) can help with anything that has to be done in order to fix the lp-foundations task.