Re: Uploading to multiple distros
On Thu, Jun 2, 2011 at 8:20 AM, Ian Jackson wrote: ... > One thing I have done a few times is to upload the very same package > simultaneously to (say) Debian and Ubuntu. > > Where the package wants to be identical, and the person doing the > upload is the same, it would be nice if this could be made simpler. > At the moment you basically need to build the whole thing twice with > minor edits to the changelog to set the target suite. > > It would be nice if this could be made simpler. In principle it would > be nice if you could use the same .changes file for uploading to two > distros (provided that only one of them wants binaries) but that may > be too much to ask. > > At the very least it should be possible to do one upload to two > distros without altering the debian/changelog. I handle this using a set of scripts in Ubuntu's bikeshed package: * http://manpg.es/release-build * http://manpg.es/release 'release-build' builds me one binary package, which I test locally, and gives me instructions on what to do next, if I want to proceed with the upstream release and upload to a bunch of different places simultaneously. It also builds source packages for each of the supported Ubuntu releases. If my testing goes well, I'm informed to run the 'release' command. 'release' then does a handful of things (like tagging the release, bumping and opening the next version), and prints a series of commands that I run manually, if I want to actually do the release (such as the bzr push to the trunk, lp-project-upload to put the tarball on Launchpad, dput of the backport changes file to that package's PPA, and dput to Ubuntu Oneiric). (If I had Debian Maintainer privileges, I'd also simultaneously dput to Debian too). I just used release-test, release-build, and release to publish bikeshed-1.15, and captured its log here: * http://paste.ubuntu.com/616969/ These helpers allow me to consistently release dozens of open source projects simultaneously to the current development series of Ubuntu, but also publish "backports" to PPAs of that same package for Lucid/Maverick/Natty. They keep me from making many of the most common mistakes and allow me to upload pretty effortlessly. These scripts are a little Ubuntu/Launchpad/Bzr specific, so I'm not advocating their use to you (Debian), but acknowledging and supporting Ian's suggestion to solve some duplication of effort! -- :-Dustin Dustin Kirkland Ubuntu Core Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikd1xrgsjgotbobhrpih81resl...@mail.gmail.com
Re: RFH: mdadm packaging
On Mon, Feb 16, 2009 at 4:26 AM, martin f krafft wrote: > I am a bit swamped and won't be able to see to the many things that > need to be done with mdadm for squeeze: > > - synchronise the big Ubuntu patch; Dustin Kirkland from Canonical > has expressed interest to cooperate and could help. Hi Martin- Most of the Ubuntu diff is present due to our use of udev for device bringup. Is there roadmap for udev in Debian? :-Dustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: update-rc.d
On Wed, Sep 24, 2008 at 4:45 PM, Kel Modderman <[EMAIL PROTECTED]> wrote: > Ubuntu have added a `service' utility in sysvinit (2.86.ds1-59ubuntu4) ... > Debian could adopt this service utility, or the ideas and code behind service > could be integrated into invoke-rc.d, making it "service-like" as some people > desire: > http://bugs.debian.org/377758 I would gladly port this functionality from Ubuntu to Debian, if the sysvinit maintainers in Debian would have it :-Dustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: update-rc.d
On Mon, Sep 22, 2008 at 1:40 PM, Michael Biebl <[EMAIL PROTECTED]> wrote: > Another idea would be, to define a new update-rc.d function called > "status", which would return either "running, not running or disabled". > There were some efforts recently, to add a status action to the init > scripts, which would be a prerequiste of such a new interface to work > properly. I certainly like this idea, though I think you'd also need another return value of "not implemented", as there are thousands of init scripts out there lacking 'status' actions. Determining if an init script has a status action or not is a pretty crude science. I usually grep for something like "status)" in the init script. Most init scripts that I've encountered implement these actions as case statements, and generally have a case of "status)". That seems to be correct maybe 98% of the time. -- :-Dustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mass bug filing: init script "status" action
Howdy debian-devel- The LSB 3.1 specification [1] defines a 'status' action for LSB-compliant init scripts. Some high-availability (HA) packages included in Debian expect to use a 'status' action as provided by the init script [2] to query daemon status. In general, such 'status' actions in Debian would be broadly useful to both system administrators and users. The lsb-base 3.2-14 package adds a new library function to /lib/lsb/init-functions; namely, status_of_proc() [3,4]. This function can be used in the vast majority of init scripts to generically provide an interface to gathering and reporting status. Individual init script patches often look something like: + status) + status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $? + ;; As an example, see Debian Bug #492138 against rsync and the associated patch [5]. Bug #208010 suggests LSB-compliance of all init scripts in Debian [6]. And Bug #291148 suggests a debian-policy change requiring 'status' actions for all init scripts [7]. I believe that the new functionality present in lsb-base provides a healthy framework for advancing such 'status' actions in a vast number of Debian init scripts. In Ubuntu, we have undertaken an effort to patch as many such init scripts as possible [8]. In most of these cases, we would like to contribute this functionality back to the Debian package. I believe this flow of bugs and patches would qualify as a 'mass bug filing' [9]. So far, we filed a few bugs before it was suggested that we propose this on the debian-devel mailing list: * 492126, 492131, 492138, 492541, 492625 Is it ok to continue filing these requests as wishlist bugs, or is another approach preferred? [1] http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488275 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483285 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490095 [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=rsync.debian.patch;att=1;bug=492138 [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010 [7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291148 [8] https://wiki.ubuntu.com/InitScriptStatusActions [9] http://www.debian.org/doc/developers-reference/beyond-pkging.html#submit-many-bugs -- :-Dustin Dustin Kirkland Ubuntu Server Developer Canonical, LTD [EMAIL PROTECTED] GPG: 1024D/83A61194 signature.asc Description: This is a digitally signed message part
