Bug#542106: ITP: promoe -- gui client for xmms2
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@ubuntu.com * Package name: promoe Version : 0.1 Upstream Author : Thomas Frauendorfer thomas.frauendor...@googlemail.com * URL : http://wiki.xmms2.xmms.se/wiki/Client:Promoe * License : GPL v2 Programming Lang: C++ Description : gui client for xmms2 Promoe is a client for the xmms2 music daemon. Promoe’s interface is modeled after XMMS/WinAMP classic. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608496: ITP: libkibi -- library for byte prefixes
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@debian.org * Package name: libkibi Version : 0.1 Upstream Author : Benjamin Drung benjamin.dr...@gmail.com * URL : https://launchpad.net/libkibi * License : ISC Programming Lang: C Description : library for byte prefixes This library is designed for formatting bytes. The byte prefixes are used depending on the user preferences. Three different types of byte prefixes can be selected: * kB, MB, GB with base 1000 (base10) * KiB, MiB, GiB with base 1024 (base2) * KB, MB, GB with base 1024 (historic) -- 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/20101231131726.11708.56346.report...@localhost6.localdomain6
Re: DEP5: CANDIDATE and ready for use in squeeze+1
Am Sonntag, den 09.01.2011, 14:27 + schrieb Lars Wirzenius: On su, 2011-01-09 at 15:18 +0100, Jakub Wilk wrote: * Lars Wirzenius l...@liw.fi, 2011-01-09, 14:00: [3] http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=153sc=0 If you are interested, please give the spec a quick read. If you find any real problems, it is not too late to get them fixed. Let me see: | Example: | | Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=135 | Upstream-Name: SOFTware | Upstream-Contact: John Doe john@example.com | Source: http://www.example.com/software/project r135 is quite an old version (and, in fact, this snippet doesn't even follow the r135 syntax). Oh, right. I haven't updated those Format: examples, yet, since there is no good URL to update them to. Updating to specific revisions in SVN is bad. Once the spec is incorporated into the debian-policy package, we can have a nice stable URL, which will change whenever the spec changes. But I guess I could change the rev=135 url to rev=153 for now, to avoid confusion. change to rev=154 (which will be the revision with the fixed revision). ;) I am playing with the idea to write python script (using python-debian) which parses debian/copyright and do some useful stuff. For example wrap-and-sort could format it nicely. Having some glue code for software-center would be nice. Third idea is to write a checker tool that compares debian/copyright with the file headers (licensecheck output). The Files field contains a space separated files list. What to do if the file name contains a space? How should this space escaped? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Bug#613306: ITP: portsmf -- Portable Standard Midi File Library
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@debian.org * Package name: portsmf Version : 0.1~svn20101010 Upstream Author : Roger B. Dannenberg * URL : http://portmedia.sourceforge.net/ * License : Expat Programming Lang: C++ Description : Portable Standard Midi File Library Portsmf is Port Standard MIDI File, a cross-platform, C++ library for reading and writing Standard MIDI Files. . Features: . - input and output of Standard MIDI Files - data structures, classes, etc. for representing music data in memory o sequence structure consisting of multiple tracks o track structure consisting of multiple events o events contain note and control data o extensible attribute-value property lists o tempo track and time signature representation - input and output of a text-based representation: Allegro files - extensive editing operations on sequences and tracks - conversion to/from binary buffers for archiving, undo/redo, etc. -- 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/20110213230656.1077.21059.reportbug@localhost6.localdomain6
Bug#613517: ITP: libsbsms -- Subband Sinusoidal Modeling Synthesis
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@debian.org * Package name: libsbsms Version : 1.7.0 Upstream Author : Clayton Otey o...@users.sourceforge.net * URL : http://sbsms.sourceforge.net/ * License : GPL2 Programming Lang: C++ Description : Subband Sinusoidal Modeling Synthesis libsbsms is a C++ library for high quality time stretching and pitch scaling of audio. It uses octave subband sinusoidal modeling. The audio is fed into a FIFO, which takes the STFT of the input. Each frame is high-pass filtered in the Fourier domain, and then written to a frame FIFO which does quadratic interpolating peak detection and track continuation. The tracks are resynthesized with a quadratic phase preserving oscillator bank at an arbitrary time scale. The subbands are fed from the low-pass filtered frames, which are decimated by two and reconstructed in a half rate time domain. The subbands perform the same process as the parent band, only the data is at half the audio frequency, and at half the rate. There are typically 6 bands. The point of subbands is to allow high time resolution for high frequencies and at the same time high frequency resolution for low frequencies. Pitch scaling is performed in a post-processing resampling step. -- 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/20110215124525.5084.47114.reportbug@localhost6.localdomain6
Re: What should we do with iceweasel/xulrunner/libmozjs?
Am Freitag, den 18.02.2011, 10:12 +0100 schrieb Mike Hommey: Hi, Now that squeeze is released, it's time to start pushing new things to unstable. I've been asked several times already how things would be evolving in the near future, to which I answered it would quite stay the way it is now until upstream releases 4.0, at which point I'd upload 4.0 to unstable. But that might change. And I'm hereby requesting feedback on what fellow developers (especially maintainers of the various reverse dependencies) think about them. Here are some of the available options: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Pros: More exposure for the 3.6 and 4.0 packages. Cons: More work for reverse dependencies, which would be made to build and work with 3.6 and then again with 4.0 in a few weeks. Last time I checked (which was 3 months ago), 4.0 doesn't work on s390, sparc and ia64, which would make problems. - Keep things the way they are (3.5 in unstable, 3.6 in experimental, 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's released. Pros: we don't need to make sure everything in unstable builds and works properly with 3.6 before doing the work again with 4.0 in a month or so. Cons: Broken architectures with 4.0. - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. Pros: We don't break anything in testing/unstable, and we don't have to deal immediately with the broken architectures. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. - Keep everything in place, prepare rdeps to build and work with 4.0, and push 4.0 to unstable when everything is ready. Pros: We don't break anything in testing/unstable, and when 4.0 lands on unstable, nothing breaks either. Cons: Past experience shows that it takes a lot of time to fix rdeps. My gut feeling is that breaking things in unstable would create an incentive to fix, which doesn't exist when the package is in experimental or worse, outside the archive. - Suggest your own if you have better ideas (really, I mean it). As I mentioned above, my initial idea was to go with the second option, breaking most rdeps in the process, but then I remembered that 4.0 doesn't work on all our architectures, and I'm hesitating, now. So, fellow developers, what do you think? I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Upcoming changes in Lintian some bits
Am Donnerstag, den 24.02.2011, 08:16 +0100 schrieb Yves-Alexis Perez: On Wed, 2011-02-23 at 22:47 -0600, Raphael Geissert wrote: As a consequence of these changes, the new Lintian release will cause many existing overrides to no longer apply. We recognise that this will lead to some noise in the short term but are convinced that the longer term advantages make this worthwhile. Did you do an archive check with the new lintian and diff'ed it against a check with previous lintian? Please do a complete archive check on lintian.debian.org. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
new scripts and patches for devscripts
Hi, I have two topics I like to discuss: 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful only for Ubuntu, but some of them are general usable for packaging. These scripts are: add-patch check-symbols cowbuilder-dist debian-distro-info distro-info edit-patch get-build-deps merge-changelog mk-sbuild pbuilder-dist pull-debian-source (?) reverse-build-depends suspicious-source what-patch wrap-and-sort Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. 2. devscripts appears to me not very well maintained. It has 11 uploaders, but 237 bugs are open. In contrast ubuntu-dev-tools, which has a similar count of scripts, has only around 50 open bugs. The more astonishing number is the 45 patches waiting to be reviewed. What can be done to improve this number? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful only for Ubuntu, but some of them are general usable for packaging. These scripts are: mk-sbuild Speaking just for this script, it's a user-friendly wrapper around sbuild/schroot to do initial setup, including package installation and chroot creation. However, it's very Ubuntu-specific. Rather than copy the script, even with the Ubuntu-specifics taken out, I'd rather integrate select pieces into sbuild proper such as into sbuild-createchroot. If the other scripts are of a similar nature, I don't think they are suitable with significant modification; it may be worth looking at correcting the deficiencies in the tools they wrap. Maybe one or two. For example suspicious-source and wrap-and-sort are good candidates for devscripts. Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. Most of the scripts are short. Rewriting would be fairly simple, and may be beneficial in removing the Ubuntu-specific bits. What speaks against having these script in python? Is python too heavy for a _development_ machine? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 16:42 + schrieb Ian Jackson: Benjamin Drung writes (new scripts and patches for devscripts): 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful only for Ubuntu, but some of them are general usable for packaging. These scripts are: add-patch check-symbols cowbuilder-dist debian-distro-info distro-info edit-patch get-build-deps merge-changelog mk-sbuild pbuilder-dist pull-debian-source (?) reverse-build-depends suspicious-source what-patch wrap-and-sort Almost all of these are very poorly named. Better name suggestions are welcome. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung bdr...@debian.org wrote: Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. Most of the scripts are short. Rewriting would be fairly simple, and may be beneficial in removing the Ubuntu-specific bits. What speaks against having these script in python? Is python too heavy for a _development_ machine? It's not just about a package dependency. It's more about restricting the knowledge base required for those maintaining the package. Considering that scripts are contributed to devscripts and the support burden is then commonly left on the shoulders of those maintaining devscripts instead of the original script author, it's in our interest to maintain a consistent set of languages that we are willing to support. This is currently Perl and shell. So yes, IMO, accepting scripts written in Python (or any other language) is too heavy. Not for a _development_ machine, but for a maintenance team. If people choose to ignore our requirement and develop scripts in other languages, then they can deal with the consequences. Stefano Rivera (stefanor) and I offer to maintain the Python scripts in devscripts. Is it enough to have at two DDs to support Python? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 22:28 + schrieb Ian Jackson: Benjamin Drung writes (Re: new scripts and patches for devscripts): Am Mittwoch, den 09.03.2011, 16:42 + schrieb Ian Jackson: add-patch check-symbols cowbuilder-dist debian-distro-info distro-info edit-patch get-build-deps merge-changelog mk-sbuild pbuilder-dist pull-debian-source (?) reverse-build-depends suspicious-source what-patch wrap-and-sort Almost all of these are very poorly named. Better name suggestions are welcome. udt-* for all applicable *, where udt stands for ubuntu-dev-tools. Why? These scripts are not ubuntu specific. Would you rename all scripts in devscripts for dv-*, where dv stands for devscripts? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Freitag, den 11.03.2011, 00:18 +0100 schrieb Stefano Zacchiroli: On Thu, Mar 10, 2011 at 08:15:22PM +0100, Carsten Hey wrote: James Vega seems to be the most active devscripts maintainer these days, and he does this (as far as I know) in his spare time. If he does not want to have python scripts in it, I see no justification to force him to do so. I also see no reason to try hard to convince him after he clearly stated his point of view. First of all, I'm not sure anymore that I see the point of discussing the *language issue* in a circle larger than the devscripts maintainers. (Disclaimer: although I'm still listed as devscripts uploader, I consider myself in violation of that rule as wall: it's been quite a while since my last significant contribution to the package.) The language issue should probably be a decision within the devscripts team, together with the script proposers. Can we continue to discuss the language issue on debian-devel or should we move the discussion somewhere else? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Donnerstag, den 10.03.2011, 14:34 -0500 schrieb James Vega: On Thu, Mar 10, 2011 at 12:48 PM, Stefano Zacchiroli z...@debian.org wrote: Also, considering we are talking about Python and not, say, my beloved OCaml, I wouldn't be surprised to discover that among active Debian developers we have nowadays more Python knowledge than Perl knowledge (but I'm already regretting starting this potential troll ...). Back to numbers, according to [1] already in Debian 4.0 the number of SLOC in the archive of Python vs Perl was very close (2.5% vs 2.8%) with a strong growing trend for Python. To conclude with an obvious argument, rewriting useful tools which are known to work and which are currently maintained by a derived distro, when they are already written in a popular language, doesn't seem to be the smartest thing to do to me. I completely agree that rewriting the tools isn't a useful effort. I was more concerned that there had been significant development done on scripts that were intended to be proposed to devscripts and yet were intentionally being written in a language that I had previously expressed to Benjamin wasn't used in devscripts. No Python script comes to my mind that was intended to be proposed to devscripts before the language decision was made. add-patch and edit-patch were written in Shell because they were intended to be proposed to devscripts. *-distro-info (formerly *-release-info) were intended to be a stand-alone package when I initially wrote them. After the package was rejected by the ftp-master, I proposed them to devscripts. A while ago I put it into ubuntu-dev-tools after splitting the script into a library and a frontend, because I wanted to use the library in another Python script in ubuntu-dev-tools (sponsor-patch). I'm not categorically opposed to having Python scripts in devscripts, as I do grok Python. My resistance was more due to the process around the proposed contributions and posing the barrier to acceptance as purely an added dependency. Also, while Benjamin and Stefano have offered to support the potential new scripts, how does that help with the existing scripts which Benjamin stated concern about? I was sucked in the ubuntu-dev-tools maintenance due to one script that I wrote. I assume that may happen with devscripts too. Last we spoke, he wasn't comfortable with Perl, so while they may support their scripts within devscripts, how much does it really buy for the devscripts package as a whole? I bough a copy of Learning Perl (translated into my native language). That's at least a starting point. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Donnerstag, den 10.03.2011, 18:32 +0100 schrieb Mehdi Dogguy: On 08/03/2011 23:01, Benjamin Drung wrote: check-symbols I always hated programs that do sudo (and even more those doing it *twice*). And, isn't just unpacking the .deb and checking for .so there enough? You could have undefined symbols… but that may not be an issue most of the time, IMO. (when diffing like in this case). Yes, this script need to be un-Ubuntu-fied. pbuilder-dist cowbuilder-dist mk-sbuild Those could be integrated in pbuilder/cowbuilder/sbuild as examples, IMHO. Good idea. That's even better than devscripts. pull-debian-source (?) apt-get source $src ? Not really, because for apt-get source $src you need an entry in your sources.list. With pull-debian-source $src experimental you get the experimental package, with pull-debian-source $src lenny you get the lenny package, and so on. reverse-build-depends This is build-rdeps, already in devscripts, afaik. Then let's check if some functionality from reverse-build-depends should be merged into build-rdeps. suspicious-source what-patch I thought that the reason for this script to exist is to be used by other scripts (like edit-patch, or add-patch) but it seems like it's not. I'm not even sure that it helps beginners since it hides some very basic information that every new maintainer should learn. Am I wrong here? suspicious-source is a tool to find pre-generated files (files not in the preferred form for editing). what-patch is a fast way to detect the patch system instead of looking in debian/source and checking debian/README.source and debian/control. Every new maintainer should know how to get this information without what-patch. With dpkg-source 3.0 (quilt) format the benefit of this script degrades. Encouraging people to document how they patch their package could be a better initiative, IMHO. Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. I suspect that the number of scripts to be moved is quite low. Moreover, most of them are very simple and can be rewritten very easily. Is rewriting them not an option? Rewriting them needs time and could cause new bugs. There are real benefits. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: More Vcs-Fields in debian/control?
Am Mittwoch, den 06.04.2011, 12:06 +0200 schrieb Evgeni Golov: Hi -devel! We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. Opinions? I like this idea. There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What should we do if we have multiple upstream VCSes? For exapmle, Eclipse has Eclipse and eclipse-build as upstream. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: More Vcs-Fields in debian/control?
Am Mittwoch, den 06.04.2011, 11:39 -0700 schrieb Steve Langasek: On Wed, Apr 06, 2011 at 12:28:39PM +0200, Benjamin Drung wrote: We (lindi, liw and me) had just a short discussion in #-devel, that it would be nice to have some sort of Vcs-Upstream-* in debian/control, to be able to get to upstreams vcs history if it is not imported in debian's vcs (which is often the case when using svn-bp or git-bf with import-orig). [background: lindi is doing some git-copyright checks and it fails heavily if there is no upstream history as the debian maintainer is asumed to be the copyright holder for everything] My suggestion would even go further (attention, I have NO idea how debian/control is parsed and how much work the following would be): Let's make that Vcs-Vendor with Vendor (like in DEP3) Debian, Upstream, Ubuntu, Whoever-else-uses-the-packaging. I like this idea. There should be a Vcs-Debian-* too and used in most cases. A package should use Vcs-Debian-* if the vcs is only used in Debian. A package could use Vcs-* if the vcs is used in derived distros too. What do you mean, only used in Debian? Do you expect Debian maintainers to track whether or not downstreams have a separate VCS? No. Simply answer the question: Is this VCS used by derived distros, too? If not, it's Debian only. Two examples: The git repository for apt-mirror is used only for Debian (there's only the master branch). The git repository for vlc is used for Debian and Ubuntu (master branch for Debian sid, squeeze branch for Debian squeeze, ubuntu branch for Ubuntu natty, maverick branch for Ubuntu maverick, and so on). I don't think this is the right way to do it any more than we should rename 'Maintainer' to 'Maintainer-Debian'. If downstreams diverge, it should be up to them to kee the information in debian/control current. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Samstag, den 21.05.2011, 21:41 +0200 schrieb Tshepang Lekhonkhobe: On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote: Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung bdr...@debian.org wrote: Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. Most of the scripts are short. Rewriting would be fairly simple, and may be beneficial in removing the Ubuntu-specific bits. What speaks against having these script in python? Is python too heavy for a _development_ machine? It's not just about a package dependency. It's more about restricting the knowledge base required for those maintaining the package. Considering that scripts are contributed to devscripts and the support burden is then commonly left on the shoulders of those maintaining devscripts instead of the original script author, it's in our interest to maintain a consistent set of languages that we are willing to support. This is currently Perl and shell. So yes, IMO, accepting scripts written in Python (or any other language) is too heavy. Not for a _development_ machine, but for a maintenance team. If people choose to ignore our requirement and develop scripts in other languages, then they can deal with the consequences. Stefano Rivera (stefanor) and I offer to maintain the Python scripts in devscripts. Is it enough to have at two DDs to support Python? Has this issue been resolved? Has this question been answered by devscripts maintainers? We managed to alleviate the concerns / weaken the resistance. The two Python scripts suspicious-source and wrap-and-sort landed in the devscripts git master branch and will be included in the upcoming upload. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
packaging-dev meta package
Hi, A few days ago, we had a discussion in Ubuntu about a packaging-dev meta package. The problem is that users have to install a bunch of packages if they want to dive into packaging. Even some packagers get annoyed when they need to turn a newly installed system into a packaging environment. The solution would be a meta package that depends on the commonly used packages for packaging. As a starting point packaging-dev would depend on build-essential quilt debhelper cmake autoconf cdbs bzr-builddeb apt-file ubuntu-dev-tools (only on Ubuntu systems) Do you like the idea or not? Do you have a better name for the meta package? Should something added to or removed from the dependency list? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packaging-dev meta package
Am Donnerstag, den 26.05.2011, 17:25 -0300 schrieb Fernando Lemos: On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung bdr...@debian.org wrote: Hi, A few days ago, we had a discussion in Ubuntu about a packaging-dev meta package. The problem is that users have to install a bunch of packages if they want to dive into packaging. Even some packagers get annoyed when they need to turn a newly installed system into a packaging environment. The solution would be a meta package that depends on the commonly used packages for packaging. Isn't apt-get build-dep enough? Users can always use equivs for something more specific. apt-get build-dep gets the build dependency for a specific package, but it wont give you devscripts for example. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packaging-dev meta package
Am Donnerstag, den 26.05.2011, 16:33 -0400 schrieb Mackenzie Morgan: On Thu, May 26, 2011 at 4:29 PM, Benjamin Drung bdr...@debian.org wrote: Am Donnerstag, den 26.05.2011, 17:25 -0300 schrieb Fernando Lemos: On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung bdr...@debian.org wrote: Hi, A few days ago, we had a discussion in Ubuntu about a packaging-dev meta package. The problem is that users have to install a bunch of packages if they want to dive into packaging. Even some packagers get annoyed when they need to turn a newly installed system into a packaging environment. The solution would be a meta package that depends on the commonly used packages for packaging. Isn't apt-get build-dep enough? Users can always use equivs for something more specific. apt-get build-dep gets the build dependency for a specific package, but it wont give you devscripts for example. I didn't realise you were going to send a mail to debian-devel too (thought it'd just be ubuntu-devel), so I guess that'd mean make devscripts a direct Rec if it ends up in Debian, because at the moment it was being accounted for as a dependency of u-d-t I thought that we should get the meta package into Debian if the DDs like the idea of it and otherwise get it only into Debian. Right, devscripts should be a direct dependency. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packaging-dev meta package
Am Donnerstag, den 26.05.2011, 22:40 +0200 schrieb gregor herrmann: On Thu, 26 May 2011 22:05:42 +0200, Benjamin Drung wrote: As a starting point packaging-dev would depend on build-essential quilt debhelper cmake autoconf cdbs bzr-builddeb apt-file ubuntu-dev-tools (only on Ubuntu systems) Do you like the idea or not? Do you have a better name for the meta package? Should something added to or removed from the dependency list? I tentatively think the idea is good; I don't really care about the name :) The problem might be that the set of packages is not trivial/uncontroversial; I'm not sure I need cdbs (or cmake), I've never heard about bzr-builddeb, I miss cowbuilder (and also svn-buildpackage and git-buildpackage, and maybe dh-make) ... So yes, the idea is interesting, but the selection of packages might need some consideration :) Then let's put the uncontroversial into Depends, the common (this needs discussion) into Recommends and the others into Suggests. Here's the starting point for discussion: Depends: build-essential debhelper devscripts gnupg lintian dput | dupload quilt ubuntu-dev-tools (only on Ubuntu) pbuilder | cowbuilder Recommends: apt-file autoconf bzr-builddeb (maybe Depends on Ubuntu) svn-buildpackage git-buildpackage dh-make Recommends or Suggests: cdbs cmake -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packaging-dev meta package
Am Donnerstag, den 26.05.2011, 16:46 -0400 schrieb Mackenzie Morgan: On Thu, May 26, 2011 at 4:44 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Keep vcs specific tools (git-buildpackage, bzr-builddeb, svn-buildpackage) in the Recommends field so they are not hard dependencies. The current version of the control field I've got sitting here has build-essential in Depends and the rest in Recommends so people can slim down at-will. Can you upload the version of the package into collab-maint on Alioth? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 25.05.2011, 14:49 +0200 schrieb Tshepang Lekhonkhobe: On Tue, 2011-05-24 at 23:51 +0200, Benjamin Drung wrote: Am Samstag, den 21.05.2011, 21:41 +0200 schrieb Tshepang Lekhonkhobe: On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote: Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung bdr...@debian.org wrote: Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. Most of the scripts are short. Rewriting would be fairly simple, and may be beneficial in removing the Ubuntu-specific bits. What speaks against having these script in python? Is python too heavy for a _development_ machine? It's not just about a package dependency. It's more about restricting the knowledge base required for those maintaining the package. Considering that scripts are contributed to devscripts and the support burden is then commonly left on the shoulders of those maintaining devscripts instead of the original script author, it's in our interest to maintain a consistent set of languages that we are willing to support. This is currently Perl and shell. So yes, IMO, accepting scripts written in Python (or any other language) is too heavy. Not for a _development_ machine, but for a maintenance team. If people choose to ignore our requirement and develop scripts in other languages, then they can deal with the consequences. Stefano Rivera (stefanor) and I offer to maintain the Python scripts in devscripts. Is it enough to have at two DDs to support Python? Has this issue been resolved? Has this question been answered by devscripts maintainers? We managed to alleviate the concerns / weaken the resistance. The two Python scripts suspicious-source and wrap-and-sort landed in the devscripts git master branch and will be included in the upcoming upload. Okay, thanks. What about the rest? Is this discussed some place public? This thread makes it look like there was indecision. What did I miss? The discussion from debian-devel was continued on pkg-devscri...@teams.debian.net and on IRC (#devscripts on OTFC). The scripts that should be moved where discussed at the UDS-o in Budapest [1]. [1] https://blueprints.launchpad.net/ubuntu-dev-tools/+spec/other-o-udt-upstreaming -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packaging-dev meta package
Am Donnerstag, den 26.05.2011, 17:28 -0400 schrieb Mackenzie Morgan: On Thu, May 26, 2011 at 5:14 PM, Russ Allbery r...@debian.org wrote: Mackenzie Morgan maco...@gmail.com writes: On Thu, May 26, 2011 at 4:49 PM, Benjamin Drung bdr...@debian.org wrote: Recommends or Suggests: cdbs cmake My reasoning on these two was that some people probably aren't interested in switching from cdbs to quilt, You mean from cdbs to using debhelper directly? cdbs and quilt are orthogonal to each other. Sorry, yes. The push toward Source Format 3 with Quilt and DH7 happened around the same time that I started doing packaging with any frequency so I'm somewhat muddled on the old way. Do I recall correctly that there was some sort of patch management included in cdbs or am I thinking of another tool? It is an one-liner to add a patch system to a cdbs rules file. You could freely choose between simple-patchsys, quilt and dpatch. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Behaviour of dpkg-source with 3.0 (quilt) and VCS and automatic patches
Am Sonntag, den 29.05.2011, 10:53 +0200 schrieb Raphael Hertzog: Again to cope with the scenario explained at the start of this mail, once a user has made modifications we must ensure that they end up in a proper patch in debian/patches/. Right now this is entirely automatic, the generated patches take the form of debian/patches/debian-changes-ver. Obviously this is a pretty poor name for a patch [...] The file should end with .patch (debian/patches/debian-changes-ver.patch) so that your favorite text editor uses the correct highlighting. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Explicitely Cc bug reporters
Am Donnerstag, den 10.09.2009, 16:09 +0200 schrieb Sandro Tosi: Ideally, I'd imaging nnn...@b.d.o to reach - submitter - maintainers - subscribers We already have -quite if we want to not mail people. Do others feel we should enable emailing the submitter by default? Yes, please email the submitter by default. It would be good if the submitter can unsubscribe himself from the bug report. Cheers, Benjamin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: DEP-5: an example parser, choice of syntax for Files:
Am Sonntag, den 13.09.2009, 23:58 +0100 schrieb Jon Dowland: Most of the examples given in DEP-5 containing the path character will not work, either, e.g. Files: debian/* Assuming they are passed into a find(1) invocation like so find . -path 'debian/*' (note the presence of the path separator and the wording about that in the text) they need to be prefixed with './', even if you omit '.' in the find execution (which itself is a GNUism iirc). Patch attached. You can get rid of those './' by replacing . with *: find * -path 'debian/*' Cheers, Benjamin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Hi, When a new upstream version is released, I have to check all patches if they were accepted by upstream or not. I have to check each patch if I can drop it. It would make packaging new releases easier if there were an optional Applied-Upstream field. Every patch that was applied upstream can be dropped. no or not-yet would indicate that the patch was not applied yet. If the patch was applied, it could contain the revision (like r4681) or a link to the VCS commit. What do you think about my suggestion? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog: Hi, On Mon, 23 Nov 2009, Benjamin Drung wrote: When a new upstream version is released, I have to check all patches if they were accepted by upstream or not. I have to check each patch if I can drop it. It would make packaging new releases easier if there were an optional Applied-Upstream field. Every patch that was applied upstream can be dropped. no or not-yet would indicate that the patch was not applied yet. If the patch was applied, it could contain the revision (like r4681) or a link to the VCS commit. What do you think about my suggestion? I suppose that you would want to add the field as soon as the patch is committed upstream so that you can more easily identify patches to remove when the next upstream version is out? Yes, indeed. Do you expect to automate this operation? Adding the field would be manual, but removing the patches can do a simple script, when the next upstream release is out. I'm not sure we need a new field for this purpose, you could add a comment in the description field or even change the Forwarded: URL to point to the upstream VCS to make it clearer that it got merged. Automating the removal would be hard then. BTW, speaking of DEP-3, someone mentioned that it doesn't tell the encoding to use. Does anyone oppose to adding a note saying that it should aim at being ASCII-only and if that's not possible then UTF-8 should be used? I think that the DEP-3 header should be in UTF-8 (ASCII would be the subset). -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow: Benjamin Drung bdr...@ubuntu.com writes: Hi, When a new upstream version is released, I have to check all patches if they were accepted by upstream or not. I have to check each patch if I can drop it. It would make packaging new releases easier if there were an optional Applied-Upstream field. Every patch that was applied upstream can be dropped. no or not-yet would indicate that the patch was not applied yet. If the patch was applied, it could contain the revision (like r4681) or a link to the VCS commit. What do you think about my suggestion? Why would the source (or VCS head) ever contain a patch that was applied upstream? The moment the patch gets applied you simply remove it. Not until the next upstream release. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
How to use binutils-gold
Hi, I got some FTBFS with binutils-gold bug reports. How can I build my packages using binutils-gold? What do I have to change for that? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#559761: ITP: release -- provides information about the current releases
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@ubuntu.com * Package name: release Version : 0.1 (native) Upstream Author : Benjamin Drung bdr...@ubuntu.com * License : GPL v3+ Programming Lang: Python Description : provides information about the current releases This package contains information about all releases of Debian and Ubuntu. The release script will give you the codename for e.g. the latest stable release of your distribution. To get information about a specific distribution there are the debian-release and the ubuntu-release scripts. It's based on the idea posted on the ubuntu-devel-discuss mailing list [1]. Comments, suggestions and feature requests are highly welcome. For Debian I need some informations: Until when were following releases supported: buzz, rex, bo, hamm, slink, and potato? [1] http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09951.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Am Dienstag, den 08.12.2009, 16:56 +0100 schrieb Thomas Koch:
Hi,
I'm triing to package a little java library, which contains its own .jar and
some pregenerated docs. These files should be regenerated on build time. So
I'd like to have them removed by diff.gz
Trying to generate an appropriate quilt patch failed. The only thing I came
up
with, was a patch that contains the whole content of the removed files with -
before every line.
Anybody more clever then me?
I know that dpatch allows the execution of shell scripts. This would be
ideal.
I'd just do find . -name *.jar -exec rm {} \;
But also a patch which contains just the names of the files to be removed and
not the whole content would suffice.
Putting 'find . -name *.jar -delete' in you clean rule should do the
same job for you.
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
* Package name: release
The tool isn't about releasing, but about to querying the release. Also,
it's about distribution release (not package...). May be a name like
{get|query}-distr[o]?-release... or something completely different like
supported-distro would be more explicit.
Yes, the name is a bit to generic. Any other suggestions for the name?
On the mailing list I found 'release-info'. On my list are now:
* release-info
* distro-release-info
* distro-releases
Any preferred name or suggestions?
Should i rename the scripts, too?
Description : provides information about the current releases
This package contains information about all releases of Debian and Ubuntu.
The
release script will give you the codename for e.g. the latest stable
release of
your distribution.
There was some discussions about a similar tool issues:
http://lists.debian.org/debian-devel/2007/05/msg01138.html
and to query Debian point release.
http://lists.debian.org/debian-devel/2007/12/msg00742.html
The topic of these discussions were slightly different. The release
packages does not know anything about the running release. It only needs
a date (and up-to-date data) for calculating the result.
To get information about a specific distribution there are
the debian-release and the ubuntu-release scripts.
I suppose you mean that there will be different back-end script.
(I suppose that you don't mean that each program will have to implement
a select/case algorithm?)
Yes, there are different back-end scripts. Due to different release
models the both scripts use different algorithms. The distro data are
stored in cvs files (like a table) and then I throw a little bit of
Python on it. Subtracting the command line parsing only 60 lines of code
are required.
It's based on the idea posted on the ubuntu-devel-discuss mailing list
[1]. Comments, suggestions and feature requests are highly welcome.
For Debian I need some informations: Until when were following
releases supported: buzz, rex, bo, hamm, slink, and potato?
See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
information for bo/rex/buzz. Anyone ?
I found that page, too. The wikipedia page of Debian did not contain
more information.
AFAIK, Debian have never supported more than two stable distributions
(stable + old-stable), therefore, you can assume that a distribution end
of life is lower than distribution N+2 release.
I used this algorithm to calculate the support dates until we find
something more precise.
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Mittwoch, den 09.12.2009, 09:34 +0800 schrieb Paul Wise: On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung bdr...@ubuntu.com wrote: Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT: On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote: For Debian I need some informations: Until when were following releases supported: buzz, rex, bo, hamm, slink, and potato? See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the information for bo/rex/buzz. Anyone ? I found that page, too. The wikipedia page of Debian did not contain more information. Try the debian-history package or its maintainer. I could not find information about the support period in this package. Bdale, do you have more information? Am Mittwoch, den 09.12.2009, 15:05 +0100 schrieb Javier Fernandez-Sanguino: The proper source for this information is the Project History document, available online at http://www.debian.org/doc/manuals/project-history/ch-releases.en.html or in the debian-history package. I could not find end of live dates on this website. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
To sum up the naming discussion, there are two possible package names: * distro-release-info * release-info The two distro-specific script will be named debian-release-info and ubuntu-release-info. I tend to name the package distro-release-info and the symlinked script release-info. Any preferences, suggestions, or objections? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Freitag, den 11.12.2009, 09:17 +0100 schrieb Frank Lin PIAT: On Fri, 2009-12-11 at 00:09 +0100, Benjamin Drung wrote: To sum up the naming discussion, there are two possible package names: * distro-release-info * release-info The two distro-specific script will be named debian-release-info and ubuntu-release-info. I tend to name the package distro-release-info and the symlinked script release-info. The distro specific script should be in /usr/share/release-info/. No. If I want to know the current stable release of Debian, I have to run 'debian-release-info -s' regardless which os/distro I run. If the distribution specific scripts are in the path, people may tend to use them, which isn't portable because one needs to know the local distribution before invoking the script. It depends on the purpose. Portable scripts have to use release-info, but distribution specific scripts can use $distro-release-info. Also, it you be nice if your script was easily extensible by Debian and Ubuntu derivatives. Every derivative can add their own $distro-release-info script. Having one generic script for all distributions would not work, because there is not _one_ release policy for all. BTW, did you notice that the DebianRelease[1] wiki page has a link per distribution release, with EOL dates (?) Yes, but for buzz to hamm (1.1 to 2.0) the EOL dates are missing. I just have a feature request: add some --foobar-url options, which would return some official urls about that distribution: * Info and support (http://www.debian.org/releases/lenny/ ) * Release Notes (http://www.debian.org/releases/lenny/releasenotes ) * Errata (http://www.debian.org/releases/stable/errata ) * Installation Guide (http://www.debian.org/releases/lenny/installmanual ) Do you have a use case for that? If you want to know these URLs for the current installed distro, you can use lsb_release instead: http://www.debian.org/releases/$(lsb_release -cs)/ http://www.debian.org/releases/$(lsb_release -cs)/releasenotes We would need the equivalent URLs for Ubuntu. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Freitag, den 11.12.2009, 15:57 -0600 schrieb Peter Samuelson: [Benjamin Drung] Yes, the name is a bit to generic. Any other suggestions for the name? On the mailing list I found 'release-info'. On my list are now: * release-info * distro-release-info * distro-releases I'd go with 'os-release'. Mostly because I hate the word 'distro'. To avoid the distro/os discussion, I will use release-info as package name. It's short and not too generic. Unix tradition is to have a bit of OS release info in one flag of 'uname' or another, but of course on Linux, where the kernel and the userland are fairly decoupled, this makes less sense. (Also, one might think /usr/share/misc/config.guess could say whether we're on debian or ubuntu ... but it doesn't.) -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#562217: ITP: jdownloader -- download manager for one-click hosting sites
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@ubuntu.com * Package name: jdownloader Version : 0.1 Upstream Author : JDownloader DEV-Team supp...@jdownloader.org * URL : http://jdownloader.org/ * License : GPL-3 Programming Lang: Java Description : download manager for one-click hosting sites JDownloader is open source, platform independent and written completely in Java. It simplifies downloading files from One-Click-Hosters like Rapidshare.com or Megaupload.com - not only for users with a premium account but also for users who don't pay. It offers downloading in multiple paralell streams, captcha recognition, automatical file extraction and much more. Of course, JDownloader is absolutely free of charge. Additionally, many link encryption sites are supported - so you just paste the encrypted links and JD does the rest. JDownloader can import CCF, RSDF and the new DLC files. . This package contains only a dektop file and a script, which will download and launch the current JDownloader. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche: Hi folks, How to deal with a desktop-command-not-in-package lintian warning when a .desktop file in a common package B references a binary in package A ? Typically the package A used to contain static/arch-independent data which was splitted to a B common package to comply with debian packaging rules (to limit the size of architecture-dependent packages). Solution 1: consider the warning a false positive and ignore it Solution 2: pull back the destop command in the arch-dependent package Solution 2 is the correct answer. (I can not reverse the dependencies, because A _do_ depends on data in B.) First I thought it would be a strange warning, but then I understood it. Imagine that you install only the data package B, which contains the desktop file. Then you have a desktop icon, but you cannot launch the application. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bits from the Mozilla Extension Packaging Team
Hi, This mail targets all developers, which maintain Mozilla extensions. Source package name === The source package name for extension should not contain the name of the enhanced application. These prefixes should be dropped from the source name: firefox- iceape- icedove- iceweasel- mozilla- thunderbird- If the remaining string is too generic (for example, notify or sage), the source package name should append -extension. For example, firefoxnotify was renamed to notify-extension. Binary package name === The Mozilla extension packaging team decided to use xul-ext- (instead of mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. This will group the extensions visually. There are currently 18 extensions that use this naming scheme already. Please rename the binary package if not already done. Use mozilla-devscripts == To make packaging extensions dead simple we have mozilla-devscripts. In most cases debian/rules can be reduces to three or four lines (shebang, two includes and maybe one variable). We highly recommend using it. An additional benefit of using mozilla-devscripts is that derived distribution can use the source code without modifying it. mozilla-devscripts take care of the distributions specialities. The usage is explained in the Wiki [2]. Joining our team You are welcome to join our team. We maintain all packages in git in the pkg-mozext group. You can contact us via email or IRC [3]. Please let us know, if you need help implementing the above mentioned items. Work needing package Here is a list of source package that need to updated. Please let me know, if I missed some packages. beagle biofox ctxextensions diggler firegpg foxyproxy icedove-attachmentreminder icedove-gcontactsync icedove-quotecolors iceweasel-downthemall imagezoom livehttpheaders mozilla-dom-inspector mozilla-noscript mozvoikko nostalgy nukeimage vimperator [1] http://wiki.debian.org/Mozilla/ExtensionsPolicy [2] http://wiki.debian.org/mozilla-devscripts [3] http://wiki.debian.org/Teams/DebianMozExtTeam -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 21:34 +0100 schrieb Thilo Six: Question 1: You propose to use the prefix xul-ext- which is more generic i guess but the itself is called pkg-mozext. Is that moz in the team name for historic reasons? Yes, it's only for historic reasons. Or is it planed to rename it pkg-xul-ext Team? There is currently no plans to rename the team, but it's worth thinking about it. What do the other team member think about it? 2nd question: In the good old days (when ever these were) someone like a short sighted person like me could search via apt or aptitude for *compatible* extentions to his application. Now does it mean, that all those xulrunner based apps can make use the same extensions? e.g. does ist make sens to use xul-ext-quotecolors with iceweasle? The extension must support the xulrunner based apps. quotecolors will support the same amount of xulrunner based apps after the rename. According to upstream it does not work with iceweasel. Realy i don't get so please explain a bit more deeply. When using mozilla-devscripts, the extension will enhance the supported xulrunner apps and provide xulapt-extname. In the case of xul-ext-quotecolors, it will enhance icedove and provide icedove-quotecolors. So are still able to run apt-get install icedove-quotecolors or apt-get install iceweasel-adblock-plus. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 15:48 -0500 schrieb James Vega: On Mon, Feb 1, 2010 at 3:34 PM, Thilo Six t@gmx.de wrote: Benjamin Drung wrote the following on 01.02.2010 20:34 icedove-quotecolors 2nd question: In the good old days (when ever these were) someone like a short sighted person like me could search via apt or aptitude for *compatible* extentions to his application. Now does it mean, that all those xulrunner based apps can make use the same extensions? e.g. does ist make sens to use xul-ext-quotecolors with iceweasle? It does make sense to use xul-ext-quotecolors with iceape, even though the current package forces icedove usage. With mozilla-devscripts, the package would recommend icedove | iceape on Debian (and thunderbird | seamonkey on Ubuntu). So you wouldn't be forced to install icedove. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
2010/2/2 Mike Hommey m...@glandium.org: On Mon, Feb 01, 2010 at 08:34:31PM +0100, Benjamin Drung wrote: Hi, This mail targets all developers, which maintain Mozilla extensions. Source package name === The source package name for extension should not contain the name of the enhanced application. These prefixes should be dropped from the source name: firefox- iceape- icedove- iceweasel- mozilla- thunderbird- If the remaining string is too generic (for example, notify or sage), the source package name should append -extension. For example, firefoxnotify was renamed to notify-extension. I don't remember this has been discussed, and i certainly disagree with this naming scheme. Also, existing extensions sources shouldn't be renamed. Yes, we only discussed binary names. The same rules apply for source package names. Why should Debian have a source package with firefox in its name (for example, firefox-notify) and why should Ubuntu have a source package with icedove in its name (for example, icedove-quotecolors)? This would be similar to the python name scheme. For example the source package matplotlib provides the binary package python-matplotlib. Binary package name === The Mozilla extension packaging team decided to use xul-ext- (instead of mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. This will group the extensions visually. There are currently 18 extensions that use this naming scheme already. Please rename the binary package if not already done. Note the policy proposal has not been updated with the latest propositions (for which i was hoping more feedback, btw). See the team list archives. I read the archives. There are still some parts of the policy proposal that needs more discussion (for example the directory question). The binary naming part was discussed and we reached the consensus that using xul-ext- as prefix is the lesser of the two evils, didn't we? Use mozilla-devscripts == To make packaging extensions dead simple we have mozilla-devscripts. In most cases debian/rules can be reduces to three or four lines (shebang, two includes and maybe one variable). We highly recommend using it. An additional benefit of using mozilla-devscripts is that derived distribution can use the source code without modifying it. mozilla-devscripts take care of the distributions specialities. The usage is explained in the Wiki [2]. Joining our team You are welcome to join our team. We maintain all packages in git in the pkg-mozext group. You can contact us via email or IRC [3]. Please let us know, if you need help implementing the above mentioned items. Work needing package Here is a list of source package that need to updated. Please let me know, if I missed some packages. I have a lintian check that checks most of the policy, except it was written before lintian 2.3 and doesn't work anymore. If someone has the time to update the script before me, I'll send it to them. What will be checked by that? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Dienstag, den 02.02.2010, 21:32 + schrieb brian m. carlson: On Tue, Feb 02, 2010 at 07:59:04PM +0100, Fabian Greffrath wrote: while we are at it, maybe we could take the opportunity and introduce a similar scheme for all packages providing mozilla-compatible browser plugins as well? I hope you mean NPAPI[0] plugins, since those will work on non-Gecko browsers. In general, there's few good reasons to have plugins that work only on Gecko browsers, especially since that means that a large number of browsers that Debian supports (such as Konqueror and Webkit-based browsers like Epiphany) are left without useful plugins. I remember this discussion has been here before. My favourite approach these days was to suffix all packages with -browserplugin, because that perfectly describes what the package contains, but is a little bit too long, maybe. Given the current approach, I think some prefix like xul-plugin- would fit better and feel more consistent with the naming scheme of the extensions packages. What do you think? I think xul-plugin- is only okay if it will only work on Gecko-based browsers. It is inaccurate and misleading to use xul-plugin- unless the plugin is designed to do something specifically with Gecko. I would suggest npapi- as a prefix for plugins that use that interface. I would suggest that plugins that do not use that interface adopt it forthwith. :-) npapi- prefix is not very user friendly. It reminds me of the PCMCIA card. xul-plugin- sounds better, but do not fit. The least evil proposal was to append -browserplugin. Better suggestions are welcome. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Donnerstag, den 04.02.2010, 10:13 +0100 schrieb Fabian Greffrath: Am 03.02.2010 07:14, schrieb Mike Hommey: I'd go for the -browserplugin suffix. Fine, but what now? Can we already call this a consensus? Shall I file wishlist bugs against the affected packages? What's the opinion of the affected packages' maintainers? We should gather more opinions, especially from the affected packages' maintainers. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: About new source formats for packages without patches
Am Donnerstag, den 25.03.2010, 16:16 + schrieb Philipp Kern: On 2010-03-25, Josselin Mouette j...@debian.org wrote: I’d expect it to be much smoother for an organization that uses Debian tools and works with us to add missing functionality in them if needed, than for an organization that uses its own tools. You seriously don't want to force dak upon everyone. And there is not even a package. (And the same is true for wanna-build, sadly.) Why is there no dak and wanna-build package? Are there plans to create such packages? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: About new source formats for packages without patches
Am Donnerstag, den 25.03.2010, 17:57 +0100 schrieb Julien BLACHE: Benjamin Drung bdr...@ubuntu.com wrote: Hi, Why is there no dak and wanna-build package? Are there plans to create such packages? Have you ever tried to install dak? No. If you have, then the answer should be obvious to you. If you haven't, try it someday, and you'll understand. Reading your response, I probably want to spend my year doing something else like coding or packaging. Is there a plan for making the installation of dak easier? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Am Donnerstag, den 25.03.2010, 23:30 +0100 schrieb Joerg Jaspert: Additionally we have one package in the archive that we can not help with a binnmu, a full source upload is required. The maintainer got a seperate mail asking for the upload, but for reference, its fatsort, the latest version. That explains why fatsort is gone. Thanks for the info. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Am Mittwoch, den 31.03.2010, 15:45 +0200 schrieb Mehdi Dogguy: Julian Andres Klode wrote: On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: Paul Wise wrote: On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode j...@debian.org wrote: Description : debhelper add-on to call autoreconf and clean up after the build Package: dh-autoreconf I'd suggest just putting this into debhelper rather than making it a separate package. Is there any advantage to have it packaged? AIUI, you have to add a build-dependency anyway and change at least one line in the debian/rules to call dh-autoreconf. Well, that line could simply call autoreconf (or whatever) which even makes debian/rules clearer. The difference is that dh_autoreconf calls autoreconf and stores a list of the changes and the changed files are then removed in the clean target. If you just call autoreconf, the changes end up in the diff; and this is not what we want. I do use autoreconf and I don't have these changes in my diff. IMO, a backup/restore script (where you specify the list of files to backup) may be more useful. It would be called before build and when cleaning. I prefer the removal over the restoring the old files. You remove .o files on clean, so why not remove the other auto-generated files on clean? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Freitag, den 16.04.2010, 22:48 +0200 schrieb Raphael Hertzog: Hi, sorry for the delay answering. On Mon, 29 Mar 2010, Colin Watson wrote: I don't know that we need to bother with two fields, though. There's precedent in DEP-3 for fields with internal structure; the format of Origin is not dissimilar to what we need here. How about something like the following? Thanks for the suggestion, it looks good so I applied it. Thanks. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Sonntag, den 25.04.2010, 13:26 +0200 schrieb Yves-Alexis Perez: On jeu., 2010-02-04 at 17:21 +0100, Yves-Alexis Perez wrote: On 03/02/2010 07:14, Mike Hommey wrote: I'd go for the -browserplugin suffix. Speaking of plugins, I see there are several plugin packages that put plugins in various places. Here is a breaking news: the canonical place for plugins is /usr/lib/mozilla/plugins. Nowhere else. Why ? Because it's where most of the plugins already are (but some packages like to put their files in several places, which is pointless), and it's where all applications are already looking for plugins. I started packaging parole media player which provides a plugin using npapi, and recently submitted a bug to split rhythmbox package. In both case I used the scheme: browser-plugin-* (replacing mozilla by browser, in fact). None of the packages are already uploaded so I can still change. I'm about to upload parole, so I'd like to know what's the status on this? At the moment a search on -browserplugin doesn't return anything. A search on browser-plugin returns cairo-dock-quick-browser-plugin and that's all. It seems that no package was really renamed. What should we do? I think we should start using the new naming policy to add the -browserplugin suffix. There were some votes for -browserplugin and none against it. No better name was proposed. Therefore I think that it was decided. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Sonntag, den 25.04.2010, 23:51 +0200 schrieb Yves-Alexis Perez: On dim., 2010-04-25 at 18:58 +0200, Benjamin Drung wrote: What should we do? I think we should start using the new naming policy to add the -browserplugin suffix. There were some votes for -browserplugin and none against it. No better name was proposed. Therefore I think that it was decided. To be perfectly fair, browser-plugin-* had my vote, but anyway. We didn't discussed browser-plugin-*. Should we make a poll with *-browserplugin and browser-plugin-*? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 11:07 +0200 schrieb Stefano Zacchiroli: On Mon, Apr 26, 2010 at 10:39:39AM +0200, Jean-Christophe Dubacq wrote: I'd rather say that generally binary packages split words at '-', so if you've a choice among these two the latter is preferable. If this is so, then browserplugin-* should content everyone. I'm sure you meant browser-plugin-* here ... Hm, browserplugin-* would be a new option. Then we would have 1. browser-plugin-* 2. browserplugin-* 3. *-browserplugin 4. *-browser-plugin I think all of these would work (with a slight preference to 1. or 2.). Opinions? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 18:49 +0200 schrieb Stefano Zacchiroli: On Mon, Apr 26, 2010 at 04:56:15PM +0200, Benjamin Drung wrote: I'm sure you meant browser-plugin-* here ... Hm, browserplugin-* would be a new option. Then we would have 1. browser-plugin-* 2. browserplugin-* 3. *-browserplugin 4. *-browser-plugin I think all of these would work (with a slight preference to 1. or 2.). Opinions? Please don't do polls on a mailing list :-) Arguments have been given for using '-' in the name (while I haven't seen any argument for _not_ using dashes). I presume the general feeling about whether it should be at the beginning or at the end of packages is we don't particularly care, as long as it is consistent. I personally don't think a poll is needed, but if you feel it is please set up one somewhere and post just a participation link. I setup a doodle poll: http://www.doodle.com/2wmykvgy7ara5pd5 Please participate there. And yes, doodle is designed for schedules, but not for polls. ;) -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 20:40 +0200 schrieb Benjamin Drung: Am Montag, den 26.04.2010, 18:49 +0200 schrieb Stefano Zacchiroli: On Mon, Apr 26, 2010 at 04:56:15PM +0200, Benjamin Drung wrote: I'm sure you meant browser-plugin-* here ... Hm, browserplugin-* would be a new option. Then we would have 1. browser-plugin-* 2. browserplugin-* 3. *-browserplugin 4. *-browser-plugin I think all of these would work (with a slight preference to 1. or 2.). Opinions? Please don't do polls on a mailing list :-) Arguments have been given for using '-' in the name (while I haven't seen any argument for _not_ using dashes). I presume the general feeling about whether it should be at the beginning or at the end of packages is we don't particularly care, as long as it is consistent. I personally don't think a poll is needed, but if you feel it is please set up one somewhere and post just a participation link. I setup a doodle poll: http://www.doodle.com/2wmykvgy7ara5pd5 Please participate there. And yes, doodle is designed for schedules, but not for polls. ;) I create a new poll that allows yes/no/maybe: http://www.doodle.com/guafbbhipwskzr8a Please add yourself there. Sorry for the inconvenience. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins
Am Montag, den 26.04.2010, 23:58 +0200 schrieb Goswin von Brederlow: Hans-J. Ullrich hans.ullr...@loop.de writes: Am Montag, 26. April 2010 schrieb Goswin von Brederlow: Benjamin Drung bdr...@ubuntu.com writes: Am Montag, den 26.04.2010, 11:07 +0200 schrieb Stefano Zacchiroli: On Mon, Apr 26, 2010 at 10:39:39AM +0200, Jean-Christophe Dubacq wrote: I'd rather say that generally binary packages split words at '-', so if you've a choice among these two the latter is preferable. If this is so, then browserplugin-* should content everyone. I'm sure you meant browser-plugin-* here ... Hm, browserplugin-* would be a new option. Then we would have 1. browser-plugin-* 2. browserplugin-* 3. *-browserplugin 4. *-browser-plugin I think all of these would work (with a slight preference to 1. or 2.). Opinions? I think *-bwoser[-]plugin is a bad choice for 2 reasons (which you can consider one reason): A) apt-get install browsertabtab This will complete nicely to give me a list of plugins with options 1 and 2 and all the packages it completes have a common use case, to make my browser better. No such thing with options 3 and 4. B) Sorting in frontends (aptitude, ...) Again say you are looking for usefull plugins to add to your browser. With options 1 and 2 you get all the plugins in one blog and can easily scroll through them. With options 3 and 4 they will be scattered all over the place. I think the seperate groups formed by a common prefix in options 3 and 4 would be much smaller and less usefull to users than having all browser plugins in one block. MfG Goswin I think, 3 and 4 are the better choices than 1 or 2. IMO, the best choice might be 4. Let me just explain why: If people are looikng for something, they first look, what application it is in for. Browser plugins might be available for iceweasel, konqueror, opera whatever. So, the first choice is iceweasel-, then what is it? Yes, it is for the -browser, and at last, they see, yes, a -plugin. I also imagine, that in the future, there might be iceweasel-sound-plugins, video-plugins, flash-plugins or whatever. I also imagine, there might be also not only plugins, but tools, or maybe modules. By that reasoning you are advocating: 5. browser-*-plugin That would also work for apt-get install browsertabtab Ok, I added it to the poll, but i doubt that it will win against browser-plugin-*. IMO we should decide for a structure or syntax, that is easy to understand and modular for future changes -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [OT] Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Dienstag, den 27.04.2010, 10:02 +0900 schrieb Charles Plessy: Le Mon, Apr 26, 2010 at 08:40:41PM +0200, Benjamin Drung a écrit : I setup a doodle poll Dear Benjamin, I would like to recommend http://selectricity.org/ instead. In contrary to Doodle, Selectricity is free software. Thanks, I bookmarked it and will use it the next time. It is free software (indicated by Copyleft), but I haven't found the source code. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Architecture Nomenclature
Am Dienstag, den 27.04.2010, 12:45 -0700 schrieb Kip Warner: Greetings Everyone, I've been looking for a while, but no luck. Is there a table somewhere that summarizes the different architecture names like i386, i586, i686, amd64, ia64, and so on along with the criteria for hardware qualifying under that name? I am not aware of a table. I would search for the names and see which is the first architecture and check their features. e.g. Does i686 mandate SSE2? i686 = Pentium Pro and later = only MMX amd64 mandates SSE2 (and therefore MMX and SSE) PS I am not on the mailing list, so please remember to cc me. Thanks. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Architecture Nomenclature
Am Dienstag, den 27.04.2010, 14:45 -0700 schrieb Kip Warner: On Tue, 2010-04-27 at 21:43 +0100, Ben Hutchings wrote: It must be 'i386'. But i386 includes machines like the 486 and the Pentium Pro that did not have SSE2 instruction set. If I was writing something for a 32-bit machine with SSE2 instruction set, what would be the most appropriate architecture name? The best solution would be autodetection of SSE2 on runtime. That can be done with a few lines of code. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Hi, after some days the poll [1] has been a clear result. browser-plugin-* has won with a huge winning margin. [1] http://www.doodle.com/guafbbhipwskzr8a -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Donnerstag, den 22.07.2010, 10:20 +0200 schrieb Yves-Alexis Perez: On 21/07/2010 10:25, Paul Wise wrote: They also currently have almost 20 times as many popcon submissions as Debian and continuing growth: http://popcon.ubuntu.com/ http://popcon.ubuntu.com/stat/sub-i386.png Is it enabled by default without asking the user? (I didn't do an ubuntu install since warty or hoary so I wouldn't know) No. You have to enable it in a submenu. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: How to make Debian more attractive for users
Am Donnerstag, den 22.07.2010, 23:14 +0800 schrieb Paul Wise: On Thu, Jul 22, 2010 at 4:28 PM, Giacomo A. Catenazzi c...@debian.org wrote: I think it is bugous to ask such question. IMHO we should care about improving Debian, going toward the perfection, not about increasing the number of users (which should be a nice secondary effect). I don't think increasing the number of Debian user is per se a nice things, after looking Ubuntu. ... So, let see how to improve Debian, not how to increase our userbase! The two are not entirely unrelated. I was a user of Debian before I was a Debian contributor. All developers come from a pool of users and with more developers we can make a better distro. Figuring out how to convert users into developers is the hard part though. Debian contributors don't have to be Debian users at the beginning. They can come from Debian-derived distributions and contribute directly to Debian to avoid work duplication. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Montag, den 26.07.2010, 10:30 +0200 schrieb Raphael Hertzog: Hi, On Thu, 22 Jul 2010, Benjamin Drung wrote: Am Donnerstag, den 22.07.2010, 10:20 +0200 schrieb Yves-Alexis Perez: On 21/07/2010 10:25, Paul Wise wrote: They also currently have almost 20 times as many popcon submissions as Debian and continuing growth: http://popcon.ubuntu.com/ http://popcon.ubuntu.com/stat/sub-i386.png Is it enabled by default without asking the user? (I didn't do an ubuntu install since warty or hoary so I wouldn't know) No. You have to enable it in a submenu. I could not find that submenu while installing 10.04. It's quite possibly only in the alternate installer image nowadays (that is used for the server edition AFAIK). On the last step (7 of 7), there is the Advanced... button. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Freitag, den 30.07.2010, 14:24 +0200 schrieb Raphael Hertzog: On Fri, 30 Jul 2010, Benjamin Drung wrote: I could not find that submenu while installing 10.04. It's quite possibly only in the alternate installer image nowadays (that is used for the server edition AFAIK). On the last step (7 of 7), there is the Advanced... button. Yes, and there's nothing about popcon there. There's stuff for grub and a Network proxy IIRC: http://i1-news.softpedia-static.com/images/extra/LINUX/large/ubuntu1004installation-large_008.jpg OTOH Karmic seems to have the checkbox: http://i1-news.softpedia-static.com/images/extra/LINUX/large/ubuntu910installation-large_010.jpg Ok, then it was dropped. software-properties-gtk has an easy way to enable popcon. In Ubuntu there is a description what popcon does and what it is used for, but software-properties-gtk in squeeze doesn't have it. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Search for a file in all Debian source packages
Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke: Hi, I want to determine in what Debian _source_ packages a file with a particular name exists. There used to be a webservice that had all? source packages indexed and allowed for this type of query, but I cannot remember what it was -- maybe it doesn't exist anymore. http://www.debian.org/distrib/packages There you can search the contents of packages. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Re: Search for a file in all Debian source packages
Am Donnerstag, den 30.09.2010, 14:38 -0400 schrieb Michael Hanke: On Thu, Sep 30, 2010 at 08:33:54PM +0200, Benjamin Drung wrote: Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke: Hi, I want to determine in what Debian _source_ packages a file with a particular name exists. There used to be a webservice that had all? source packages indexed and allowed for this type of query, but I cannot remember what it was -- maybe it doesn't exist anymore. http://www.debian.org/distrib/packages There you can search the contents of packages. _Binary_ packages. This is not what I was looking for. Oops. IIRC there was a website where you can search the source code, but this website took the code directly from upstream. So this might not fit your needs. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Re: Create package for XUL-based app
Am Montag, den 18.10.2010, 17:26 -0500 schrieb David Rios: Hi. I want to package a XUL-based application which isn't in Debian Repository yet. I've read many tutorials, including Debian New Maintainters' Guide but I can't find how to package this kind of apps. You don't have to compile it (it's an script-based app) so it doesn't have a Makefile file. I use dpkg-buildpackage and it creates a .deb file but it doesn't include my app. Can you help me? where can I find instructions? You probably want to use mozilla-devscripts to package it. Look at the wiki page [1] and look how other XUL extensions (e.g. adblock-plus) are packaged. [1] http://wiki.debian.org/mozilla-devscripts -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Bug#602977: ITP: ocs -- Opal Compilation System
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@ubuntu.com * Package name: ocs Version : 2.3n Upstream Author : Opal Group, TU Berlin * URL : https://projects.uebb.tu-berlin.de/opal/ * License : GPL, LGPL (will probably change) Programming Lang: C, Opal Description : Opal Compilation System The Opal project is concerned with research into a programming environment in which advanced language concepts and formal development methods can be used for creating production-quality software. At the core of the project is the algebraic programming language, Opal, which integrates both concepts of algebraic specification and functional programming. A comprehensive set of tools supporting the language constitutes the Opal compilation system OCS. I am in direct contact with the upstream maintainer to get the package suitable for Debian (relicensing documentation under DFSG compliant license, FHS compliance, lintian fixes). We target to have a new upstream version at the end of the year and to get this into the archive. -- 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/20101109235654.12865.15671.report...@localhost6.localdomain6
Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
Am Samstag, den 04.06.2011, 14:10 +0200 schrieb Gergely Nagy: Jonas Smedegaard d...@jones.dk writes: I have noticed several times package changes like the following (from cairomm entering testing today): * debian/control: - Drop build dependencies on doxygen and graphviz, since upstream now ships the generated documentation Feels wrong to me to redistribute when e.g. html files clearly are not the preferred form of editing for upstream. To me, that doesn't sound all that troubling: we do use other generated files that upstream ships more often than not: configure, Makefile.ins - and so on. Though, those are rarely shipped in the binary package, but still: we do not build-depend on the tools that generate these. Technically, upstream could do anything in those files, write them by hand instead of generating from configure.ac, and include that in the distributed tarball, potentially under a non-free license. In any case: even if upstream shipts generated content, as long as the source is shipped aswell, all is fine and well, in my opinion. The _source_ needs to be in the preferred form of modification. If it contains generated files aswell, that doesn't matter all that much: the source is still there. You just don't have to use it, if the result would be the same anyway. It's better to build the pre-generated files from source in case you need to modify the source. It's easier to just modify for example configure.ac instead of modifying it and figuring out how to rebuild the pre-generated files, especially when you do security fixes or stable release updates. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: [ANNOUNCE] dh_splitpackage 0.2.2
Am Samstag, den 04.06.2011, 20:46 +0200 schrieb Zygmunt Krynicki: The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards. I looked at the man page of dh_splitpackage and compared it to dh_install --fail-missing. I found three differences. Please let me know if there were more. 1. dh_splitpackage complains if a file ends up in more than one binary package. Having the same file in two binary package leads to a conflict if you want to install both binary packages. IMO dh_install should do this check too. 2. dh_splitpackage put files in the primary package if no other install destination is specified. I would love to see a command line option for dh_install that does the same. For example, I want to call dh_install --put-everything-else-in=vlc-nox for the daily builds of vlc. 3. dh_splitpackage supports more pattern than dh_install. To name them: ** for matching all directories, [] to match as specific set of characters. I could live without that, but ** would be nice sometimes. I think that dh_install could be improved to support all three points above. The features of dh_splitpackage are great, but the configuration format (JSON) seems to be too complex for this use case. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
intermediate result of packaging-dev meta package discussion
Hi,
A few days ago, we had a discussion about a packaging-dev meta package.
The responses were between neutral and positive. Therefore I created a
initial draft [1] and tried to incorporate all suggestions made in the
discussion.
The list looks currently like this:
Depends: build-essential,
debhelper,
devscripts,
dput | dupload,
lintian,
pbuilder | cowbuilder | sbuild,
quilt,
${misc:Depends}
Recommends: apt-file,
autoconf,
automake,
autotools-dev,
bzr-builddeb,
cdbs,
cmake,
debian-policy,
developers-reference,
git-buildpackage,
gnupg,
libtool,
piuparts,
svn-buildpackage,
${vendor-specific:Recommends}
Suggests: dh-make
${vendor-specific:Recommends} will be evaluated to ubuntu-dev-tools on
Ubuntu.
Please let me know if there is something missing, should be demoted, or
removed.
This package is just for packaging, not for developing. So gdb, pylint
and co. won't go into it. This package should be installed by packagers.
No other package should depend or build-depend on packaging-dev.
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git
--
Benjamin Drung
Debian Ubuntu Developer
signature.asc
Description: This is a digitally signed message part
Re: intermediate result of packaging-dev meta package discussion
Am Sonntag, den 05.06.2011, 15:11 +0100 schrieb Neil Williams: On Sun, 05 Jun 2011 15:46:44 +0200 Benjamin Drung bdr...@debian.org wrote: A few days ago, we had a discussion about a packaging-dev meta package. This package is just for packaging, not for developing. So gdb, pylint and co. won't go into it. This package should be installed by packagers. No other package should depend or build-depend on packaging-dev. I'd suggest that a wishlist bug is filed against lintian to set an error if any package (source or binary) lists a dependency (or even Recommends) on the packaging-dev binary. Time should be allowed for lintian to implement this check before this package is uploaded, unless the lintian maintainers disagree. Done (bug #629308). It would also be sensible to have a summary of the quoted paragraph in the package description. Done, but a proper long description is still missing. Anyone with good writing skills volunteering? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: intermediate result of packaging-dev meta package discussion
Am Dienstag, den 07.06.2011, 10:46 +0100 schrieb Neil Williams: On Tue, 07 Jun 2011 11:34:30 +0200 Vincent Danjean vdanjean...@free.fr wrote: A few days ago, we had a discussion about a packaging-dev meta package. The responses were between neutral and positive. Therefore I created a initial draft [1] and tried to incorporate all suggestions made in the discussion. The list looks currently like this: Depends: [...] pbuilder | cowbuilder | sbuild, My laptop, where I do all my packaging work but final build, has none of them installed. I've a separate machine with several chroots (lenny, squeeze, unstable and several for ubuntu) managed with sbuild that I use when I want to really build the package I will upload. Due to disk space, I cannot instal them (chroots) on my laptop. I other people work like me, these tools can be moved to Recommends I disagree. pbuilder or the alternatives are fundamental to best practice Debian packaging. The needs of Debian are wider than a single user having a problem with a single machine. This package is trying to express best practice for packaging, to get a baseline. You admit that you have a way of building in a chroot and it isn't required that everyone uploading to Debian has this package installed, it is simply a way of making it simple for most people to have a standard set of build tools. Most people would have space for a pbuilder chroot (it's only a few hundred megabytes even unpacked, it's the apt cache which takes up the space and that can be cleared with a configuration change) and everyone using packaging-dev should be expected (required) to use a chroot to build packages prior to upload. Recommending chroot build tools is not strong enough. Beginners are the target, not experienced packagers. That's why Neil's reasons seems to be stronger for me than Vincent's. Therefore I will leave the chroot dependency as dependency unless more people are in favor of moving them to Recommends. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
packaging-dev 0.1 in unstable
Hi, packaging-dev 0.1 is now available in Debian unstable. If you think that it misses a dependency or recommends, file a bug or discuss it on this mailing list. I like to see these kind of discussions: A: I am new to packaging. How do I get started? B: Install packaging-dev and then ...! -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: build self-contained repository for offline use
Am Mittwoch, den 06.07.2011, 04:11 -0400 schrieb Hamish Moffatt: On Tue, Jul 05, 2011 at 10:52:02PM +0200, Paul Wise wrote: One of apt-zip/aptoncd/apt-offline might meet your needs. Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, CDD and apt-clone. None of them really suited my needs, as I want to generate this repository automatically, and want to do a whole class of target systems which will have a baseline set of packages installed. Anyway I've found it's pretty easy to roll my own using python-apt and configuring apt to use alternate locations for the cache, dpkg status file etc. I feed in the dpkg status file from my baseline install, a sources.list and a list of packages I want to be installable, and I can easily download the files. Then use apt-ftparchive to generate the metadata and I'm done. If you have enough bandwidth and disk space, you could use apt-mirror to store a complete mirror locally (takes around 30 GB for one architecture). -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Call for teams interested in collaborating on a 'standard' Git workflow
Am Samstag, den 30.07.2011, 16:26 +0100 schrieb David Goodenough: On Saturday 30 Jul 2011, Lucas Nussbaum wrote: On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote: Hi, It seems that many different teams have recently switched to Git, or are considering switching. But each of them seems to re-implement the wheel by designing their own Git workflow. I think that it would be fantastic if we could collaborate on defining a common Git workflow. [...] If you are interested in participating (which doesn't mean that you commit on behalf of your team to switch to that workflow, just that you want to participate in the discussions), add yourself (and your team) to http://wiki.debian.org/GitPackagingWorkflow. If more than 3 teams are interested in a BOF at DC11, I'll try to organize one on saturday (all the video-broadcasted slots are taken, but we will make sure to take notes). If the BOF doesn't happen, I'll contact interested people to see how to continue. Hi, So a BOF happened at Debconf 11, and I've put the raw notes online at http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF My understanding of the situation is that we are ready to document a workflow including: - using git-buildpackage for basic stuff - managing several repositories with mr - managing and tracking the status of the repositories (e.g with PET) - managing patches with quilt (the nothing fancy approach) + additionally, using a patch-queue system (but which one?) to manage patches locally - managing debian/changelog with git-dch Some people expressed interest in starting a proper documentation on that on the Debian wiki. I suggest to use the http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the http://wiki.debian.org/PackagingWithGit page). We probably need more discussion: - on patch queue managers - on the one-branch-per-patch approaches Eclipse recently moved to one-branch-per-patch, or at least one branch per issue being fixed. This seems to be the fashion. Did we? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: packages under the AGPL-3 license
Am Dienstag, den 20.09.2011, 14:25 -0700 schrieb Russ Allbery: I personally consider 1000 packages to be the appropriate level for considering including something new in common-licenses, but I'm fairly conservative on that front. The closest (by far) of the licenses not already listed there, and the best case for inclusion, is the MPL 1.1 at 740 packages. The next closest contender would be the CDDL at 219 packages. Probably many people of the Mozilla extension maintainers team would love to see the MPL-1.1 in common-licenses. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Bug#645212: ITP: lxmms2 -- control XMMS2 with a LIRC compatible remote control
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@debian.org * Package name: lxmms2 Version : 0.1.3 Upstream Author : Johannes Heimansberg wejpi...@gmail.com * URL : http://wejp.k.vu/projects/xmms2/lxmms2 * License : GPL-2 Programming Lang: C Description : control XMMS2 with a LIRC compatible remote control lxmms2 is a tiny XMMS2 client to control XMMS2 with a LIRC compatible remote control. Following actions are supported: - play (starts playback) - pause (pauses playback) - toggle_play_pause (toggles pause and starts playback if XMMS2 is not playing at all) - toggle_pause (toggles pause) - stop (stops playback) - next (advances to the next track) - prev (goes back to the previous track) - volume_up (increases the volume) - volume_down (decreases the volume) -- 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/20111013155848.14230.23978.reportbug@localhost6.localdomain6
Re: Announcing derivatives patches and call for help and feedback
Am Mittwoch, den 26.10.2011, 08:49 +1100 schrieb Karl Goetz: On Tue, 25 Oct 2011 13:57:20 +0200 Mehdi Dogguy me...@dogguy.org wrote: On 25/10/2011 09:50, Paul Wise wrote: For the presentation side of things I am thinking one approach might be to move UbuntuDiff[8] to the QA infrastructure, generalise it and enhance it for this purpose. This will necessarily include mechanisms to mark patches as having been dealt with or ignorable. 8. http://ubuntudiff.debian.net/ [...] About source code, it is written in OCaml. I realize that OCaml is not the best candidate if we want people to contribute patches (or even have a look at the code) :) It depends on who wants to contribute here. I'm open to suggestions… If integration with PTS is planned (and or if you're using ubuntu-distro-info) perhaps python would make sense as a language choice. ubuntu-distro-info is implemented in Haskell (since version 0.3) and has an Python and Perl library. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
DEP-5 and files with white spaces
Hi, DEP-5 is nice, but how can I specify a license for a file with white spaces? For example you want to specify that the file foo/file one.bar is licensed under ISC, but foo/file_one.bar is licensed under GPL. How can you do that? I would like to write following: File: foo/file one.bar License: ISC File: foo/file_one.bar License: GPL -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:20 -0800 schrieb Russ Allbery: Benjamin Drung bdr...@debian.org writes: DEP-5 is nice, but how can I specify a license for a file with white spaces? For example you want to specify that the file foo/file one.bar is licensed under ISC, but foo/file_one.bar is licensed under GPL. How can you do that? No, that distinction isn't representable. There was some earlier discussion about that, and the conclusion reached was that it was a rare case that wasn't worth making the syntax more complicated (after various more complicated syntaxes were tossed around without making anyone very happy). Is it to complex to have a syntax that is similar to what the shell does? Two solutions pop into my mind. Please let me know, why these are not use. You can point me to previous discussions. Idea 1: Use a escape sequence for specifying a whitespace (e.g. \ for a space). Idea 2: Allow quotation marks. The general way to specify information for a file name that contains whitespace is to use wildcards to match the whitespace, which means that you can't disambiguate from other files that only differ in the places where whitespace is present. I don't like the idea of abusing a wildcard if the files could be specified more precisely. Out of curiosity, have you run across a case where this matters, or were you asking because it's a theoretical hole? It's definitely a theoretical hole, but one of the reasons why we didn't spend more time on it was that everyone was dubious that the case would arise in a real-world situation. I haven't run across an actual case. This case just popped into my mind and I wondered how to cover this case. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 23:31 +0100 schrieb Jakub Wilk: * Russ Allbery r...@debian.org, 2012-02-01, 14:20: DEP-5 is nice, but how can I specify a license for a file with white spaces? For example you want to specify that the file foo/file one.bar is licensed under ISC, but foo/file_one.bar is licensed under GPL. How can you do that? No, that distinction isn't representable. This one is representable. You can take advantage of the fact the the last paragraph that matches a particular file applies to it: | Files: foo/file?one.bar | License: ISC | | Files: foo/file_one.bar | License: GPL That said, you _can_ construct even more contrived examples which are unrepresentable, e.g. by replacing _ with a tab. The general way to specify information for a file name that contains whitespace is to use wildcards to match the whitespace, That works only if you can stand ugliness of such Files fields. True words. For example, the eclipse source package has files with spaces in it using ? instead of spaces does look ugly. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery: Benjamin Drung bdr...@debian.org writes: Is it to complex to have a syntax that is similar to what the shell does? Two solutions pop into my mind. Please let me know, why these are not use. You can point me to previous discussions. Idea 1: Use a escape sequence for specifying a whitespace (e.g. \ for a space). Idea 2: Allow quotation marks. Yeah, both of those were among the other syntax proposals that were suggested, and I think one of them was in the document at one point. Using backslash is probably the easiest, although it does make parsing the files harder. IMHO allowing both would be the optimum. A real parser would have problems with both, but a simplistic parser that just split the string by spaces would have a problem. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:56 -0800 schrieb Russ Allbery: Benjamin Drung bdr...@debian.org writes: Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery: Yeah, both of those were among the other syntax proposals that were suggested, and I think one of them was in the document at one point. Using backslash is probably the easiest, although it does make parsing the files harder. IMHO allowing both would be the optimum. A real parser would have problems with both, but a simplistic parser that just split the string by spaces would have a problem. Yeah, that was, as I understand it, the motivation (to allow really simple parsers). What is more important: A good looking copyright file or being parsable by a dead simple, stupid parser? The proposed changes would make the parser overly complex. I don't know if it's worth revisiting this. I can't say that I particularly liked the outcome we arrived at, but theoretical holes in standards bother me a lot (possibly more than they should). I would call a theoretical hole a design bug. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: leaks in our only-signed-software fortress
Am Samstag, den 18.02.2012, 11:48 +0100 schrieb Thomas Koch: July 2011 VLC suffers from Companies spreading Malware bundled with VLC This is no problem for us, because the malware was distributed on some untrustworthy websites. We, as packagers, get the code directly from the Videolan project. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Bug#663647: ITP: npapi-vlc -- multimedia plugin for web browsers based on VLC
Package: wnpp Severity: wishlist Owner: Benjamin Drung bdr...@debian.org * Package name: npapi-vlc Version : 2.0.0 Upstream Author : VLC media player developers vlc-de...@videolan.org * URL : http://git.videolan.org/?p=npapi-vlc.git * License : GPL-2+ Programming Lang: C++ Description : multimedia plugin for web browsers based on VLC This plugin adds support for MPEG, MPEG2, DVD, DivX, Ogg/Vorbis and many more formats to your Gecko-based web browser (Firefox, Galeon, etc.). The decoding process is done by VLC and the output window is embedded in a webpage or directly in the browser window. There is also support for fullscreen display and javascript control. . VLC is the VideoLAN project's media player. It plays MPEG, MPEG-2, MPEG-4, DivX, MOV, WMV, QuickTime, WebM, FLAC, MP3, Ogg/Vorbis files, DVDs, VCDs, podcasts, and multimedia streams from various network sources. The browser plugin was part of the vlc source tarball, but is now separated from the vlc source tarball and shipped as separate npapi-vlc tarball. -- 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/20120312225006.9527.15176.reportbug@localhost6.localdomain6
Re: (deferred) bits from the DPL: March 2012
Am Sonntag, den 15.04.2012, 20:19 +0200 schrieb Stefano Zacchiroli: - as part of a discussion on unofficial debian repositories [9], Which discussion? ;) I've proposed to open up the list of *.debian.net domains. As nobody disagreed, consensus has been quickly reached and the announced [10] change is now imminent. Thanks to Carsten Hey and Gerfried Fuchs for their help in figuring out the details of the last discussion on the matter and DSA for their feedback. [10] https://lists.debian.org/debian-devel-announce/2012/03/msg8.html -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
Am Freitag, den 29.06.2012, 19:21 +0200 schrieb Mehdi Dogguy: Package: wnpp Severity: wishlist Owner: Mehdi Dogguy me...@debian.org * Package name: ben Version : 0.6 Upstream Author : Mehdi Dogguy and Stéphane Glondu * URL : http://ben.debian.net/ * License : AGPL-3+ Programming Lang: C, OCaml Description : toolbox for Debian maintainers This is a collection of useful tools that Debian maintainers can use to make their packaging work easier. They all work with regular Debian package list files, and should be useful for Debian derivatives as well. This package ships a single executable, ben, with the following subcommands: * download: download a set of package list files from a mirror * monitor: monitor the status of a set of packages across several architectures (useful for transitions) * query: query packages using their metadata (similar to grep-dctrl, but uses a dedicated query language) * tracker: frontend to multiple monitors What does ben stand for? Is this just a short name for me? ;) Would it be useful to have ben in devscripts instead of a separate package? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Finding missing epochs
Am Donnerstag, den 05.07.2012, 23:34 +0200 schrieb Jakub Wilk: I wrote a tool to detect versioned (build-)dependencies with possible missing (or insufficient) epochs. The results for unstable and a DD-list are attached. Thanks. Your tool found a missing epoch in vlc, which I fixed now. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: About the media types text/x-php and text/x-php-source
Am Freitag, den 24.08.2012, 23:28 +0200 schrieb Ondřej Surý: Chris, this is surely not critical severity. I have cloned your bug report, assigned it a right severity and retitled it to mime-support: use of text/ for interpreted languages is discouraged since we have several interpreted languages in our mime.types text/x-perl text/x-python text/x-tcl text/x-sh text/x-java text/x-haskell [...] Java and Haskell are compiled, but not interpreted languages. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: (seemingly) declinging bug report numbers
Am Donnerstag, den 11.10.2012, 16:14 -0400 schrieb Paul Tagliamonte: On Thu, Oct 11, 2012 at 09:45:58PM +0200, Simon Josefsson wrote: Marco Nenciarini mnen...@debian.org writes: Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha scritto: On the other hand, some worries are there that this could imply some decline in Debian itself. Well I still think Debian is the best distro out there for most (if not all cases), even though I'd like to see it putting more emphasis on security. I've seen recently several company I'm working with getting away from Debian in favor of Ubuntu because they have a LTS version. However I don't know if this is a general trend. I can confirm the trend for a couple of organisations. The primary reason that I identified was the retirement of security support for Lenny and that Lenny packages are removed from many Debian mirrors which made it difficult to use Lenny machines. IMHO, supporting an OS release for only 3 years is not long enough. FWIW, it should be noted Ubuntu only supports most packages for 3 years as well. The subset of packages considered for Server support is supported for 5, but most people will suggest you follow the LTS upgrade path, which is very similar to Debian Stable's. Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on the desktop, too. [1] https://wiki.ubuntu.com/LTS -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Popularity of bzr-builddeb and dh-make
Hi, How popular are bzr-builddeb and dh-make in Debian? The current situation is that packaging-dev recommends bzr-builddeb and suggests dh-make. It was requested to drop bzr-builddeb from Recommends and add dh-make [1]. The recommended packages of packaging-dev should be recommended by most of the Debian developer and not just by the maintainer of packaging-dev or one single bug reporter. Therefore I am asking you: How popular are bzr-builddeb and dh-make? Should they be recommended or just suggested by packaging-dev? [1] http://bugs.debian.org/688572 -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Popularity of bzr-builddeb and dh-make
A poll is a good idea. Can you recommend a site that allows setting up a poll? Am Donnerstag, den 11.10.2012, 23:29 +0200 schrieb Matthias Klumpp: Hi! Have you considered making a poll for this? Because everyone will tell you a different oppinion... For me, I think: bzr-builddeb is specific to Bzr, if you don't use Bzr, it is useless. Instead, dh_make can be used to generate Debian templates quickly, so it might be useful for more people, even those not using Bzr. I use the Debian Git tools for packaging, I never touched the Bzr stuff, so I don't need it. I also don't need dh-make often, but it sometimes is useful. I can't give any hint, because I am just one developer, but I would probably prefer dh-make for the reason above. But if I would need to decide, I would probably suggest both and recommend none of them :-) Cheers, Matthias 2012/10/11 Benjamin Drung bdr...@debian.org: Hi, How popular are bzr-builddeb and dh-make in Debian? The current situation is that packaging-dev recommends bzr-builddeb and suggests dh-make. It was requested to drop bzr-builddeb from Recommends and add dh-make [1]. The recommended packages of packaging-dev should be recommended by most of the Debian developer and not just by the maintainer of packaging-dev or one single bug reporter. Therefore I am asking you: How popular are bzr-builddeb and dh-make? Should they be recommended or just suggested by packaging-dev? [1] http://bugs.debian.org/688572 -- Benjamin Drung Debian Ubuntu Developer -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Popularity of bzr-builddeb and dh-make
Am Donnerstag, den 11.10.2012, 14:38 -0700 schrieb Steve Langasek: Hi Benjamin, On Thu, Oct 11, 2012 at 10:38:08PM +0200, Benjamin Drung wrote: How popular are bzr-builddeb and dh-make in Debian? The current situation is that packaging-dev recommends bzr-builddeb and suggests dh-make. It was requested to drop bzr-builddeb from Recommends and add dh-make [1]. The recommended packages of packaging-dev should be recommended by most of the Debian developer and not just by the maintainer of packaging-dev or one single bug reporter. I think this is a failing proposition. There are as many different preferences about packaging, to the nearest order of magnitude, as there are Debian developers. I'm fine with this package being one maintainer's recommendations for some packages; I'm not at all ok with it being recast as a blessed recommendation of the project, as I object to about a third of the stuff in there. The main purpose of this package is to help beginners to get ready for packaging and not making a recommendation statement for the Debian project. The question is: Will you recommend newcomers to install packaging-dev to start packaging? Will installing packaging-dev be enough or will you recommend to install bzr-builddeb or dh-make afterwards? Therefore I am asking you: How popular are bzr-builddeb and dh-make? Should they be recommended or just suggested by packaging-dev? dh-make isn't so relevant now that debhelper 7 exists. cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules dch --create, manually create debian/control and debian/copyright, and that's about it. That's my opinion, too. bzr is the fourth most popular version control system in Debian according to http://upsilon.cc/~zack/stuff/vcs-usage/. If you're going to demote bzr-builddeb (which doesn't bother me), I think you should also be demoting svn-buildpackage, because svn is horrible and should die. I agree that Subversion should die, but it is still widely used. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: (seemingly) declinging bug report numbers
Am Freitag, den 12.10.2012, 00:00 +0200 schrieb Vincent Bernat: ❦ 11 octobre 2012 22:33 CEST, Benjamin Drung bdr...@debian.org : I can confirm the trend for a couple of organisations. The primary reason that I identified was the retirement of security support for Lenny and that Lenny packages are removed from many Debian mirrors which made it difficult to use Lenny machines. IMHO, supporting an OS release for only 3 years is not long enough. FWIW, it should be noted Ubuntu only supports most packages for 3 years as well. The subset of packages considered for Server support is supported for 5, but most people will suggest you follow the LTS upgrade path, which is very similar to Debian Stable's. Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on the desktop, too. [1] https://wiki.ubuntu.com/LTS This only applies to main, right? main + restricted are supported by Canonical. universe + multiverse are supported by the community (in a best effort manner). -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Poll (was: Popularity of bzr-builddeb and dh-make)
Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise: On Fri, Oct 12, 2012 at 5:35 AM, Benjamin Drung wrote: A poll is a good idea. Can you recommend a site that allows setting up a poll? The Debian secretary was at one point going to setup devotee for this sort of thing, don't think that ever happened though. If you want some FSAAS (free-software-as-a-service), search for doodle on this page: https://wiki.debian.org/FreedomBox/LeavingTheCloud Thanks. I have setup a poll for it: https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/ The poll will be closed in one week (if enough votes are collected). -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
Am Freitag, den 12.10.2012, 21:13 +0900 schrieb Hideki Yamane: - bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed Development, as Ubuntu packaging guide says) way, but now it heavily relies on Launchpad in my point of view. How does bzr-builddeb depend on Launchpad? bzr is integrated into Launchpad, but you can use bzr without Launchpad as every other DVCS. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Vote result (was: Poll (was: Popularity of bzr-builddeb and dh-make))
Hi, the week is over and here are the results from the vote: There were 64 participants in total. dh-make === 46 people want dh-make recommended. 27 people (+ 3 with a question mark) want dh-make suggested. 58 people voted for (at least) one of the above options. Recommending dh-make instead of suggesting was the clear winner. I will move dh-make from Suggests to Recommends in packaging-dev. bzr-builddeb 8 people (+ 3 with a question mark) want bzr-builddeb recommended. 30 people (+ 10 with a question mark) want bzr-builddeb suggested. 44 people voted for (at least) one of the above options. What will I do? Am Samstag, den 13.10.2012, 00:10 +0900 schrieb Charles Plessy: Le Fri, Oct 12, 2012 at 12:06:11PM +0200, Benjamin Drung a écrit : Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise: https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/ The poll will be closed in one week (if enough votes are collected). Hello everybody, if the point is to have a package that pulls everything one needs when doing random work in Debian (as opposed with working specifically in one team where it is predictable which helpers are used and which are not), then I do not understand the point of not including *-buildpackage and dh-make, which are tiny regarding to most other things that mk-builddeps will pull in later. I think that it is exactly the case where we should not vote. Unless the wheight of bzr and dh-make is unbearable to otherwise users of packaging-dev, even if the majority do not use them, what is the harm recommending them ? Not to mention that there is no evidence that the people who vote for or against recommending them are really using packaging-dev... I agree with your opinion. packaging-dev targets especially newcomers and should give them a good starting point. It should allow doing random work in Debian and therefore recommends packages that are used by a portion (could be lower than 50%) of Debian developers. For example, gnome-pkg-tools and pkg-kde-tools are recommended. Not every developer touches a GNOME or KDE packages, but these desktop environments are important enough to recommend these helpers. The poll showed that bzr-builddeb is wanted by a portion of developers (18 % up to 25 %), but not by most of them. Therefore I will keep bzr-builddeb recommended until someone has another good reason to demote the package to suggests. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
