Re: Deprecating the wiki-based Packaging Guide
Hello, On 18.12.2012 01:52, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. As soon as a branch is out of date, new users are lost. while out-of-date branches and other bits and pieces around UDD are a problem, can we please make them a separate discussion? We can certainly have a discussion about our Development Guide and what we recommend in which way. The reality and motivation of the current discussion is that two guides are simply confusing and that the Wiki documentation hasn't been touched or updated in any meaningful way in ages. I'd suggest we agree on one guide and then figure out what we recommend, rewrite or improve in there. This shouldn't be a blocker for obsoleting one of the guides. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On 12/18/2012 09:23 AM, Daniel Holbach wrote: Hello, On 18.12.2012 01:52, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. As soon as a branch is out of date, new users are lost. while out-of-date branches and other bits and pieces around UDD are a problem, can we please make them a separate discussion? We can certainly have a discussion about our Development Guide and what we recommend in which way. The reality and motivation of the current discussion is that two guides are simply confusing and that the Wiki documentation hasn't been touched or updated in any meaningful way in ages. I'd suggest we agree on one guide and then figure out what we recommend, rewrite or improve in there. This shouldn't be a blocker for obsoleting one of the guides. Have a great day, Daniel I think the point is that the new guide would have to include the pull-lp-source/debdiff/attach to bug route as well before some of us are comfortable deleting that information from the Wiki. It's not so much where it lives as that it's available as a fallback. Thanks, Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Hello, On 18.12.2012 16:35, Micah Gersten wrote: I think the point is that the new guide would have to include the pull-lp-source/debdiff/attach to bug route as well before some of us are comfortable deleting that information from the Wiki. It's not so much where it lives as that it's available as a fallback. It does: http://developer.ubuntu.com/packaging/html/traditional-packaging.html Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging
On 12/18/2012 01:16 AM, Emmet Hikory wrote: Mike Carifio wrote: On 12/17/2012 08:11 PM, Emmet Hikory wrote: Where this is understandably annoying for the application developer is that the recommendation is subject to change over time, as newer tools are developed and adopted: we tend to select toolsets that provide the most automation while leaving us the facility to make local exceptions to standard processing as appropriate for specific packages, which may appear to require an application developer to relearn from scratch every so many years. In practice, the lifecycle of a toolset is typically much longer than the period during which it is the most popular for use, and it is rare for toolsets to be entirely retired (although in some cases the maintainer of the packaging toolset may declare they no longer intend to support it, and it will only live on if someone else is willing to update it to support current policy). As a result, once one learns some means of packaging, one may usually continue with that method for a fairly long time without need to change unless one is excited about new features of a newer toolset. Emmet, thanks for your quick tutorial. It was useful. I would opine that many application developers are more than annoyed, they're lost. So presenting them with all the various variants and then asking them to select the right one based on criteria they neither appreciate nor care about pretty well assures that many will silently walk away. I know I'm saying the same thing a different way, but it bears repeating. As I understand it, policy based packaging just means declarative and declarative means I can state *what* I want and the toolchain will figure out the *how*. I don't find that true in practice, however. I find that I state the what in debian/control, then figure out the how in debian/rules and then figure out why I didn't say it all properly. So I google and find a thicket of various approaches and workflows which only serve to confuse me more. I see packaging as something we want the app developer to do. They have the most knowledge about their application. Given a reasonable bar, I think they will actually do it. After all, they're written the application and they want to see it used. If/when Ubuntu's popularity grows, then the incentive to package will grow. But let us never forget that this is a tax they must bear to integrate into Ubuntu. If the tax is too high, they just won't do it. So we may appreciate a policy-based approach, the richness of many toolchains and so on. But *they* don't, unless it makes their lives easier. Note that I'm not saying that packaging is easy. I'm just saying it can't be a research project for each rookie developer who wants to take a shot at it. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging
Mike Carifio wrote: I would opine that many application developers are more than annoyed, they're lost. So presenting them with all the various variants and then asking them to select the right one based on criteria they neither appreciate nor care about pretty well assures that many will silently walk away. I know I'm saying the same thing a different way, but it bears repeating. Oh, indeed. There should be a simple default method presented for the ease of this audience. My fear is only that if we push too far, we lose the ability to handle exceptions, or fall into painful bikeshedding about the one true way when in practice the judgement should be on the end, rather than the means. As I understand it, policy based packaging just means declarative and declarative means I can state *what* I want and the toolchain will figure out the *how*. I don't find that true in practice, however. I find that I state the what in debian/control, then figure out the how in debian/rules and then figure out why I didn't say it all properly. So I google and find a thicket of various approaches and workflows which only serve to confuse me more. Your understanding matches mine. For purposes of how, I currently believe that the use of /usr/share/doc/debhelper/examples/rules.tiny should be complete from the perspective of application developers: nearly anything else may well indicate issues with the underlying build system. That said, from the perspective of distribution developers, I think it's important to understand debian/rules as something supporting an API for package creation and interaction to support uncooperative, abandoned, or strongly opinionated upstream developers when others are handling the packaging. Ensuring that we can support both audiences from the same documentation is tricky, but it should be our goal. I see packaging as something we want the app developer to do. They have the most knowledge about their application. Given a reasonable bar, I think they will actually do it. After all, they're written the application and they want to see it used. If/when Ubuntu's popularity grows, then the incentive to package will grow. But let us never forget that this is a tax they must bear to integrate into Ubuntu. If the tax is too high, they just won't do it. So we may appreciate a policy-based approach, the richness of many toolchains and so on. But *they* don't, unless it makes their lives easier. Note that I'm not saying that packaging is easy. I'm just saying it can't be a research project for each rookie developer who wants to take a shot at it. There have been many discussions in the past about generating documentation targeted to recommended procedures for build systems and release procedures for application developers to support the ease of packaging. Ideally, it should be possible to generate distribution artifacts that support near automated packaging for a variety of distributions (for debian-format distributions, this reduces to a need to write the Description and review if multiple binary packages are needed from a source artifact). This goes well beyond packaging and much is unlikely to be specific to an individual distribution, but is likely worth constructing, if there are sufficient members of the class of application developers willing to help define the nature of the issue (I'm not convinced it's something that distribution developers can see well enough to write well). Examples of things to address here might be handling init systems, writing man pages, use of .desktop or .service files, ensuring build systems allow for varied build and installation paths, documenting copyright and licensing assertions, modular configuration file handling, and similar issues. In my opinion, it would be best to have this also be a policy-based model, rather than an implementation-based model, but I suspect a simple set of recommendations can be constructed for common toolchains (e.g. If you're writing a desktop GUI in ruby, here's what you want to do to make it easily distributable. If you wrote it in python, you likely want to use this entirely different toolchain to do the same thing.), and that such documentation of best practices for application developers would reduce impression of integration tax, as the volume of effort to package something for a given target is significantly reduced. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging
On 19/12/2012 00:30, Barry Warsaw wrote: I'm positive I'm not typical, but I personally find Ubuntu development so much more pleasant than Debian development that I'll use the Debian branches on Launchpad for 90% of my on Debian work. It's only at the last mile that I'll switch over to e.g. DPMT's or PAPT's svn repo, or file a patch on a BTS ^ That's the issue, you see. Anything's better than svn. I personally use the git-buildpackage suite of things for development locally. For packages not maintained in git, I typically use git import-dsc(s) on downloaded .dsc files before starting work. Debian makes this even nicer by having git import-dscs --debsnap which pulls everything from snapshots.debian.org. I used to maintain some packages in DPMT/PAPT back before I became a DD, but it was such a pain to use SVN that I just moved everything to collab-maint. issue (generated, of course with `bzr diff`). Heck, I'd even accept using git gulp! if Debian had anything as comfortable as UDD for me. There was some talk on debian-devel about having everything on Debian imported into Git repositories, which would probably allow for a somewhat UDD-like workflow for Debian. Unfortunately, I think the usual debian-devel flames cut it short. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 03:16:13PM +0900, Emmet Hikory wrote: While it may appear that way at first glance, this is very much an intentional consequence of policy-based packaging, which Ubuntu inherits from Debian. By having packaging judged against policy, rather than against some arbitrary implementation, we are free to continuously innovate in our use of tools to improve our packaging. Innovations that lead to interesting consequences frequently become policy, such that all other packaging toolchains in the archive are expected to support the expected results (or be retired). However, as this has been an ongoing process of competitive improvement of the several toolchains over more than 20 years, and as many packages have not been updated in some time (this may be by design: e.g. mpi-specs, which likely won't be updated for many more years to come), and many how to package documents are floating around the internet, this means that every possible experimental means of packaging is documented somewhere (and may show up in your favorite search engine), and many of them are used for packages extant in the current archive. There is definitely a set of tools that are currently the most popular in the Debian archive, and these integrate well with a set of tools being developed under the Ubuntu Distributed Development moniker, which combination may well likely be that which is recommended by the Ubuntu Packaging Guide under development: as such, this recommendation [0] is what ought be followed by the class of developers for whom packaging is a means to an end (as they are often focused on a specific piece of software). For folk who might focus on packaging as an end, preferring the role of distribution developer to that of application developer, there is a need for a greater understanding of the underlying policy and the massive variety of tools by which this policy may be implemented. People who are aiming to contribute to Ubuntu as a distribution absolutely need to master a different set of skills than those who just want to package up their own software. In terms of developer documentation, I think the important goals are that: - We make sure everyone has a handle on the second category before they tackle the first category. - We avoid annoying or distracting developers who only care about the second category with information that's only relevant in the first category. - We ensure that developers who are looking to participate in Ubuntu development can find the information they need from the same entry point. - We ensure that the recommendations that we're giving developers for creating packages for their software aren't at odds with the consensus among experienced Ubuntu developers about how a package should look. I think the current Ubuntu Packaging Guide is doing a reasonably good job of walking this line. Where it isn't, I'm sure bug reports are welcome. Where this is understandably annoying for the application developer is that the recommendation is subject to change over time, as newer tools are developed and adopted: we tend to select toolsets that provide the most automation while leaving us the facility to make local exceptions to standard processing as appropriate for specific packages, which may appear to require an application developer to relearn from scratch every so many years. In practice, the lifecycle of a toolset is typically much longer than the period during which it is the most popular for use, and it is rare for toolsets to be entirely retired (although in some cases the maintainer of the packaging toolset may declare they no longer intend to support it, and it will only live on if someone else is willing to update it to support current policy). As a result, once one learns some means of packaging, one may usually continue with that method for a fairly long time without need to change unless one is excited about new features of a newer toolset. Where package tooling has changed recently, it has mostly been about incremental improvements rather than revolutionary changes. At the packaging level, http://people.debian.org/~cjwatson/dhstats.png shows that dh(1) has had dominant mindshare for over 3 years (shown by the constant growth in usage), and if it doesn't quite yet represent the way the majority of packages in the archive are done, this has more to do with the inertia of existing packages than with any lack of consensus. Prior to the advent of dh(1), there *was* a distinct lack of consensus, with developers divided roughly equally between cdbs and debhelper camps. So I do think it's important that any documentation that's teaching people how to package focus on dh, and explicitly relegate non-dh packaging to the category of here's what to do if you need to work on an existing package that doesn't follow best practices. UDD poses a different set of problems. I'm not sure how
Re: Deprecating the wiki-based Packaging Guide
Mike Carifio cari...@usys.com wrote: On 12/18/2012 05:48 PM, Scott Kitterman wrote: Barry Warsaw ba...@ubuntu.com wrote: On Dec 17, 2012, at 07:52 PM, Scott Kitterman wrote: UDD is not mature or reliable enough to be presented to new users as the way to do packaging for Ubuntu. I think the current guide is fatally flawed as is. Yes, it's frustrating when you need to work on a package that has import failures, and yes, I wish we had more cycles to devote to fixing this, but the majority of packages import just fine, and UDD (IMHO and YMMV) has enormous benefits which outweigh those frustrations. Of course, I'm not saying that traditional packaging shouldn't also be described. -Barry It seems obvious to me that the standard approach ought to be the reliable one. Making the UDD based approach 'normal' ensures people need to know two ways to do it and for introductory material, I think that is clearly suboptimal. Also, I think the benefits primarily accrue to people that use UDD a lot. The benefits to people that don't use it quite regularly are minimal. This reinforces the idea it's not the right default to present. Finally, it's a more complex toolset that raises the barrier to entry for newcomers. I don't think that's what we want. Scott K I don't mean to be argumentative, but none of that seems obvious to me. If UDD is a better workflow when it works, then fix it until it works. Then describe it so it makes sense. Then use it consistently to improve the ecosystem. That will make it the default. Right now, we seem to have to work with debian source packages so we can feed the build system but work with a version control system to upstream changes in a productive way. That seems suboptimal too. I'm the first person to admit that I probably don't get it yet or see the obstacles to UDD utopia. But not using a version control tool for a source code control problem doesn't make sense either. Downloading a Debian source package or even a source package and a Debian only bzr branch (as the Kubuntu team does) is much faster than downloading full source bzr branches. Unless someone works with a specific package routinely, full source branches slow the process up significantly. I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa Go figure that one out (yes, I understand it and why, but I think it's a user hostile interface design). The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. The people you see advocating that UDD has great advantage for them are ~all people who do this full time and can live in the UDD environment. They aren't the target audience for the packaging guide. I think the lack of reliability argument is sufficient for now to make the case that UDD should not be the 'normal' method taught to new people. Even if that weren't the case though, I would still think the added leaving curve coupled with creating a barrier to collaboration with our primary upstream would mean it's still not a good idea. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. The Kubuntu team does not use it and last I checked Ubuntu Desktop didn't either. There are people the use UDD, of course, but also large numbers that don't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Tue, Dec 18, 2012 at 09:09:39PM -0500, Scott Kitterman wrote: I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa 'bzr bd -- -S -sa' works equally well, and could be the usage recommended in the documentation for consistency. The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)
On Tue, Dec 18, 2012 at 09:19:31PM -0500, Scott Kitterman wrote: Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 02:08:04AM -0500, Scott Kitterman wrote: 1. While there are sponsors that prefer branches over debdiffs/source packages uploaded somewhere, I don't know of any that will only sponsor branches. The reverse is not true. There are developers that don't do UDD sponsoring. By pursuing this path, new packagers limit the potential candidates to sponsor packages. If there is a consensus that new packagers should be using UDD, we shouldn't let that consensus be held hostage by dissenters that refuse to use UDD. But as per my previous message, I agree that UDD reliability here is a major problem, and no one is well served by developer documentation describing a non-existent utopia instead of the way things actually are. I don't think such a consensus, outside of the small group of people that invested time in the packaging guide, exists. There may or may not be such a consensus. But the consensus is what matters, and the above argument is therefore irrelevant to whether UDD should be the recommended workflow. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 09:09:39PM -0500, Scott Kitterman wrote: I find the interfaces to the UDD tools very confusing. Here's but one example (yes, I filed a bug, no I don't recall the number): The basic dpkg-buildpackage command to build a source package that will include the upstream tarball in the upload is: dpkg-buildpackage -S -sa For the non-UDD dpkg-buildpackage wrapper debuild, one attaches dpkg-buildpackage options on the end and they are passed to dpkg-buildpackage: debuild -S -sa bzr-builddeb has this interface: bzr-builddeb -S -- -sa 'bzr bd -- -S -sa' works equally well, and could be the usage recommended in the documentation for consistency. The biggest benefit of UDD, IMO is that each upload is imported into a VCS so we have per upload history. That happens no matter how the package is built or uploaded. All the additional complexity of committing to the VCS and getting that merged has very minimal benefits for the average developer. One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. I should clarify here that I meant a merge of a new upstream version packaged in Debian. For packaging-only merges, debdiffs work fine. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek steve.langa...@ubuntu.com wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: One concrete example where UDD shines and the non-UDD workflow is inadequate is for sponsoring of package merges. If someone hands me a branch that properly merges the new Debian version into the Ubuntu branch, I can review that with the standard bzr diff tools and ascertain that the sponsoree has done the merge correctly. If someone hands me a debdiff for a Debian merge, that's useless; I effectively have to do the merge myself as part of the review, and no time is saved. I should clarify here that I meant a merge of a new upstream version packaged in Debian. For packaging-only merges, debdiffs work fine. It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. Right. What I really want (and what our docs asked for at one point) is a packaging diff (debian dir) and a pointer to the upstream tarball. I said the branch would be useless to me, because I'd have to extract out the packaging diff and redo the merge to make sense of it. BTW, I didn't come to my perspective on UDD without trying it.I gave it a real go, but it just didn't work for me. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. This exchange leaves me even further confused about how UDD works, but reviewing merges for new upstream sources has always been a bit fussy, and while interdiffs of diff.gz worked reasonably for format:1.0 packages, there is no useful equivalent for format:3.0 packages. When I'm attempting to review someone else's merge, I generally want them to send me enough information that I can produce their candidate artifacts locally for upload, and generally want to do so in a way that reduces the opportunity for them to submit files that don't match history (either previously in Ubuntu or in Debian). My review tends to consist of looking at the prior Ubuntu-only changes, looking at the upstream changes, looking at any changes beyond the new upstream version from Debian, and ensuring that the resulting artifacts contain the best possible blend of all of these (possibly combined with fixes for other outstanding bugs found in Ubuntu). With a non-UDD workflow, this involves getting the outstanding Ubuntu diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want to download source artifacts and run locally), getting the Debian diff (also available from merges.ubuntu.com), and some artifact diff (which could be that presented for sponsoring, although I tend to generate local artifacts and regenerate the diff). If I want to separate distribution changes and upstream changes, filterdiff can help, or I can run diffs only against contents of debian.tar.gz (or other selected artifacts). With a UDD workflow, this involves getting the candidate branch, reviewing the history to confirm it inherits from preexisting UDD branches, and then using bzr to generate the same set of diffs, for the same level of manual consideration. There are no shortcut pre-generated diffs I can download, but the bzr branch contains everything so there is no need to pull from multiple sources: depending on one's local environment this may be either good or bad in terms of total bandwidth and processing requirements (and one can convince launchpad to generate the diffs, if one is sufficiently motivated and lacks local processing facilities). In either case, once I have a local artifact, unless I'm dealing with a package that is handled by some team that doesn't like it, I can just upload. When I'm dealing with packages where teams want special things done, regardless of which solution I choose above, I need to go fiddle with their special VCS arrangements or get complained at later. Now, it may be that in one of my summaries above, I've mischaracterised one of the workflows, and if so I'd very much like to read an expansion of both procedures by someone who has a very strong preference for one or another workflow based on what they consider to be the user experience. On the other hand, if I've not mischaracterised it, how can *either* the branch or the necessary diff to generate candidate artifacts be useless? While I don't personally see any benefit of one over the other except in terms of access speed to review materials (which depends on sufficient local factors that it isn't likely to be generally applicable), I don't understand how I would have to redo the merge in either case, how I would be able to perform the necessary level of scrutiny of the candidate without reviewing the same set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor, candidate-to-debian, new-upstream-to-old-upstream), nor why I would need to perform any file editing or reconcillation as part of this review. Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Steve Langasek wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. This exchange leaves me even further confused about how UDD works, but reviewing merges for new upstream sources has always been a bit fussy, and while interdiffs of diff.gz worked reasonably for format:1.0 packages, there is no useful equivalent for format:3.0 packages. When I'm attempting to review someone else's merge, I generally want them to send me enough information that I can produce their candidate artifacts locally for upload, and generally want to do so in a way that reduces the opportunity for them to submit files that don't match history (either previously in Ubuntu or in Debian). My review tends to consist of looking at the prior Ubuntu-only changes, looking at the upstream changes, looking at any changes beyond the new upstream version from Debian, and ensuring that the resulting artifacts contain the best possible blend of all of these (possibly combined with fixes for other outstanding bugs found in Ubuntu). With a non-UDD workflow, this involves getting the outstanding Ubuntu diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want to download source artifacts and run locally), getting the Debian diff (also available from merges.ubuntu.com), and some artifact diff (which could be that presented for sponsoring, although I tend to generate local artifacts and regenerate the diff). If I want to separate distribution changes and upstream changes, filterdiff can help, or I can run diffs only against contents of debian.tar.gz (or other selected artifacts). With a UDD workflow, this involves getting the candidate branch, reviewing the history to confirm it inherits from preexisting UDD branches, and then using bzr to generate the same set of diffs, for the same level of manual consideration. There are no shortcut pre-generated diffs I can download, but the bzr branch contains everything so there is no need to pull from multiple sources: depending on one's local environment this may be either good or bad in terms of total bandwidth and processing requirements (and one can convince launchpad to generate the diffs, if one is sufficiently motivated and lacks local processing facilities). In either case, once I have a local artifact, unless I'm dealing with a package that is handled by some team that doesn't like it, I can just upload. When I'm dealing with packages where teams want special things done, regardless of which solution I choose above, I need to go fiddle with their special VCS arrangements or get complained at later. Now, it may be that in one of my summaries above, I've mischaracterised one of the workflows, and if so I'd very much like to read an expansion of both procedures by someone who has a very strong preference for one or another workflow based on what they consider to be the user experience. On the other hand, if I've not mischaracterised it, how can *either* the branch or the necessary diff to generate candidate artifacts be useless? While I don't personally see any benefit of one over the other except in terms of access speed to review materials (which depends on sufficient local factors that it isn't likely to be generally applicable), I don't understand how I would have to redo the merge in either case, how I would be able to perform the necessary level of scrutiny of the candidate without reviewing the same set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor, candidate-to-debian, new-upstream-to-old-upstream), nor why I would need to perform any file editing or reconcillation as part of this review. Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
On Wednesday, December 19, 2012 02:02:58 PM Emmet Hikory wrote: Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. It's been some time since I tried this, so i don't recall. I don't see how it can beat grab-merge $PACKAGE and an appropriate packaging diff in a bug for simplicity. When I use grab-merge there's everything I need sitting there is a directory ready for me to use. No hunting for diffs or branches needed. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Deprecating the wiki-based Packaging Guide
Steve Langasek [2012-12-18 18:40 -0800]: A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. A debdiff between the current Debian and the merged Ubuntu package can be compared directly to the current Ubuntu delta on MoM, and simply calling debdiff against the current version in Ubuntun gives you the U-U debdiff. I find neither operation significantly harder than the two bzr diff commands, and bandwith-wise they are roughly comparable, too. So I disagree that they are useless. What I find useless rather are trivial merges where Ubuntu's delta is just one line in debian/control. Doing the merge yourself vs. sponsoring one take the same time. (They still might be an opportunity to learn for new contributors). But if it's a complex merge and the merge actually went through the effort of cleaning up and upstreaming patches etc., I appreciate them a lot, and the D-U debdiff is the distillation of that work. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Misc problems with quantal
On Mon, Dec 17, 2012 at 7:37 PM, Dale Amon a...@vnl.com wrote: Second, I am getting hit with a blinking screen even in virtual terminals on a quantal amd64 server build. Terminal is an ADI ProVista attached to a KVM. Eventually the screen seems to go to sleep and I cannot get it to ever come back. I have modified /etc/default/grub to get # Uncomment to disable graphical terminal (grub-pc only) GRUB_TERMINAL=console which I assumed would shut off any graphical silliness, but it seems to have had no affect. Try GRUB_GFXPAYLOAD_LINUX=text. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Misc problems with quantal
On Tue, Dec 18, 2012 at 12:53:46AM +, Dmitrijs Ledkovs wrote: On 18 December 2012 00:37, Dale Amon a...@vnl.com wrote: A couple broken items in quantal... First off, I also have been bit by the dselect problem discussed in https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1066847 I always use dselect unless I am only installing one or two packages. I just do not particularly like aptitude, etc. As noted in the bug report dselect does not work with multi-arch. Either write patches to dselect to make it support multi-arch, or disable multi-arch, or use a different package management tool. Each of these proposals has advantages drawbacks. The first one is universally best, but requires significant technical work. The latter two, are compromises one way or another. How and where do I disable multi-arch? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Misc problems with quantal
On 18 December 2012 20:18, Dale Amon a...@vnl.com wrote: On Tue, Dec 18, 2012 at 12:53:46AM +, Dmitrijs Ledkovs wrote: On 18 December 2012 00:37, Dale Amon a...@vnl.com wrote: A couple broken items in quantal... First off, I also have been bit by the dselect problem discussed in https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1066847 I always use dselect unless I am only installing one or two packages. I just do not particularly like aptitude, etc. As noted in the bug report dselect does not work with multi-arch. Either write patches to dselect to make it support multi-arch, or disable multi-arch, or use a different package management tool. Each of these proposals has advantages drawbacks. The first one is universally best, but requires significant technical work. The latter two, are compromises one way or another. How and where do I disable multi-arch? Depending on which release you are on, use either first or second answer: http://askubuntu.com/questions/66875/how-to-disable-multiarch-support Please use google first next time. Regards, Dmitrijs. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Misc problems with quantal
On Tue, Dec 18, 2012 at 09:05:22PM +, Dmitrijs Ledkovs wrote: On 18 December 2012 20:18, Dale Amon a...@vnl.com wrote: How and where do I disable multi-arch? Depending on which release you are on, use either first or second answer: http://askubuntu.com/questions/66875/how-to-disable-multiarch-support The file named in the first method did not exist; however the second method worked nicely. # dpkg -l | grep i386 # dpkg --remove-architecture i386 There were no i386 files to remove. Thank you for the link. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
