Build of Paje on mipsel : what hapens ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I already sent two mails to [EMAIL PROTECTED] asking why paje.app 1.97-cvs20080110-2 has not been built (no try [1]) on this architecture. I did not get any answer at all. Do I use the good email ? Currently, paje.app is not at all in testing (old long outstanding FTBFS bugs leads to its removal). The new upstream version packaged with the new GNUStep libraries seems to work. I've no bug in unstable since the last upload (42 days ago [2]) So, I've two questions: - - can someone tell me why paje.app has not been tried on mipsel ? What should I do ? - - can the release team give an hint on paje.app 1.97-cvs20080110-2 so that it enters testing immediately (42 days in unstable without any bug, built on all architecture but mipsel (no error in this case, only no try)) Thanks a lot, Vincent [1] http://buildd.debian.org/build.php?arch=mipselpkg=paje.appver=1.97%2Bcvs20080110-2 [2] http://packages.qa.debian.org/p/paje.app.html - -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHx889C/d4Z50CXocRAm6DAJ9BdCELv2ldpSDJ0gVBtJ6Qjf9e3QCfcsmD Aa6I4v8P6FW/kr4F5xjGn9A= =ltsn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Many packaged programs that are doing the same thing
On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Even there, it looks very much like other very small webservers, such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, mini-httpd or thttpd. What does it do better than any of them? Or worse? Or different? Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. There is nothing wrong with having multiple packages in Debian that do the same thing. However, you can wonder whether it is really helpful for the user to have 10 or more light-weight http daemons to choose from. As a distribution, we have a much broader view than the authors of those http daemons. When we see something like this, maybe we should contact the upstream authors and suggest that they work together, so that the number of light-weight daemons to choose from decreases but the quality of the remaining will be better. Again, I'm not saying there should only be one light-weight http daemon. But more than 10? -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Build of Paje on mipsel : what hapens ?
Vincent Danjean [EMAIL PROTECTED] writes: So, I've two questions: - can someone tell me why paje.app has not been tried on mipsel ? What should I do ? Due to kernel problems, the mips* buildds haven't been very reliable in the past few weeks, creating a lng backlog of packages that need to be built. As there seems to be a workaround for the kernel bug, this should start getting better from the weekend on. As a maintainer: Just wait. - can the release team give an hint on paje.app 1.97-cvs20080110-2 so that it enters testing immediately (42 days in unstable without any bug, built on all architecture but mipsel (no error in this case, only no try)) No. Marc -- Fachbegriffe der Informatik - Einfach erklärt 753: Nur der Inhalt zählt! Ich war zu blöd, meinen HTML-Editor richtig zu bedienen. pgpP3cmTa8j37.pgp Description: PGP signature
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
On Fri, Feb 29, 2008 at 10:29:25AM +0100, Guus Sliepen wrote: EDF is the usual name of the company whose logo appears on the upstream web site http://www.code-aster.org/. (The initials used to stand for Electricité de France, but the company has diversified and no longer expands the initials.) Ok. But three letters is not enough for me, who is not French, to know that it stands for the company formerly known as Electricité de France. If that's the legal name of the copyright holder, then that's still how it should be listed in debian/copyright, whether or not it's easy to match the name to a real-world entity. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
On Fri, Feb 29, 2008 at 02:30:29AM +, Ben Hutchings wrote: On Sat, 2008-02-23 at 10:09 +0100, Guus Sliepen wrote: On Sat, Feb 23, 2008 at 01:41:05AM +0100, Sylvestre Ledru wrote: Upstream Author : EDF / RD Please include the full name of the author(s). snip EDF is the usual name of the company whose logo appears on the upstream web site http://www.code-aster.org/. (The initials used to stand for Electricité de France, but the company has diversified and no longer expands the initials.) Ok. But three letters is not enough for me, who is not French, to know that it stands for the company formerly known as Electricité de France. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
Le vendredi 29 février 2008 à 10:29 +0100, Guus Sliepen a écrit : On Fri, Feb 29, 2008 at 02:30:29AM +, Ben Hutchings wrote: On Sat, 2008-02-23 at 10:09 +0100, Guus Sliepen wrote: On Sat, Feb 23, 2008 at 01:41:05AM +0100, Sylvestre Ledru wrote: Upstream Author : EDF / RD Please include the full name of the author(s). snip EDF is the usual name of the company whose logo appears on the upstream web site http://www.code-aster.org/. (The initials used to stand for Electricité de France, but the company has diversified and no longer expands the initials.) Ok. But three letters is not enough for me, who is not French, to know that it stands for the company formerly known as Electricité de France. Well, it is a hugue corporation. I put EDF because it is quite famous. At least I thought... EDF is one of the world's largest producers of electricity. In 2003, it produced 22% of the European Union's electricity, primarily from nuclear power http://en.wikipedia.org/wiki/%C3%89lectricit%C3%A9_de_France What do you want me to put as an author ? Electricité de France would be OK ? Sylvestre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FW by [EMAIL PROTECTED] : Bug#467249: man-db: over sensitive on the spell of locale
On Fri, Feb 29, 2008 at 08:52:12AM +0100, Petter Reinholdtsen wrote: [Michelle Konzack] It seems there is a common problem while setting up the correct UNICODE locale in systems. As the posster in the attached message has written, he has setup his locale to zh_CN.utf8 which is wrong, but as he has written too, the output of locale -a show it. 'locale -a' do not show that the locale is working, it just show what is set in the environment. locale will indicate whether a locale is working by means of the messages it prints on standard error if it isn't: $ LANG=zz_ZZ.utf8 LC_ALL=zz_ZZ.utf8 locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=zz_ZZ.utf8 [...] $ LANG=zh_CN.utf8 LC_ALL=zh_CN.utf8 locale LANG=zh_CN.utf8 [...] (The same goes for 'locale -a', which in fact does not show what is set in the environment at all, but does what it is documented to do: Write names of available locales.) Use 'locale charmap' to check that the locale is working and that the correct character set is selected. If it return 'ANSI_X3.4-1968' (which is ASCII), the locale isn't working (unless it is a locale that uses ASCII, not very likely). If it show 'UTF-8', the locale settings are working. $ LANG=zh_CN.utf8 locale charmap UTF-8 In the case you describe, I believe the only fix is to get the user to stop using an invalid and non-existing locale, It is neither an invalid nor a non-existing locale. It is not in the form documented in /usr/share/i18n/SUPPORTED, but it is in the canonical form into which glibc normalises it internally. See the _nl_normalize_codeset function in glibc/intl/l10nflist.c. and instead use the correct locale string, which I would suspect is 'zh_CN.UTF-8'. The only workaround to this would be to rewrite glibc and locales, and it does not seem useful to me. This is not a glibc bug. This is not a locales bug. This is a man-db bug. I am both the Debian maintainer and the upstream maintainer and I have accepted the bug (see the bug log). I wish people would stop trying to argue that it isn't a bug or that it is a bug somewhere else. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Fri, February 29, 2008 03:02, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. The word different is key here. Debian wants to offer different options to its end users. But please, only options that are significantly different to what we already have. There are several costs associated with having yet another package doing the same thing: * For the project in general, it costs archive and Packages file space, build time, QA efforts just to name a few; * Especially true for network facing services: the security team needs to support every package in stable; * For the administrator: having a choice between a few webservers is good, having to choose between a dozen that are hardly different just troubles their view. You can have too much choice. We can obviously live with the costs that a package incurs, but it makes sense only if there is something that offsets the cost: a clear added value of this package to the distribution. That is something that must be able to be justified when any new package is added. Just because doesn't cut it. Package descriptions should stick to positive aspects of the package, and not try to draw comparisons towards other packages. IMO. A package description is intended for the administrator to choose which of a set of alternatives to install. A comparison to others, or being open about possible limitations, are very helpful to make this decision. It seems to me as if you are trying to get people to justify the packages they want to work on. Yes, and that's very desirable. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Let's kill this part of the discussion right away [was: Re: How to cope with patches sanely]
Manoj Srivastava wrote: And no, I can do this using plain old arch, and I don't really have to change my SCM. But not all Debian maintainers are using git; Version control systems that have content-addressable filesystems (essentially, git and Monotone) are inherently efficient to distribute; [...] Which is great, but I fear it will not fly as a the one and only Ok, I apologise for leaving my note to this effect to the end of my e-mail. But let me repeat. I'm not asking that you change the SCM that you use. I'll say it again, this time for the other subscribers. I'm NOT asking that you change the SCM that you use or the way that you work. All I'm talking about is using git as a replacement for the *source archive* format. How the files are archived and distributed. There are compelling reasons to want to do this; not least getting around the fact that shipping patch series in .diff.gz doesn't handle cases like integration branches without adding a new patch format (which is also something I think is probably useful, and a complementary approach). Thanks for the rest of your e-mail, which contains constructive feedback which I will now digest and respond to! Cheers, Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Many packaged programs that are doing the same thing
Hi, On Fri, 2008-02-29 at 10:38 +0100, Guus Sliepen wrote: On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: Even there, it looks very much like other very small webservers, such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, mini-httpd or thttpd. What does it do better than any of them? Or worse? Or different? Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. There is nothing wrong with having multiple packages in Debian that do the same thing. However, you can wonder whether it is really helpful for the user to have 10 or more light-weight http daemons to choose from. As a distribution, we have a much broader view than the authors of those http daemons. When we see something like this, maybe we should contact the upstream authors and suggest that they work together, so that the number of light-weight daemons to choose from decreases but the quality of the remaining will be better. Again, I'm not saying there should only be one light-weight http daemon. But more than 10? Why not? Debian ships more than 10 different shells, media players, etc. Why should an httpd be not included because there are already others. This isn't about being helpful, this is about _choice_. Have you considered that perhaps the upstreams don't work together because they DON'T WANT TO? Again, it's a matter of _choice_. As a distribution, Debian's goals are to: * provide the widest latitude of free software; * provide the highest quality of packaging of said free software; * ensure the software we ship by default is really free. If that means having a lot of different httpds to choose from, then great! You're not being forced to use them, so why does it matter to you if they are available in Debian? Most software in Debian is maintained for personal reasons, e.g. the maintainer uses it. What further justification than that is required? William signature.asc Description: This is a digitally signed message part
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Hi, On Fri, 2008-02-29 at 11:16 +0100, Thijs Kinkhorst wrote: On Fri, February 29, 2008 03:02, William Pitcock wrote: Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. The word different is key here. Debian wants to offer different options to its end users. But please, only options that are significantly different to what we already have. There are several costs associated with having yet another package doing the same thing: * For the project in general, it costs archive and Packages file space, build time, QA efforts just to name a few; * Especially true for network facing services: the security team needs to support every package in stable; * For the administrator: having a choice between a few webservers is good, having to choose between a dozen that are hardly different just troubles their view. You can have too much choice. Clearly these packages are different enough to somebody if they are going to the effort of packaging them. Perhaps they have a superior configuration format or some other non-notable feature. But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. The main featureset I see here would be: * Anyone could register with it, and upload their packages. There would be buildd's and whatnot, so for all purposes, it would be similar to having packages in Debian proper. * If the package is good, it could be migrated into Debian proper where it would receive proper security team and QA attention. * It would allow people who are having problems finding mentors to upload on their behalf the ability to still contribute to Debian's package collection. Which in turn, would probably eventually lead them towards a mentor. * It would give end users the ability to learn more about DAK and all of the other stuff involved in Debian packaging in a hands-on environment. * It would allow a greater latitude of options while not adding additional workload on the QA and security teams. * Community QA'd, meaning a hands-on learning experience for those who might be interested in joining the QA team. * As it is not an official Debian repo, but instead a community repo, Debian ftp maintainers would choose for themselves whether or not to mirror it, like backports.org. If the project is successful, it could later be offered as an option at install time to get more packages. We can obviously live with the costs that a package incurs, but it makes sense only if there is something that offsets the cost: a clear added value of this package to the distribution. That is something that must be able to be justified when any new package is added. Just because doesn't cut it. Sure in the Debian main repo, but if a community repo existed, it would not matter. Package descriptions should stick to positive aspects of the package, and not try to draw comparisons towards other packages. IMO. A package description is intended for the administrator to choose which of a set of alternatives to install. A comparison to others, or being open about possible limitations, are very helpful to make this decision. Use debtags for that. It seems to me as if you are trying to get people to justify the packages they want to work on. Yes, and that's very desirable. Telling people to go away because you don't want to QA their package is not desirable at all. William signature.asc Description: This is a digitally signed message part
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Fri, February 29, 2008 12:41, William Pitcock wrote: But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. I have no intent of stopping you to create any third party repositories. Sure in the Debian main repo, but if a community repo existed, it would not matter. Definately, but I don't see the relevance because we are talking about a plan to include something the main repo here. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Many packaged programs that are doing the same thing
On Fri, Feb 29, 2008 at 04:58:11AM -0600, William Pitcock wrote: [...] When we see something like this, maybe we should contact the upstream authors and suggest that they work together, so that the number of light-weight daemons to choose from decreases but the quality of the remaining will be better. Again, I'm not saying there should only be one light-weight http daemon. But more than 10? Why not? Debian ships more than 10 different shells, media players, etc. Why should an httpd be not included because there are already others. This isn't about being helpful, this is about _choice_. When does it stop? After 20 httpds? 50? 1000? Surely there is a point where there is too much choice. So if we, as a distributor with an overview of the situation, see that there is so much choice, which can be good but _not necessarily_, we should put some effort in determining if we can improve the situation. For example: if two light-weight httpds have a very similar feature set, then if the two upstream maintainers can be made to work together and create a single httpd with the best qualities of both, then that will reduce choice, but the one choice left is better than both old choices. Have you considered that perhaps the upstreams don't work together because they DON'T WANT TO? Again, it's a matter of _choice_. Other possibilities: upstream doesn't know that there are other software packages available that do what they want. Or maybe he doesn't want to work together with other upstreams for the wrong reasons. As a distribution, Debian's goals are to: * provide the widest latitude of free software; * provide the highest quality of packaging of said free software; * ensure the software we ship by default is really free. Not only the highest quality of packaging, we also want to make sure the software itself is of good quality. Otherwise, why would we bother tracking upstream bugs? If that means having a lot of different httpds to choose from, then great! You're not being forced to use them, so why does it matter to you if they are available in Debian? Most software in Debian is maintained for personal reasons, e.g. the maintainer uses it. What further justification than that is required? If we can create even better httpds by merging the development efforts, then yes it does matter to me. I want high quality software. I don't want a lot of choice of bad quality software. I am not saying that more or less httpds to choose from is good or bad in itself, but more than 10 light-weight httpds might be an indication that there is room for improvement. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)
On Fri, 29 Feb 2008, William Pitcock wrote: But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. Please don't! Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Many packaged programs that are doing the same thing
On Fri, 29 Feb 2008, Guus Sliepen wrote: For example: if two light-weight httpds have a very similar feature set, then if the two upstream maintainers can be made to work together and create a single httpd with the best qualities of both, then that will reduce choice, but the one choice left is better than both old choices. Just for the record: This is what we try in the Custom Debian Distribution effort in Debian-Med: Talk to upstream, suggest them to join forces, find reasonable ways of cooperation. The group of maintainers of a CDD have an overview about packages that are needed in their field and thus are able to see inter-package connections. Building a distribution is more than just adding packages to a pool. It is about creating a work environment for users freeing them from the work to compile programs from sources on one hand but also give some reasonable advise and freeing them from the work to do research which package might fit their needs best. I personally really hate to pick a random package out of 10 or more. There would be less work to compile _the_ _right_ one from source instead of selecting it out of 10 prebuilded packages. If we can create even better httpds by merging the development efforts, then yes it does matter to me. ... Well said. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote: Ian Jackson [EMAIL PROTECTED] writes: What I am trying to achieve is to use git in the proper way: that is, in a way which makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. This makes it more difficult to ask for review while the branch is in progress, which is a valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. Usually, I make branches public when my log looks sane. And it's not absurd, is to allow everyone to be kept sane when looking the log in 5 years forward. I have never once run into this problem with other revision control systems in which branching and merging are common. Somehow it just never seems to be a real issue. I contend that dpkg is not big enough for it to become a real issue. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468510: ITP: octave-nnet -- A feed forward multi-layer neural network
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-nnet Version : 0.1.6 Upstream Author : Michael Schmid * URL : http://octave.sourceforge.net/nnet/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : A feed forward multi-layer neural network This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468515: ITP: octave-optim -- Unconstrained Non-linear Optimization toolkit
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-optim Version : 1.0.2 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/optim/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Unconstrained Non-linear Optimization toolkit This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468498: ITP: octave-control -- Additional Octave Control tools
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-control Version : 1.0.5 Upstream Author : Ben Sapp * URL : http://octave.sourceforge.net/control/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Additional Octave Control tools This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468505: ITP: octave-informationtheory -- Functions and routines for basic Information Theory definitions, and source coding
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-informationtheory Version : 0.1.4 Upstream Author : Muthiah Annamalai * URL : http://octave.sourceforge.net/informationtheory/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Functions and routines for basic Information Theory definitions, and source coding This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468502: ITP: octave-gsl -- Octave bindings to the GNU Scientific Library
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-gsl Version : 1.0.4 Upstream Author : Teemu Ikonen [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/gsl/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Octave bindings to the GNU Scientific Library This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468524: ITP: octave-special-matrix -- Additional Special Matrices for Octave
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-special-matrix Version : 1.0.4 Upstream Author : Paul Kienzle [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/special-matrix/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Additional Special Matrices for Octave This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468503: ITP: octave-ident -- Addition System Indentification Control functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-ident Version : 1.0.4 Upstream Author : Paul Kienzle * URL : http://octave.sourceforge.net/ident/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Addition System Indentification Control functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468495: ITP: octave-audio -- Audio recording, processing and playing tools
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-audio Version : 1.1.0 Upstream Author : Paul Kienzle * URL : http://octave.sourceforge.net/audio/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Audio recording, processing and playing tools This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468529: ITP: octave-symbolic -- Symbolic toolbox based on GiNaC and CLN
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-symbolic Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/symbolic/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Symbolic toolbox based on GiNaC and CLN This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468533: ITP: octave-ad -- Automatic Forward Differentiation
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-ad Version : 1.0.1 Upstream Author : Thomas Kasper * URL : http://octave.sourceforge.net/ad/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Automatic Forward Differentiation This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468496: ITP: octave-combinatorics -- Combinatorics functions, incuding partitioning
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-combinatorics Version : 1.0.5 Upstream Author : Torsten Finke [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/combinatorics/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Combinatorics functions, incuding partitioning This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468499: ITP: octave-econometrics -- Econometrics functions including MLE and GMM based techniques
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-econometrics Version : 1.0.5 Upstream Author : Michael Creel [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/econometrics/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Econometrics functions including MLE and GMM based techniques This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson [EMAIL PROTECTED] writes: Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): As soon as you edit commits, they'll get a new id, and thus you'll disrupt merging. As I thought. What I am trying to achieve is to use git in the proper way: that is, in a way which makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. Usually, I make branches public when my log looks sane. And it's not absurd, is to allow everyone to be kept sane when looking the log in 5 years forward. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468528: ITP: octave-struct -- Additional Structure manipulations functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-struct Version : 1.0.4 Upstream Author : Etienne Grossmann * URL : http://octave.sourceforge.net/struct/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Additional Structure manipulations functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468542: ITP: octave-mapping -- Simple Mapping functions.
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-mapping Version : 1.0.4 Upstream Author : Andrew Collier [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/mapping/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Simple Mapping functions. This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468512: ITP: octave-octgpr -- The package allows interpolating and smoothing scattered
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-octgpr Version : 1.1.1 Upstream Author : Jaroslav Hajek ([EMAIL PROTECTED]) * URL : http://octave.sourceforge.net/octgpr/index.html * License : GPL v2 Programming Lang: C++, Octave Description : The package allows interpolating and smoothing scattered This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468501: ITP: octave-general -- General tools for octave
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-general Version : 1.0.5 Upstream Author : Various authors * URL : http://octave.sourceforge.net/general/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : General tools for octave This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468497: ITP: octave-communications -- Digital Communications, Error Correcting Codes (Channel Code), Source Code functions, Modulation and Galois Fields
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-communications Version : 1.0.5 Upstream Author : David Bateman * URL : http://octave.sourceforge.net/communications/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Digital Communications, Error Correcting Codes (Channel Code), Source Code functions, Modulation and Galois Fields This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468517: ITP: octave-outliers -- Grubbs, Dixon and Cochran tests for outlier detection
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-outliers Version : 0.13.6 Upstream Author : Lukasz Komsta * URL : http://octave.sourceforge.net/outliers/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Grubbs, Dixon and Cochran tests for outlier detection This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468540: ITP: octave-java -- Provides Java interface with OO-like Java objects manipulation
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-java Version : 1.2.3 Upstream Author : Michael Goffioul [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/java/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Provides Java interface with OO-like Java objects manipulation This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468538: ITP: octave-graceplot -- Graceplot bindings for octave
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-graceplot Version : 1.0.4 Upstream Author : Teemu Ikonen * URL : http://octave.sourceforge.net/graceplot/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Graceplot bindings for octave This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468535: ITP: octave-civil-engineering -- Functions to solution some ODE's in Civil Engineering
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-civil-engineering Version : 1.0.4 Upstream Author : Matthew W. Roberts * URL : http://octave.sourceforge.net/civil-engineering/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Functions to solution some ODE's in Civil Engineering This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468537: ITP: octave-fpl -- Collection of routines to plot data on unstructured triangular and tetrahedral meshes
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-fpl Version : 0.1.1 Upstream Author : Carlo de Falco and Massimiliano Culpo * URL : http://octave.sourceforge.net/fpl/index.html * License : GNU/GPL Programming Lang: C++, Octave Description : Collection of routines to plot data on unstructured triangular and tetrahedral meshes This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468504: ITP: octave-image -- The Octave-forge Image package provides functions for
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-image Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/image/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : The Octave-forge Image package provides functions for This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468527: ITP: octave-strings -- Additional manipulation functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-strings Version : 1.0.4 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/strings/index.html * License : See individual files Programming Lang: C++, Octave Description : Additional manipulation functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468519: ITP: octave-physicalconstants -- Physical Constants from Atomic Molecular Physics, taken from NIST database
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-physicalconstants Version : 0.1.4 Upstream Author : Muthiah Annamalai * URL : http://octave.sourceforge.net/physicalconstants/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Physical Constants from Atomic Molecular Physics, taken from NIST database This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468507: ITP: octave-irsa -- Irregular sampling analysis
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-irsa Version : 1.0.4 Upstream Author : Joerg Huber * URL : http://octave.sourceforge.net/irsa/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Irregular sampling analysis This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468518: ITP: octave-parallel -- Parallel execution package for cluster computers
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-parallel Version : 1.0.5 Upstream Author : Hayato Fujiwara * URL : http://octave.sourceforge.net/parallel/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Parallel execution package for cluster computers This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468541: ITP: octave-jhandles -- JHandles is a java- and openGL-based alternative graphics
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-jhandles Version : 0.3.2 Upstream Author : Michael Goffioul [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/jhandles/index.html * License : GPL version 2 or later / LGPL Programming Lang: C++, Octave Description : JHandles is a java- and openGL-based alternative graphics This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468525: ITP: octave-splines -- Additional Cubic spline functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-splines Version : 1.0.4 Upstream Author : Kai Habel and Paul Kienzle * URL : http://octave.sourceforge.net/splines/index.html * License : GPL v2 or later, and Public Domain Programming Lang: C++, Octave Description : Additional Cubic spline functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468534: ITP: octave-bim -- Package for solving Diffusion Advection Reaction (DAR) Partial Differential Equaltions based on the Finite Volume Scharfetter-Gummel (FVSG) method a.k.a Box Integration
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-bim Version : 0.0.5 Upstream Author : Carlo de Falco, Culpo Massimiliano * URL : http://octave.sourceforge.net/bim/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Package for solving Diffusion Advection Reaction (DAR) Partial Differential Equaltions based on the Finite Volume Scharfetter-Gummel (FVSG) method a.k.a Box Integration Method (BIM) This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468532: ITP: octave-zenity -- A set of functions for creating simple graphical
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-zenity Version : 0.5.4 Upstream Author : S?ren Hauberg * URL : http://octave.sourceforge.net/zenity/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : A set of functions for creating simple graphical This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468506: ITP: octave-io -- Input/Output in external formats
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-io Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/io/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Input/Output in external formats This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468509: ITP: octave-miscellaneous -- Miscellaneous tools including waitbar, xml tools, etc
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-miscellaneous Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/miscellaneous/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Miscellaneous tools including waitbar, xml tools, etc This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468514: ITP: octave-odepkg -- A toolkit for Differential Equations and Initial Value Problems
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-odepkg Version : 0.4.1 Upstream Author : Thomas Treichl * URL : http://octave.sourceforge.net/odepkg/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : A toolkit for Differential Equations and Initial Value Problems This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468530: ITP: octave-time -- Additional date manipulation tools
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-time Version : 1.0.5 Upstream Author : Bill Denney [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/time/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Additional date manipulation tools This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468523: ITP: octave-specfun -- Special functions including ellipitic functions, etc
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-specfun Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/specfun/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Special functions including ellipitic functions, etc This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468522: ITP: octave-sockets -- Socket functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-sockets Version : 1.0.3 Upstream Author : John Swensen [EMAIL PROTECTED] * URL : http://octave.sourceforge.net/sockets/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Socket functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468513: ITP: octave-odebvp -- To approximate the solution of the boundary-value problem y''=p(x)*y' + q(x)*y + r(x), a=x=b, y(a)=alpha, y(b)=beta by the linear finite-diffence method
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-odebvp Version : 1.0.3 Upstream Author : Tiago Charters de Azevedo * URL : http://octave.sourceforge.net/odebvp/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : To approximate the solution of the boundary-value problem y''=p(x)*y' + q(x)*y + r(x), a=x=b, y(a)=alpha, y(b)=beta by the linear finite-diffence method This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468526: ITP: octave-statistics -- Additional statistics functions for Octave
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-statistics Version : 1.0.5 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/statistics/index.html * License : See individual files Programming Lang: C++, Octave Description : Additional statistics functions for Octave This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468500: ITP: octave-fixed -- Fixed point real and complex matrix toolbox
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-fixed Version : 0.7.5 Upstream Author : David Bateman * URL : http://octave.sourceforge.net/fixed/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Fixed point real and complex matrix toolbox This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)
On Fri, Feb 29, 2008 at 9:18 PM, Andreas Tille [EMAIL PROTECTED] wrote: On Fri, 29 Feb 2008, William Pitcock wrote: But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. Please don't! Why not? unsupported.d.n could be the right place for packages that are not good enough for Debian (yet). It could be a good place to merge packages removed from Debian for having no users (or whatever), uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other Debian-based distros that have public archives. A while ago on -devel there was a post about automatic creation of rough packages using automatic software discovery and AI techniques for the packaging, such packages could be uploaded to unsupported. Upstreams often make Debian packages but don't upload them anywhere, unsupported could be a place for them. I've often wanted to package some cool software (see the list on my wiki page), but not maintain it forever, so I didn't bother and just moved on. Instead I could just upload to unsupported. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mass ITPs
Hi Rafael, all, Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#468183: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)
I created an updated description. Please see below. One thing i forgot to mention earlier was the feature of logging the http requests directly to a mysql-database. I'm not quite sure, but I think this feature is not supported by most other webservers. Description: small http server Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web server. It implements the following features: . * multi-threading * support for MIME * resume * virtual hosts * CGI and PHP * directory navigation * basic security features (denying access to certain URLs and IPs) * logging directly to a mysql-database instead of using logfiles. * translated documentation . Regards, Thorsten On 29/02/08 13:18 +0100, Andreas Tille wrote: On Fri, 29 Feb 2008, William Pitcock wrote: But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. Please don't! Kind regards Andreas. -- http://fam-tille.de -- MY SUSPENSION WAS NOT MUTUAL MY SUSPENSION WAS NOT MUTUAL MY SUSPENSION WAS NOT MUTUAL MY SUSPENSION WAS NOT MUTUAL Bart Simpson on chalkboard in episode BABF10 signature.asc Description: Digital signature
Re: Many packaged programs that are doing the same thing
[William Pitcock] Why not? Debian ships more than 10 different shells, media players, etc. Why should an httpd be not included because there are already others. This isn't about being helpful, this is about _choice_. You seem to assume that choice is good, and more choices are better. This is not always the case. To answer your question about why not, the key point is cognitive strain. Every new option increases the cognitive strain on the person having to select between them. This make me believe it is a good idea to not increase the cognitive strain on our users without a good reason to do it, and thus limit the available options in Debian to those that make most sense to include, and no more and no less. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468521: ITP: octave-signal -- Signal processing tools, including filtering, windowing and display functions
Package: wnpp Severity: wishlist Owner: Debian Octave Group [EMAIL PROTECTED] [N.B.: This ITP was generated automatically from a template, even though the DOG does intend to package the described software for Debian. We apologize for the glitches in the text below.] * Package name: octave-signal Version : 1.0.6 Upstream Author : Various Authors * URL : http://octave.sourceforge.net/signal/index.html * License : GPL version 2 or later Programming Lang: C++, Octave Description : Signal processing tools, including filtering, windowing and display functions This is one of the packages distributed by the octave-forge project using the pkg.m system introduced in version 3 of Octave [1], a numerical computation software. Although users can use directly the pkg() command for installing the octave-forge pkgs, the Debian Octave Group (DOG) [2] will provide them as Debian packages. Preliminary versions of the packages can be found in the DOG SVN repository [3]. The final versions of the packages will be built using the octave-pkg-dev insfrastructure [4] [5]. The full list of octave-forge pkgs can be found at the SF project website [6]. [1] http://www.octave.org/ [2] http://pkg-octave.alioth.debian.org/ [3] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0sc=0 [4] http://svn.debian.org/wsvn/pkg-octave/octave-pkg-dev/?rev=0sc=0 [5] http://bugs.debian.org/468311 [6] http://octave.sourceforge.net/packages.html -- Rafael Laboissiere, in the behalf of the DOG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Le Friday 29 February 2008 11:16:04 Thijs Kinkhorst, vous avez écrit : There are several costs associated with having yet another package doing the same thing: * For the project in general, it costs archive and Packages file space, build time, QA efforts just to name a few; You're mixing different things.. Storage is one, but I don't think a light package is an issue here, QA is another. For the QA effort, I'd rather prefer yet another package that is well maintained, for which the maintainer cares about RC issues, security fixes etc.. to a massively popular package unmaintained, and I have example on this topic... * Especially true for network facing services: the security team needs to support every package in stable; Again, the maintainer has a role to play, and can often help seciruty fixes quite well.. * For the administrator: having a choice between a few webservers is good, having to choose between a dozen that are hardly different just troubles their view. You can have too much choice. Do you really believe in such an argument ? Well, administrators are wise people. In particular with http servers, first most of them will install apache without thinking of anything else, and I don't think the remainers will cry a river because apt-cache search httpd returns too many results. But, yes, the description needs to be relevant. Now, for the fundamental, since it seems no one returned to it, I found the webpage of the project well done, the code is hosted in a git repo, maintenance seems to be done. So, unless legal issues, if the proposed maintainer has a package well done and is willing to maintain it, I don't see what we're discussing here. Romain
Re: mass ITPs
On Fri, 29 Feb 2008, Paul Wise wrote: Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? That would defeat a lot of the purpose of the ITPs (like looking at the descriptions, etc). I think we just have to deal with it, they are not as common as to be a major nuisance at all. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
William Pitcock dijo [Fri, Feb 29, 2008 at 05:41:25AM -0600]: Clearly these packages are different enough to somebody if they are going to the effort of packaging them. Perhaps they have a superior configuration format or some other non-notable feature. But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. The main featureset I see here would be: * Anyone could register with it, and upload their packages. There would be buildd's and whatnot, so for all purposes, it would be similar to having packages in Debian proper. * If the package is good, it could be migrated into Debian proper where it would receive proper security team and QA attention. (...) Why not instead call it http://www.apt-get.org? -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
William Pitcock dijo [Fri, Feb 29, 2008 at 05:41:25AM -0600]: But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. The main featureset I see here would be: * Anyone could register with it, and upload their packages. There would be buildd's and whatnot, so for all purposes, it would be similar to having packages in Debian proper. BTW, and on a much more serious tone: I do not trust anyone (hell, I often don't even trust myself! My hat off to our always kind ftp-masters) to check for proper licensing terms. And we cannot afford to have non-distributable or otherwise illegal content distributed from within Debian, however unofficial it looks like. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported?
Hi, On Fri, 2008-02-29 at 21:54 +0900, Paul Wise wrote: unsupported.d.n could be the right place for packages that are not good enough for Debian (yet). It could be a good place to merge packages removed from Debian for having no users (or whatever), uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other Debian-based distros that have public archives. A while ago on -devel there was a post about automatic creation of rough packages using automatic software discovery and AI techniques for the packaging, such packages could be uploaded to unsupported. Upstreams often make Debian packages but don't upload them anywhere, unsupported could be a place for them. I've often wanted to package some cool software (see the list on my wiki page), but not maintain it forever, so I didn't bother and just moved on. Instead I could just upload to unsupported. As I see it, unsupported would be: * packages excluded from main for whatever reason (think: GTK1, XMMS), * packages not yet good enough for main (or not yet sponsored, uploading to mentors could automatically put built packages in unsupported, for example.), * packages that someone made, but does not want to maintain, * community maintained (e.g. you could bump the version by uploading to mentors, or uploading directly to unsupported if you are a DD/DM), * and most importantly _UNSUPPORTED_. That said, provided that it's clear that it's _UNSUPPORTED_, it could become an additional asset for Debian users. The community maintainance concept has proven to be quite reasonable, other projects have had great success with this sort of thing, think ArchLinux's AUR, Gentoo's Sunrise Overlay, etcetera. Yes, some person can upload an evil package, but with proper moderation, evil packages can be dealt with in a timely manner. Did I mention that it is unsupported? William signature.asc Description: This is a digitally signed message part
Re: mass ITPs
* Paul Wise [Fri, 29 Feb 2008 21:59:58 +0900]: Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? (Without entering to discuss the subject matter, just a clarification: they could go to submit@ as usual, with just removing the usual X-Debbugs-CC to -devel that reportbug adds. IOW it's not debbugs that's sending a copy to -devel on its own afaik.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Love in your heart wasn't put there to stay. Love isn't love 'til you give it away. -- Oscar Hammerstein II -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mass ITPs
Hi, On Fri Feb 29, 2008 at 21:59:58 +0900, Paul Wise wrote: Hi Rafael, all, Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? And/or creating a new mailing list, debian-itp, debian-devel-itp or whatever might be a good idea. Quite a big number of mails to the debian-devel mailing list are ITPs. Greetings Martin -- Martin Zobel-Helas [EMAIL PROTECTED] | Debian Release Team Member Debian GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported?
On Fri, Feb 29, 2008 at 11:47:25AM -0600, William Pitcock wrote: Did I mention that it is unsupported? So if it's unsupported, set it up yourself instead of asking Debian to dedicate resources to it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri February 29 2008 09:26:32 Henrique de Moraes Holschuh wrote: On Fri, 29 Feb 2008, Mike Bird wrote: I'm not a DD but I've been programming since 1963 when I was 7. Based on decades of software engineering experience, I would just like to remind you to USE THE FSCKING SOURCE!!! I am not sure this applies to dpkg, but in kernel land, the full reasoning behind even one-line trivial patches to some deep-magic areas are just plain impossible to understand without a ton of explanations in the log. Irrelevant. The size and complexity of dpkg are not in the same ballpark, county, state, country, or hemisphere as the kernel. Logs are not the source. No matter how much time you waste fiddling with them, they are really unimportant. Programmers Sorry, I don't agree with you. Logs are important. Especially if one member of the team quits, and another has to join in and find out exactly what was happening to the code at that point in time (as opposed to reading the code at that point in time, to know how it looked like). A log by this measure has temporary value during development of a new feature. Thereafter the value is negligable. Therefore by this measure it is not worth spending time prettifying logs for git merges of completed features. should be documented in a design document or noted in a comment. Comments have this very bad property of getting stale, which really is a damn pity, as comments are in the code and therefore extremely more likely to be read by someone trying to modify that area of the code. Logs are never stale, as they are only valid at one exact point in time and they are tied to a specific set of changes anyway. But they don't have the extreme advantage of locality that comments do. You need *both*, and you need to take good care of *both*. You may wish to have both logs and comments but you have not demonstrated any value to logs other than for WIP, nor any return on the investment of Ian's time to prettify logs for you. Time spent prettifying logs is time that could be better spent programming or packaging or playing with the grandkids. That does not work well in large development teams. I confess I've only worked on development teams ranging from one to a few hundred developers. dpkg has how many thousand developers? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported?
Hi, On Fri, 2008-02-29 at 09:57 -0800, Steve Langasek wrote: So if it's unsupported, set it up yourself instead of asking Debian to dedicate resources to it. I wasn't aware that I was asking Debian to dedicate resources to it. William signature.asc Description: This is a digitally signed message part
Bug#468638: ITP: libdbd-mock-perl -- Mock database driver for testing
Package: wnpp Severity: wishlist Owner: Jaldhar H. Vyas [EMAIL PROTECTED] * Package name: libdbd-mock-perl Version : 1.36 Upstream Author : Chris Winters [EMAIL PROTECTED], Stevan Little [EMAIL PROTECTED], Rob Kinyon [EMAIL PROTECTED] * URL : http://www.example.org/ * License : GPL + Artistic Programming Lang: Perl, Python, etc Description : Mock database driver for testing Testing with databases can be tricky. If you are developing a system married to a single database then you can make some assumptions about your environment and ask the user to provide relevant connection information. But if you need to test a framework that uses DBI, particularly a framework that uses different types of persistence schemes, then it may be more useful to simply verify what the framework is trying to do -- ensure the right SQL is generated and that the correct parameters are bound. DBD::Mock makes it easy to just modify your configuration (presumably held outside your code) and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql) in your framework. I'm packaging this as it is a build-dependency of libcgi-application-plugins-perl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468314: RFH: k3b -- A sophisticated KDE CD burning application
Hi, I request a co-maintainer for K3b. You can join us. We maintain Qt, KDE and KDE related packages in pkg-kde on alioth. On my list of things to do is merge the packaging with the Ubuntu version and try to collaborate more with the Ubuntu maintainers. We work in collaboration with kubuntu people and we sync regularly our packages with them. cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
Lucas wrote: On 28/02/08 at 01:09 -0800, Steve Langasek wrote: Yes, subjective to the point of absurdity. If failure is defined in terms of *your* expectations, I don't see how we can even have a meaningful dialogue about it. Note that my main point in the thread is we should use GSOC to get fresh blood in Debian, not to fund existing contributors. The point about Debian GSOC projects have been unsuccessful in the past is totally secondary. I am under the impression that results from last years' GSOC projects weren't up to par with what could have reasonably been expected from them, based on the skills of the students and the time they were supposed to spend on the projects. Maybe I'm wrong, but it will be difficult for you to convince me of that, since we lack data :-) But that's not going to stop you making accusations of previous GSoC students and mentors misleading Google about how time was spent, though. That's *nice* to see. but I think that the evaluation done by the mentors is subjective too. How were the GSOC projects evaluated? I don't know how they were evaluated, but why are you only now asking this question, and of debian-devel instead of the program mentors? Mainly because GSOC 2008 was announced on d-d-a with a reply-to set to [EMAIL PROTECTED] Not quite: * Mail-followup-to: debian-devel@lists.debian.org * Reply-to: [EMAIL PROTECTED] I deliberately set the Reply-to to point to debian-project, but it seems that the d-d-a list then helpfully added a different target in the M-F-T header... :-( Also, my goal is not to do a witch hunt about last years' projects. Frankly, I don't care. My goal is to see if we can improve things this year (if there's something to improve). If your goal was not to have a witch hunt, then being a *lot* less aggressive and accusatory in your mails here would help. snip I'm not saying that students that were DD did nothing of their time during GSoc, but most of them produced results that were a bit disappointing given what people could have expected from them, mainly because they used their GSOC time to work on other Debian tasks. Do you have any proof at all for that accusation? If so, please share it. Otherwise, I think that people deserve apologies from you right now. Here's a hint: even when working full-time hours on a job (35-40 hours a week, typically), it's entirely possible to do other things in your other time. I have a full-time job working for a company in Cambridge, yet I spend some of my spare time to work on Debian projects, DebConf etc. alongside that. Are you going to accuse me of stealing time from my employer to do them? In past years, the GSoC mentors and admins have ranked student applications based on a few criteria: * How interesting the project is for Debian (and how well it fits with us and our needs) * How good we reckon the student is: motivation, skills, enthusiasm, dedication * Whether or not we have a suitable mentor The ideal student applying will take inspiration from the project ideas we've posted, but will take the extra time to turn those suggestions into their own proposal. Background research and a genuine understanding of the problem are good indicators here. In 2006, only 6 of our allotted 10 projects completed successfully. The Google folks informally told us that that was not good enough - we were well below the average of the programme as a whole. We were allowed back in for 2007, but were only awarded funding for 9 projects of the 20 or so that we asked for. Given that, there was a lot of debate about exactly which projects we should choose. I'm happy that we picked a very good set. There was scope to have made different selections here and there, but the 9 that we chose all succeeded: they all met their goals. I'm not greatly convinced by your arguments that DDs and DMs should automatically be barred from applying for GSoC. In my opinion, they are just as welcome as anybody else. Each application should be evaluated fairly on its own merits. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mass ITPs
On Fri, 29 Feb 2008, Martin Zobel-Helas wrote: And/or creating a new mailing list, debian-itp, debian-devel-itp or whatever might be a good idea. Quite a big number of mails to the debian-devel mailing list are ITPs. I also thought the same some time ago, on the other hand development of Debian means in big parts packaging software (as opposed to work on the infrastructure) and as such it makes sense to have ITP on devel. That said, the benefits are not that important: review of description and package names and in some cases discussion of the usefulness of the package. Are there other ways to get the same result without involving the -devel list? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468651: ITP: libsub-wrappackage-perl -- add wrappers around subroutines in packages.
Package: wnpp Severity: wishlist Owner: Jaldhar H. Vyas [EMAIL PROTECTED] * Package name: libsub-wrappackage-perl Version : 1.2 Upstream Author : David Cantrell [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Sub-WrapPackages/ * License : GPL + Artistic Programming Lang: Perl Description : add wrappers around subroutines in packages. This is mostly a wrapper around Damian Conway's Hook::LexWrap module The differences are: * no exporting We don't export a wrap() function, instead preferring to do all the magic when you use this module. We just wrap named subroutines, no references. * the subs and packages arrayrefs Any subroutine mentioned in the subs parameter will be wrapped. Any packages mentioned in the packages parameter will have all their subroutines wrapped. * wrap_inherited In conjunction with the packages arrayref, this wraps all calls to inherited methods made through those packages. If you call those methods directly in the superclass then they are not affected. * parameters passed to your subs Your pre-wrapper will be passed the wrapped subroutine's name, and all the parameters to be passed to it. I'm packaging this as it is a build-dependency to libcgi-applications-plugin-perl. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
* Ben Finney: It's no security risk to unpack a tarball, apply a patch to it via GNU 'patch', and examine the result. History should tell you that this is not true. 8-) I can even understand people who state that GNU tar should never be used to uncompress tarballs from untrusted sources, and we therefore do not need to provide security support for it, but this is going a bit too far for my taste. But my point really is: Please do do not use potential security issues as arguments. The overall situation is sufficiently bad that this can be used to prove *anything*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mass ITPs
On Fri, Feb 29, 2008 at 06:44:40PM +0100, Martin Zobel-Helas wrote: On Fri Feb 29, 2008 at 21:59:58 +0900, Paul Wise wrote: Hi Rafael, all, Perhaps in future mass ITPs could be mostly filed with only one to [EMAIL PROTECTED] and the rest to [EMAIL PROTECTED] instead? And/or creating a new mailing list, debian-itp, debian-devel-itp or whatever might be a good idea. Quite a big number of mails to the debian-devel mailing list are ITPs. Hrm, or people could just subscribe to debian-wnpp and filter out the stuff they are not interested in... Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
* Manoj Srivastava: But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. As each feature branch was created or developed, if there were any conflicts, these conflicts were resolved in the integration branch. And the integration branch does not keep track of what changes come from which branch -- that is not its job. And it does not keep the integration patches up to date either -- that again is not its job. Details below. There are some systems that automatically push changes on a branch to all branches that branched from it (Clearcase is in that category, IIRC, and Aegis does something similar). My experience with Aegis is that this is usually *not* what you want, and the prevalent DVCS model uniformly rejects this idea. However, this would help to get rid of the integration branch. Changes to lower branches would bubble up, if necessary with manual help, and a separate integration branch would not be necessary. I'm not sure if this is actually workable (probably not with the branching model currently in fashion), but it might be. Anyway, this gets me back to my original question: Is there tools support for dealing with patch series (quilt or dpatch) which lets me bubble up patches (including new upstream versions, at least conceptually) and sink them down the queue? With three-way merging, so that it's comparable to typical in-VCS operation? Has anybody written the converse to git-quiltimport (which should go to great lengths not to create any gratuitous changes), and a port of that script to dpatch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
Sylvestre Ledru [EMAIL PROTECTED] writes: What do you want me to put as an author ? Electricité de France would be OK ? In that case, I might give both the current legal form and a clarifying comment: EDF S.A. (historically named Electricité de France) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Fri, Feb 29, 2008 at 05:11:17PM +0100, Raphael Hertzog wrote: But Guillem wants to review and understand the code. In this process, he will rearrange the changes in smaller logical chunks. Ah, the impression that has been created on the lists is more that the patches were being NACKed and wouldn't be looked at until the logs had been rewritten. I guess that's a bit less of a bad situation. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: Unsupported?
* Thorsten Schmale: I created an updated description. Please see below. One thing i forgot to mention earlier was the feature of logging the http requests directly to a mysql-database. I'm not quite sure, but I think this feature is not supported by most other webservers. We've already got libapache2-mod-log-sql. (I wouldn't recommend using it either, though.) Most web servers support SQL logging in some form or other. There are also tons of converters to load Common Log format files into SQL databases. Are you sure that MonkeyD logs requests containing ' characters correctly? The source code doesn't look like it. (You may have to use telnet/socket/nc manually, to prevent escaping from the browser.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
* Lucas Nussbaum: I have had a problem with the way GSOC was handled in Debian in the past years. Me too, but I've seen exactly the opposite: someone was funded who wasn't really active in the area of the project where he worked on, and didn't use existing interfaces etc. to implement his project. I had no idea how to follow his progress, or how to make sure that the end result is something we could actually use at Debian (or our users could use, for that matter). And I'm not really concerned by DDs being paid under the project (my usual reservations towards Google notwithstanding). This is Google's project, if they care about conflict of interest, they should investigate them before making a decision. As long as they pick the actual beneficiaries, we don't need to discuss this to death. It's not like they are paying for the addition of a new architecture to the archive or something like that. (By the way, if someone in south-western Germany thinks they have got an interesting summer project for Debian, particularly in the area of security or systems management, they should contact me.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Sat, Jan 26, 2008 at 11:39:32PM +0100, Pierre Habouzit wrote:
Another thing is that people have the old habit to see the source
package be the preferred form of modification for a Debian package.
Hmm. This started off a train of thought. In one sense, one
could see the source code for the binary package as the sources
delivered by applying the diff.gz to the upstream tarball, and the rest
merely tools to deliver the sources, somewhat like editors. I don't
want to go down that debate, since the binary blob people would jump in
and claim that the hardware editors creating the binary blobs are,
ummm, editors.
David Nusinow has criticized my methodology as delivering a
mostly opaque diff.gz; and I have been thinking about that too. The
criticism has merit; and I allowed myself to get distracted by the
whole quilt subthread, which was a red herring. quilt introduces
linearlization of patches, etc, and ordering, which were merely
distractions.
But the comment above by Pierre got me thinking: when someone
reports a bug in my package, and I fix it, or when I add a whole new
feature; I do not do it on the integration branch. I do it on a new
branch, dedicated to that series of fixes or the new feature, and the
goal of the branch is to maintain a clean topic patch to feed
upstream. I then post the same fix into the integration branch, easily
done. So the modifications are being made in a topic branch -- but
then, I ship only the integration branch (which is what the diff.gz
represents) in the source package.
So, in a very real sense, I do not ship the branch where I
prefer to make the changes.
Now, David had a point that people who need to make changes need
to understand how to take the diff.gz apart, and understand what parts
of the diff.gz correspond to which logical line of development. This
annotation of the diff lies in the topic branches; the integration
branch has elided the annotation, in one sense. So, by only shipping
the integration branch (as a diff.gz), I am eliding information that is
present in my SCM, and not presenting that to the end user. This is not
a good thing.
Then it struck me: why not present the end users with the same
environment and history that I have when I make changes? So, here are
the goals of my proposal:
A) All the branches that I use (the pure feature branches, the
upstream branch, and the integration branch) should be made
available to the users. This will give them the same environment I
have, and thus they have the preferred place to make modifications.
B) When people do dpkg-source -x, they should have a fully unpacked
tree that is compiled, with no further action that needs to be
taken
C) In order to reconstitue all the other branches, no network
connectivity should be required. There a lot of people in the
developing world that do not have a readily available network
connection -- my solution must work with source DVD's
D) No knowledge of my SCM should be required. People should be able
to construct the topic branches without knowing arch or git or bzr
or Hg or what have you.
Now, a lot of what I need is already present.
1) the orig.tar.gz represents the upstream branch, exactly.
2) the diff.gz + orig.tar.gz represents the integration branch,
exactly.
So the missing thing is the topic branches.
3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
files. Each diff, applied to the orig.tar.gz , shall recreate for
the interested user the corresponding branch in my development.
Bingo. With this addition, every user that want to see where the
integration branch comes from can examine each topic patch or topic
branch. Each of these topic branches can then be compiled and
experimented with. Upstream can incorporate each of these topic
patches, if they wish.
Any end user who wishes to modify Topic branch C can, then,
modify the topic branch, and apply the same delta to the integration
branch, and they have done the same thing that I would do with the
patch. In other words, they have the same work flow, and preferred
means of modification, even if they do not know my SCM.
People who do not care about independent lines of development
can just ignore ./debian/branches, since that directory is never used
in building, and is for human consumption.
The downside, of course, is shipping the same patch twice, once
in the diff.gz, and once in ./debian/branches/*.diff.gz.
Comments welcome.
manoj
--
Laugh while you can, monkey-boy. Dr. Emilio Lizardo
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
* Manoj Srivastava:
Now, a lot of what I need is already present.
1) the orig.tar.gz represents the upstream branch, exactly.
2) the diff.gz + orig.tar.gz represents the integration branch,
exactly.
So the missing thing is the topic branches.
3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
files. Each diff, applied to the orig.tar.gz , shall recreate for
the interested user the corresponding branch in my development.
I like it a lot. It's somewhat debatable how to deal with divergence
between the sume of topic branches and the integration branch/real
source package contents, but that's something the package maintainers
can be tasked with. What's particularly charming about this scheme is
that such discrepancies do not impact repeatable builds.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Raphael Hertzog wrote: Heh, anybody can blindly apply the patches corresponding to the branch and attach to it a sane commit message. If that was the real problem, it would most probably already be done and we wouldn't discuss here. But Guillem wants to review and understand the code. In this process, he will rearrange the changes in smaller logical chunks. If the code had been submitted in that form (easy to review), the branch would most probably already have been merged and we would be done. What about keeping the (bad) real history (so that merging with out-tree branch will still be easy) AND presenting logical chunks easy to review ? I imagine the current situation is something as A0 A1 - ... - A mainline branch \\ B1 B2 Btrigger branch with crap history (and several merges from mainline) Then go to the situation : A0 A1 - ... --- A P1 ... P6 logical chunks easy to review \\ \\ B1 B2 B - M1 - M final commit to push with the property that M1, M and P3 represent exactly the same source tree (but obviously they are not the same commit as they do not have the same history) There will still be some commit with crap log (Bx) in the git repo but, if no one create branches from Bx or M1, one would always be able to follow an easy to understand path from the base to its commit (by looking the changes on the Px path and knowing that the merge M merges two *identical* trees) Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unsupported? (Was: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol)
On Fri, 29 Feb 2008, Paul Wise wrote: unsupported.d.n could be the right place for packages that are not good enough for Debian (yet). Is there any reason why a Debian should spend resources to maintain things that are not good enough for Debian? For the not good enough _yet_ there is experimental. I don't mind if somebody else wants to register to-bad-for-debian.org but I also would love if people would discuss such issues on a mailing list of this domain. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
binary vs real debian packages
I've built a few debian binary style packages [1] but the maintainer of my local repository is asking that I have all the proper debian files, like the .dsc, .orig, .diff, .changes, etc so some how he can sleep better at night or something. He likes dupload for putting packages into the repo and that requires a .changes my contents are not source (configure, make, etc), rather I'm more interested in the preinst/postinst scripts, the Depends part of the control file, a few config files and placing a few scripts on the filesystem that require no compiling. All the howto info that I've found so far is aimed at making proper debian packages from source which means working with dh_make and checkinstall, etc which I don't thnk I need here. At least, I don't think that I need checkinstall as there is no make install command to run. Further, I understand the concept of an upstream provider and understand that I don't have one in this case, unless I sort of fake it somehow. Is that wise or is there a well understood method of having an .orig file and then doing stuff to make your .dsc, .diff and .changes files? What would the contents of an orig file like that look like in my case where it's not a source package? thank you! Will [1] http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/x88.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
William Pitcock [EMAIL PROTECTED] wrote:
But if you are worried about the QA and security team, then why not
create an unsupported repo. It could even be a good solution towards
recruiting new DDs.
Lets call it, say, 'community', 'extras', or 'unsupported'.
One reason why I prefer Debian over Ubuntu is that it does *not*
have that differerence between a supported ('main') and unsupported
('universe') repository. I like Debian *because* there are so many
choices in the main repository and I don't have to worry if a
package is actually well-supported when I install it, and I would be
glad if it would just stay like that. If a maintainer really takes
care of a package, I see no reason why it shouldn't be added even
when there are already several others with a similar feature set.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
* Sebastian Krause: I like Debian *because* there are so many choices in the main repository and I don't have to worry if a package is actually well-supported when I install it, Sorry, you are kidding yourself if you actually believe that. Software and packaging quality vary greatly across the archive (but we tend to be pretty good at packaging quality, granted). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary vs real debian packages
* William Francis: I've built a few debian binary style packages [1] but the maintainer of my local repository is asking that I have all the proper debian files, like the .dsc, .orig, .diff, .changes, etc so some how he can sleep better at night or something. He likes dupload for putting packages into the repo and that requires a .changes Depending on your local infrastructure, this might actually be the right thing to do (certainly if you're using the full Debian toolchain, including dak). You really need to discuss that with the person who makes your local policy. my contents are not source (configure, make, etc), rather I'm more interested in the preinst/postinst scripts, the Depends part of the control file, a few config files and placing a few scripts on the filesystem that require no compiling. This is kind of unrelated to the question whether .dsc c files are necessary. Do you want that your local repository takes the .deb files you compiled directly, without getting the source code? This can be done, but there might be good reasons not to do this (building from source on autobuilders gives you repeatable builds, for instance). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Friday 29 February 2008 6:16:59 am Otavio Salvador wrote: Ian Jackson [EMAIL PROTECTED] writes: Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): As soon as you edit commits, they'll get a new id, and thus you'll disrupt merging. As I thought. What I am trying to achieve is to use git in the proper way: that is, in a way which makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. Whatever happened to release early, release often? I prefer to make everything public unless I have a reason not to. It lets anyone interested help out, and it makes less work for me because I don't have to keep track of what should be public and what shouldn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How important is Architecture: any (Was: Downloads things, ...)
On Sat, 1 Mar 2008, Petter Reinholdtsen wrote: I guess you might be right, now. Earlier, we used depends to pull in packages using the meta packages during installation. Now we use tasksel tasks, which are more forgiving about missing packages. We did have a problem with the debian-edu package failing to propagate into testing because it depended on arch-any packages that was missing on some architecture. Now that we are using recommends, and recommends might even be installed by default, I guess the need is not so high. Hmmm, once you say so I remember (non-RC!) bugs for not available Recommended packages. So it will not block anything but I'm not sure about the policy here. If we are just asking for those bug reports (even if non RC) the plan is quite suboptimal. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Friday 29 February 2008 8:29:07 am Otavio Salvador wrote: Colin Watson [EMAIL PROTECTED] writes: On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote: Ian Jackson [EMAIL PROTECTED] writes: What I am trying to achieve is to use git in the proper way: that is, in a way which makes merging work properly. Insisting that I use git in a manner which makes merges break but gives prettier logfiles is absurd. That's why you should avoid using the branch as basis to others until it's clean and also avoid to make it public (without a reason) too. This makes it more difficult to ask for review while the branch is in progress, which is a valuable property. It is ridiculous to artificially avoid making branches public; a branch is a useful means of collaboration and we should take advantage of it as such. I'm not saying that it couldn't be made public for review however I suppose noone will ask for review if it's still at start of development process. The moment you commit a patch on the branch is the moment it potentially is interesting. Here's an example. I'm looking at evaluating Redmine, a web-based project management tool, sorta like *forge but smaller, easier, faster, and better. Redmine's SVN tree has integration with Darcs, Mercurial, etc. -- but not git. So someone made a Git branch of it that has Git support. This support will certainly be integrated into mainline at some point. Meanwhile, even if he is still working to refine it, it's useful to me to see it because I'd want Git integration. I understand the risks of running bleeding-edge code, and in this case maybe it's worth it, and maybe I'm interested in helping to test, too. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 29/02/08 at 19:55 +, Steve McIntyre wrote: Lucas wrote: On 28/02/08 at 01:09 -0800, Steve Langasek wrote: Yes, subjective to the point of absurdity. If failure is defined in terms of *your* expectations, I don't see how we can even have a meaningful dialogue about it. Note that my main point in the thread is we should use GSOC to get fresh blood in Debian, not to fund existing contributors. The point about Debian GSOC projects have been unsuccessful in the past is totally secondary. I am under the impression that results from last years' GSOC projects weren't up to par with what could have reasonably been expected from them, based on the skills of the students and the time they were supposed to spend on the projects. Maybe I'm wrong, but it will be difficult for you to convince me of that, since we lack data :-) But that's not going to stop you making accusations of previous GSoC students and mentors misleading Google about how time was spent, though. That's *nice* to see. I think something. You think something else. There's no data to back either claim, so we just have to live with it. Note that the whole did last year projects were successful? issue is secondary. Even if all of last years projects produced fabulous results that totally changed the way Debian is developed, I'm still not sure if we should use GSOC to pay current Debian contributors, instead of using it to bring in new contributors. Also, my goal is not to do a witch hunt about last years' projects. Frankly, I don't care. My goal is to see if we can improve things this year (if there's something to improve). If your goal was not to have a witch hunt, then being a *lot* less aggressive and accusatory in your mails here would help. snip I'm not saying that students that were DD did nothing of their time during GSoc, but most of them produced results that were a bit disappointing given what people could have expected from them, mainly because they used their GSOC time to work on other Debian tasks. Do you have any proof at all for that accusation? If so, please share it. Otherwise, I think that people deserve apologies from you right now. Do you have any proof that GSOC students worked 35-40 hours a week on their GSOC projects? You probably don't. So again, no real data to back either claim. We have different opinions, and have to live with it. Also, I absolutely don't want to start looking in detail at the code produced by last years' projects, and evaluate how much development time was spent on them using the COCOMO model or something else, because it's only marginally relevant to my point (see above). Frankly, if I were in the position of a GSOC student, I would probably find it very hard to work 35-40 hours per week on my project, while I could squash some items off my TODO list. Maybe the whole problem is that I'm less disciplined than our students ;) snip In past years, the GSoC mentors and admins have ranked student applications based on a few criteria: * How interesting the project is for Debian (and how well it fits with us and our needs) * How good we reckon the student is: motivation, skills, enthusiasm, dedication * Whether or not we have a suitable mentor The ideal student applying will take inspiration from the project ideas we've posted, but will take the extra time to turn those suggestions into their own proposal. Background research and a genuine understanding of the problem are good indicators here. In 2006, only 6 of our allotted 10 projects completed successfully. The Google folks informally told us that that was not good enough - we were well below the average of the programme as a whole. We were allowed back in for 2007, but were only awarded funding for 9 projects of the 20 or so that we asked for. Given that, there was a lot of debate about exactly which projects we should choose. I'm happy that we picked a very good set. There was scope to have made different selections here and there, but the 9 that we chose all succeeded: they all met their goals. I'm not greatly convinced by your arguments that DDs and DMs should automatically be barred from applying for GSoC. In my opinion, they are just as welcome as anybody else. Each application should be evaluated fairly on its own merits. OK, thank you for this clarification. To let everybody benefit from it, could you please mention in your next d-d-a mail about GSOC that everybody is welcomed as students, not just people not involved in Debian already? I know at least 2 people that could have applied as students last year, but didn't because they thought that GSOC wasn't for them since they were already involved in Free Software development. Also note that in my initial mail in that thread, I wrote: However, I'm not sure that many DDs agree with this, so maybe we should just aim for *clarification*. So any of the three following solutions would work
Re: binary vs real debian packages
On Fri, Feb 29, 2008 at 3:05 PM, William Francis [EMAIL PROTECTED] wrote: ... Further, I understand the concept of an upstream provider and understand that I don't have one in this case, unless I sort of fake it somehow. Is that wise or is there a well understood method of having an .orig file and then doing stuff to make your .dsc, .diff and .changes files? What would the contents of an orig file like that look like in my case where it's not a source package? Hi William, A quick answer to one of your questions... The orig file would contain all the files not in the debian/ directory, and the diff file would contain all the files in the debian/ directory. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 2/29/08, Lucas Nussbaum [EMAIL PROTECTED] wrote: Do you have any proof that GSOC students worked 35-40 hours a week on their GSOC projects? You probably don't. So again, no real data to back either claim. We have different opinions, and have to live with it. I don't think there's anything in the GSoC that requires 35-40 hours per week. From some of the postings on the students list last year it seems like 20 hours per week is more common. I think Google leaves this up to the mentoring organization and students to work out for themselves, so if we require 35-40 hours per week, we should obtain assurances from the students during the application process that they have that time to commit. Frankly, if I were in the position of a GSOC student, I would probably find it very hard to work 35-40 hours per week on my project, while I could squash some items off my TODO list. Maybe the whole problem is that I'm less disciplined than our students ;) I was a GSoC student for Debian last year. I estimate I put in close to 35 hours per week, but it may have been closer to 30. This year I don't plan on applying as I'm finishing my thesis, though by your suggestion I would not be accepted anyway as I am at the DAM stage of NM. I also maintain several packages, and was in the NM queue when I applied to GSoC last year. I consider packaging to be a different style of contribution than my GSoC project, as all my packages were just packaging, while my project is my own code (and now a 'native' package). I certainly did work on my other packages during the summer, but just like this work doesn't interfere with school or full-time jobs, it didn't interfere with my GSoC project. That's just me though, and I can certainly see how a student who's also a Debian contributor could be sidetracked by other things. I think it's up to the mentor and others (maybe admins) to make sure the student does not get sidetracked, and to end the project if this happens all the time. However, I don't see the need to ban DDs from the GSoC, as my previous packaging and Debian experience was essential to completing my project. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary vs real debian packages
Shaun Jackman [EMAIL PROTECTED] writes: The orig file would contain all the files not in the debian/ directory, and the diff file would contain all the files in the debian/ directory. More accurately, the 'foo-1.2.3.orig.tar.gz' file would contain the upstream from the perspective of Debian source; that is, the working tree of all files that someone would want if they were taking the software and uninterested in making a Debian package. The 'foo_1.2.3-1.diff.gz' would contain whatever changes are necessary to turn that working tree into something buildable to a Debian binary package. The 'foo_1.2.3-1.dsc' would contain necessary metadata about the combination of 'foo-1.2.3.tar.gz' and 'foo_1.2.3-1.diff.gz'. To answer the OP's for some reason implied question: the combination of these three files is a Debian source package. -- \“To punish me for my contempt of authority, Fate has made me | `\an authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Buildd backlog and testing transition.
Le Fri, Feb 29, 2008 at 10:40:57AM +0100, Marc 'HE' Brockschmidt a écrit : Due to kernel problems, the mips* buildds haven't been very reliable in the past few weeks, creating a lng backlog of packages that need to be built. As there seems to be a workaround for the kernel bug, this should start getting better from the weekend on. As a maintainer: Just wait. Dear Marc, it is good news to read that there is a solution being found. However, I am a bit confused because previous messages were suggesting that the problem was disk speed, not downtime. In the meantime, could the release team do us the favor of letting the packages migrate? I just got a message from a user who wants to use one of the blocked packages (emboss), and I am just so ashamed to answer him that he has to use unstable just because it is not built on a platform where nobody is using it. Please. Our work is left aside for no benefit, and if I understand correctly, transiently allowing the migration is just a matter of changing a configuration file two times. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
