Today, I uploaded the latest development build (3.3.4) of the Totem video player to the GNOME3 PPA (Rico actually did most of this packaging). The Ubuntu Desktop Team is keeping Totem 3.0 in the normal Ubuntu archives because newer versions of Totem require clutter which means users would need to have working 3D graphics which isn’t the case for everyone. For instance, I am “lucky” enough to own a Dell Mini which came with Ubuntu pre-installed but also unfortunately came with the poorly supported Intel GMA500 “Poulsbo” graphics cards and the open source drivers don’t really do 3D yet.
The purpose of the GNOME 3 PPA is to provide the pieces of GNOME that don’t make it into the archives (specifically, GNOME 3.0 for Ubuntu 11.04 “Natty” [no longer supported], 3.2 for Ubuntu 11.10 “Oneiric”, and 3.4 for Ubuntu 12.04 “Precise”) and Totem is a great example of one of these pieces.
But when I went to upload totem, I used the following command
dput ../build-area/totem_3.3.4-0ubuntu1~precise1_source.changes ppa:gnome3-team/gnome3
which didn’t do what I expected. For some Linux commands, the order of arguments doesn’t matter; for quite a few others like dput, order is important. dput completely ignored the “ppa:gnome3” part of my command because the destination has to go before the .changes filename. If no destination is listed before the .changes filename, then dput by default uploads to the official Ubuntu archives. Within a few minutes, I was contacted by the ever watchful Martin Pitt and Micah Gersten to find out if I really meant to do that.
For the Ubuntu archives, packages in main like Totem can only depend on other packages in main, but the new totem depended on a universe package, mx. Because the new Totem was in dependency hold and didn’t actually build, Colin Watson was able to delete the source package and I uploaded a new totem-3.0.1-0ubuntu13 to replace it (which made a stop in the new queue first). If the package had built (which happens automatically unless there’s a dependency hold or the archives are frozen), we would instead have had to upload an ugly name like 3.3.4really3.0.1-0ubuntu1. Uploads to the Ubuntu archives must always have a greater number than previous uploads so that upgrades work (except -proposed but that’s different) but there weren’t any binary packages produced for anyone to upgrade to so this worked. By the way, the “really” uploads aren’t always accidents; sometimes Ubuntu developers decide that it would be better to remain with an older, more stable package when the newer version is found to not work very well.
I’m posting this so that when someone else does this in the future, they’ll have a bit of a writeup on what needs to happen to fix it. Also, I’ve fixed my dput so this won’t happen so easily to me in the future.
- Edit /etc/dput.cf .
- In the [DEFAULT] section, change the value of default_host_main to local. Leaving it blank isn’t a good choice as dput will default to uploading to the Debian FTP incoming server which isn’t a great place to accidentally upload something either.
I strongly recommend that anyone with Ubuntu upload rights make this change to their dput configuration, but I wonder if dput should be made more foolproof and not default to uploading to the Ubuntu official archives?
I don’t know of a command where the order doesn’t matter. However, for most commands, the order of options doesn’t matter, but the two arguments you passed to dput were not options.
When in doubt, autocompletion with can help you get them in the right order.
The PPA name itself doesn’t autocomplete, although I could make custom entries in my dput configuration for the PPAs I regularly upload to so that it does.
See the mental model I had was similar to the Unix cp command: dput from my local *.changes to the PPA but the syntax is the opposite. In my ideal, dput would either ignore the order of the *.changes filename since that can easily be recognized and print an error if an argument is unrecognized or will be ignored. That might improve the cleanup since the new upload can be deleted as long as new binary packages haven’t been published yet.
Good advice, it’s happened to me too in the past and I’ve done the same in my dput.conf file 🙂
i change default host to local 🙂
Thanks, I couldn’t think of a good name to fit in the blank but now I’m using your suggestion!