put your business on Page #1 of Google Today.
{Business Owners}}}
Let us help you grow your monthly revenue by advertising your company on Google!
Front page placement on Google for:
Sponsored Results (SEM)
Local Business listings (Google Maps)
Before you sign up with a telemarketer with no experience other than sales,
contact us to see how it's
really supposed to be done.
References available around the country in all types of industries!
***
Reply with your NAME and PHONE
NUMBER..
***
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1pkbw4-000ibs...@mail-relay2.dca2.superb.net
Re: A request for those attending key signing parties
On Mon, January 31, 2011 21:18, Martin Zobel-Helas wrote: > a more theoretical question quite related to this: > > If one plans to have the key replaced in the keyring, and we have a > fellow DD in the keyring who's only trust path to other Debian > Developers goes via that key (this might become a real scenario when we > do a bigger round of key replacements) will that key replacement really > happen? Thus CCing keyring maintainers. (I'm not a keyring maintainer.) Currently connectedness has only been used to decide on entry into the keyring. In a similar scenario, if you are signed by just one DD and that DD retires from Debian, you are not removed from the keyring, even though you're no longer connected to other DD's by trust paths. And that is not a problem, because the process is used to establish identity. Your identity has been established upon entry, and this fact is not lost when connectedness of your key is reduced. Thus it's not essential to keep the keys internally connected. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/906938246402b2893e33b381b2fe3747.squir...@wm.kinkhorst.nl
Re: Upstream "stable" branches and Debian freeze
On Mon, January 31, 2011 18:09, Christian PERRIER wrote: > However, upstream's policy in their "stable" branches is alway to only > fix "important" bugs (they don't call them this way...but the > definition is fairly close to Debian's). So, *in the case of samba*, I > can guarantee that the user's (indeed sysadmin's) experience is much > improved if (s)he can follow the upstream minor releases. In the past such things have not been allowed with the argumentation that even though stable may contain bugs, users rely on the behaviour that stable has. They may know about a bug but may have worked around it (and the update may break the workaround) or they do not know about a bug but a fix for it may break a previously functional system. And of course as we all know: bugfixes are not zero-risk and do have chances on new bugs being introduced. Being completely bug-free would be nice, but is probably unachievable. I think there's something to say for the predictability of a release: it may not be perfect, but once installed and tested it will keep working. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edb1dc090de6330490ab7f897785b9f.squir...@wm.kinkhorst.nl
Re: CPE lists was Re: Equivalent packages between Linux distributions
[Silvio Cesare] > I created an automatically generated CPE list for Fedora13 > packages. It only has 300 or so packages in it, but this will > improve as say Debian increase the list of packages they track (they > only track 1100 or so currently). > > https://github.com/silviocesare/Equivalent-Packages/blob/master/CPE/Fedora13.CPE.generated Very interesting. I created the CPE entries for Debian manually, by comparing the set of affected packages reported in the CVE database for Debian and NVD. Perhaps something similar could be done for Fedora, assuming the project track CVEs in a structured way? Note that there are several duplicate CPE entries used by NVD. A list of the ones I have identified so far is in data/CPE/aliases. Note that there is a bug in your list. xen is claimed to be grub-legacy. Perhaps check your code? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fllj202i1e@login2.uio.no
Re: Upstream "stable" branches and Debian freeze
On Tue, 01 Feb 2011, Thijs Kinkhorst wrote: > On Mon, January 31, 2011 18:09, Christian PERRIER wrote: > > However, upstream's policy in their "stable" branches is alway to only > > fix "important" bugs (they don't call them this way...but the > > definition is fairly close to Debian's). So, *in the case of samba*, I > > can guarantee that the user's (indeed sysadmin's) experience is much > > improved if (s)he can follow the upstream minor releases. > > In the past such things have not been allowed with the argumentation that > even though stable may contain bugs, users rely on the behaviour that > stable has. They may know about a bug but may have worked around it (and > the update may break the workaround) or they do not know about a bug but a > fix for it may break a previously functional system. And of course as we > all know: bugfixes are not zero-risk and do have chances on new bugs being > introduced. It is a good thing that we are actually able to learn, and move forward then, isn't it? Some upstreams do so much regression testing and are so strict, that you'd actually be doing a disservice to your users if you don't track their stable branch during Debian stable lifetime. > Being completely bug-free would be nice, but is probably unachievable. I > think there's something to say for the predictability of a release: it may You can just unplug it from the net and never update, if you want that (and if you're going to do that, be smart and use read-only media for the invariant parts of the system already): We've had several regressions due to security fixes. While those are not frequent, they're certainly not rare enough that you can ignore the fact. We seem to have reached a good equilibrium of stability versus bug-fixing on most packages. The current de-facto system works, let's not mess with that. -- "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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201114155.gb29...@khazad-dum.debian.net
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
On Tue, Feb 01, 2011, Wookey wrote: > But if something is looking for arch-independent stuff in /lib then in > general that's wrong, and I'm not aware of any examples of > correctly-packaged packages that need this. Any arch-independent files > will be supplied by an arch all package that the build should depend > on if needed. I might be getting your point wrong, but I certainly see a lot of files in /lib itself which are arch-independent data used for early boot (before /usr is available); PNG files and text files which would be identical on all architectures. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201115048.ga21...@bee.dooz.org
Re: Upstream "stable" branches and Debian freeze
Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.
Basically this argument is "the update may break things".
That's true, but the right questions are: how likely is that; how bad
are the bugs that would be fixed by the update; and so on.
> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may
> not be perfect, but once installed and tested it will keep working.
This argument seems very absolutist and would seem to suggest we
should never do any stable release updates at all. But a user who
wants that level of stability can simply not take the stable release
updates, and only apply the security updates.
I think there is room for us relaxing our policy for stable updates.
Where upstream have a good track record of not breaking their own
stable branch, I think providing those updates to our users is
probably sensible.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19784.1680.379747.405...@chiark.greenend.org.uk
Re: Upstream "stable" branches and Debian freeze
On 2011-02-01, Ian Jackson wrote: > This argument seems very absolutist and would seem to suggest we > should never do any stable release updates at all. But a user who > wants that level of stability can simply not take the stable release > updates, and only apply the security updates. That's not easily possible as stable as found on the mirrors is overriden by point releases.[1] So you'd need to mirror stable r0. > I think there is room for us relaxing our policy for stable updates. > Where upstream have a good track record of not breaking their own > stable branch, I think providing those updates to our users is > probably sensible. First off they have to establish that track record with us, though. (See also [2]. There will be a few updates to leaf packages in stable. However updates to stable server software will be considered carefully, and it depends on how we're convinced of the QA of maintainers and the quality of upstream releases. PostgreSQL did that[3]. For others we'll act on a case-by-case basis.) Kind regards Philipp Kern [1] Ubuntu does it a tad differently. On normal releases their release suite isn't updated. Instead updates are just pushed through the -updates suite. So here you're free to ignore those. LTS do point releases like we do, though. [2] http://lists.debian.org/debian-volatile-announce/2011/msg0.html [3] And they better don't screw up... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnikg9su.sv7.tr...@kelgar.0x539.de
Any Debian Developers traveling to Almaty? (GPG key sign needed)
Hello, Are there any Debian Developers traveling to Almaty for the Asian Winter Games? I need a GPG key sign. Thanks, -- Timur -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ii9976$gef$1...@dough.gmane.org
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
On Tue, 1 Feb 2011 12:50:48 +0100 Loïc Minier wrote: > On Tue, Feb 01, 2011, Wookey wrote: > > But if something is looking for arch-independent stuff in /lib then in > > general that's wrong, and I'm not aware of any examples of > > correctly-packaged packages that need this. Any arch-independent files > > will be supplied by an arch all package that the build should depend > > on if needed. > > I might be getting your point wrong, but I certainly see a lot of files > in /lib itself which are arch-independent data used for early boot > (before /usr is available); PNG files and text files which would be > identical on all architectures. /lib vs /usr/lib is a different argument. I'm working on the basis that Wookey was meaning /usr/lib/ compared to /usr/share. The point about dpkg-cross is that it doesn't blindly take everything from /usr/lib and propagate that into /usr/$triplet/lib, it picks out stuff that it knows is useful to a cross package. Symlinks are included because there's no need to copy libfoo.so.0.0.1 as libfoo.so.0 etc. There's a complex list of regular expressions, allowing header files, static linking files, object files, .la files, anything in /usr/include/ and stuff in /usr/lib/pkg-config/ and stuff already under /usr//lib/. This list has aggregated over time. As multiarch is as far away as ever, I will discuss pruning that list significantly once Squeeze is released, leading to a dpkg-cross 3.0.0. The final list will only include stuff which dpkg-cross can reliably identify *and* which is absolutely essential to cross-builds. /usr/share won't be included, except for pkg-config files. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpnLLwRftyDC.pgp Description: PGP signature
Re: Upstream "stable" branches and Debian freeze
Hi, Ian:
On Tuesday 01 February 2011 14:11:44 Ian Jackson wrote:
> Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> > In the past such things have not been allowed with the argumentation that
> > even though stable may contain bugs, users rely on the behaviour that
> > stable has. They may know about a bug but may have worked around it (and
> > the update may break the workaround) or they do not know about a bug but
> > a fix for it may break a previously functional system. And of course as
> > we all know: bugfixes are not zero-risk and do have chances on new bugs
> > being introduced.
>
> Basically this argument is "the update may break things".
[...]
> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.
I don't think "relax" is the word but "reinterpret".
Why is the policy exactly the way it is? It's obvious that changes are
allowed as security and point releases show. The "why" is obvious too:
because security and/or severe malfunctions overweight the risk of breaking
things *and* Debian release/security team try to minimize that risk by
patching the bare minimum to achieve the intended result.
That said, I find that to be the proper way for a maintenance policy and an
interesting one to push forward to upstream maintainers: it's not Debian,
it's proper engineering to strictly segregate bug fixing from new
functionality; it's proper engineering comitting for long term maintenance
for selected versions of your software and it's proper engineering taking
responsibility for the software one publishes and the bugs that come along
with it.
So, may I propose (if not already done) a document that outlines with enough
detail what Debian maintenance policy is and why from an upstream point of
view, and then allow for within Stable upgrades for software that has
demonstrated to pursue the same standards as Debian? Kindof a "quality seal"
that will allow to push minor versions: it would mean "more with less" since
Debian maintainers wouldn't need to maintain their own patch sets and they
would know in advance what the "proper" version to pack for Stable is (the
one that upstream publishes for long term maintenance within the time-frame
for the new Stable version). For those upstreamers interested in doing the
things the proper way, they could find Debian people to be knowledgeable and
helpful about it (since they've been doing it for years and it's in their own
interest).
Cheers.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201102011709.40161.jesus.nava...@undominio.net
Bug#611738: ITP: pascal-synapse -- syncronous TCP/IP library in Pascal
Package: wnpp Severity: wishlist Owner: Marcos Marado * Package name: pascal-synapse Version : 39+svn135 Upstream Author : * URL : http://www.ararat.cz/synapse/ * License : BSD variant Programming Lang: Pascal Description : syncronous TCP/IP library in Pascal pascal-synapse is a syncronous TCP/IP library in Pascal that also has limited non-blocking mode. Full license: Copyright (c)1999-2002, Lukas Gebauer All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Lukas Gebauer nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- System Information: Debian Release: 5.0.8 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201155728.5762.14923.reportbug@readnew
Re: Bug#611641: ITP: fadecut -- Radio livestream to ogg/mp3 tool
Le lundi 31 janvier 2011, Marco Balmer a écrit : > Description : Radio livestream to ogg/mp3 tool > > This script handle mp3 files (-ripped by streamripper), fade in and > out. It set stream tags: artist, title and your own decided genre. If > you have songs you do not like, move the ripped file to dontlike/ > folder, so fadecut will no longer convert this song, if it was read on > the livestream. All processed files of fadecut are in new/ folder. > The original files from streamripper are in the orig/ folder after > processing. Maybe it is just because I do not understand English well enough, but I really cannot understand this description. Maybe it should be rewritten in a clearer way. What does “to handle files” mean, is that “recording” (e.g. ripping from a radio stream), “playing” (e.g. streaming from files), “organizing” (e.g. renaming) or “transforming” (e.g. adjusting volume or metadata)? Is it a script to record radio streams, cutting files at fade effects? Or a script to produce a stream with fade effects from separate files? -- ,--. : /` ) Tanguy Ortolo | `-'Debian Maintainer \_ signature.asc Description: Digital signature
Re: Upstream "stable" branches and Debian freeze
2011/2/1 Jesús M. Navarro : > So, may I propose (if not already done) a document that outlines with enough > detail what Debian maintenance policy is and why from an upstream point of > view, and then allow for within Stable upgrades for software that has > demonstrated to pursue the same standards as Debian? Kindof a "quality seal" > that will allow to push minor versions: it would mean "more with less" since > Debian maintainers wouldn't need to maintain their own patch sets and they > would know in advance what the "proper" version to pack for Stable is (the > one that upstream publishes for long term maintenance within the time-frame > for the new Stable version). For those upstreamers interested in doing the > things the proper way, they could find Debian people to be knowledgeable and > helpful about it (since they've been doing it for years and it's in their own > interest). It depends on the kind of package and computer whether it makes sense. For production servers, stability is (way) more important. For desktop users and packages like browsers, which might be fast moving, new features might be more important. Upstream for Firefox and Chrome are not going to provide stable branches that are maintained for two+ years. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinOqYUc=g6gy9ckkjsgfkp6jzs8nxsws0qst...@mail.gmail.com
Re: Upstream "stable" branches and Debian freeze
Hi, Olaf: On Tuesday 01 February 2011 17:18:58 Olaf van der Spek wrote: > 2011/2/1 Jesús M. Navarro : > > So, may I propose (if not already done) a document that outlines with > > enough detail what Debian maintenance policy is and why from an upstream > > point of view, and then allow for within Stable upgrades for software > > that has demonstrated to pursue the same standards as Debian? Kindof a > > "quality seal" that will allow to push minor versions: it would mean > > "more with less" since Debian maintainers wouldn't need to maintain their > > own patch sets and they would know in advance what the "proper" version > > to pack for Stable is (the one that upstream publishes for long term > > maintenance within the time-frame for the new Stable version). For those > > upstreamers interested in doing the things the proper way, they could > > find Debian people to be knowledgeable and helpful about it (since > > they've been doing it for years and it's in their own interest). > > It depends on the kind of package and computer whether it makes sense. > For production servers, stability is (way) more important. > For desktop users and packages like browsers, which might be fast > moving, new features might be more important. It depends more on the use case than in the package. As long as there's no interface with externals/third parties it makes more sense add new functionality only as needed, no matter if it's a kernel or a web browser. > Upstream for Firefox and Chrome are not going to provide stable > branches that are maintained for two+ years. That's up to them and, in fact, it makes no difference: they won't get the "quality seal" and their maintenance procedures within Debian will be just the way they are now so no loss from this side. On the other hand, each and every package that would go under the "quality seal" umbrella would mean an easier day for the package maintainer, a higher quality software for everybody and, on a side note, source of "unintended" benefits for everybody (remember Mark Shuttleworth's interest on sincronizing packages among distributions? It would be a natural outcome if a significant number of upstreamers aligned to the "quality seal" idea: distributions interested on stability would just converge around the long term versions distributed by upstream). Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102011740.20430.jesus.nava...@undominio.net
Re: Bug#611698: nodejs: conflicts with package node needlessly
On Tue, Feb 1, 2011 at 01:43:27 +, brian m. carlson wrote: > Package: nodejs > Version: 0.2.6-1 > Severity: serious > Tags: experimental > > It appears that nodejs in experimental has acquired a Conflicts with > node. According to the changes file for that release: > >* Use upstream binary names for node and node-waf, > conflicts with node package. (Closes: #597571) > > I still don't believe that is allowed by Debian Policy. Correct, that's not an acceptable use of Conflicts. Cheers, Julien signature.asc Description: Digital signature
Re: A request for those attending key signing parties
On Mon, Jan 31, 2011 at 09:18:18PM +0100, Martin Zobel-Helas wrote: > a more theoretical question quite related to this: > > If one plans to have the key replaced in the keyring, and we have a > fellow DD in the keyring who's only trust path to other Debian > Developers goes via that key (this might become a real scenario when we > do a bigger round of key replacements) will that key replacement really > happen? Thus CCing keyring maintainers. I've had a few conversations with developers who are known to be the single path to many DDs about holding off on their key replacements, and been keeping an eye in general on our connectedness over time. In some occasions we have pushed back on developers who want to replace their keys with a minimal number of signatures when their old keys are well integrated. Overall the connectedness seems to have stayed about level; in January 2009 we had 89.6% of the keys is in the reachable subset and 84.0% in the strong subset. By the end of 2010 these numbers had increased to 91.1%/85.2%. Yes, some of that is because we've removed inactive keys, but I think it's an indicator that (so far) the key replacements have not been weakening our web of trust. J. -- Web [ If I hold really still maybe all of this will just go away. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201173635.gc30...@earth.li
Re: A request for those attending key signing parties
Martin Zobel-Helas dijo [Mon, Jan 31, 2011 at 09:18:18PM +0100]: > a more theoretical question quite related to this: > > If one plans to have the key replaced in the keyring, and we have a > fellow DD in the keyring who's only trust path to other Debian > Developers goes via that key (this might become a real scenario when we > do a bigger round of key replacements) will that key replacement really > happen? Thus CCing keyring maintainers. http://lists.debian.org/20110201183448.gf24...@gwolf.org
Bug#611752: ITP: mana -- mana is a 2D MMORPG
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: mana Version : 0.5 * URL : http://www.manasource.org/ * License : GPL, BSD Programming Lang: C++ Description : mana is a 2D MMORPG The Mana client is developed as part of The Mana Project, which aims to build a complete 2D MMORPG platform. This includes a client, server and web component, as well as a library of free content that you can use under the terms of the GPL. . This version of the client can connect to a specific version of the eAthena server known as tmwAthena, a version with adaptations made as part of The Mana World project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201194303.24746.83858.reportbug@localhost
Re: Misc Developer News (#24)
Paul Wise writes: > squeeze release live microblogging > -- > > The Debian squeeze release will be live microblogged[4] to Debian's > identica account[5]. Several steps of the release process are quite long > and boring, so these quiet periods will be filled with funny or otherwise > interesting facts about Debian. If you would like to help out by > supplying some fun or interesting facts, please reply to the thread[6]. > > -- Paul Wise > > [4] http://lists.debian.org/20110130130240.gc30...@melusine.alphascorpii.net > [5] http://identi.ca/debian > [6] http://lists.debian.org/debian-publicity/2011/01/threads.html#00055 Is there a ToDo list of things that need to happen during the release process, idealy with ETAs? Something that gives an overview without the distractions of funny and otherwise interesting facts about Debian? Something simple like - Do final dinstall run (done) - update mirror for cd/dvd creation (done) - create cd/dvd images [amd64, i386, armel done ...] ETA: 5h - mirror images ETA: Tueday - send release announcement ETA: Wednesday or so. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vxzsdkp.fsf@frosties.localnet
Bug#611764: ITP: activiz.net -- Tool for generating C# wrappers around VTK
Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: activiz.net Version : 5.6.1 Upstream Author : kitware * URL : http://www.kitware.com/products/avdownload.php * License : BSD Programming Lang: C++ Description : Tool for generating C# wrappers around VTK ActiViz provides a powerful interface to the Visualization Toolkit (VTK), an object-oriented software system encompassing thousands of algorithms that transform data into interactive 3D environments. ActiViz, which generates C# wrappers around VTK, enables developers to combine the power of VTK with the many .NET framework objects for web and database access. Available as source code or as a pre-built WinForms Control, ActiViz .NET includes examples, online documentation, and supports IntelliSense in the .NET Framework -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201211248.695.65487.report...@hpdesk.malat.net
Re: Misc Developer News (#24)
Hi! * Goswin von Brederlow [110201 21:29]: > > squeeze release live microblogging [..] > Is there a ToDo list of things that need to happen during the release > process, idealy with ETAs? Something that gives an overview without the > distractions of funny and otherwise interesting facts about Debian? Yes, there are checklists. But TTBOMK there are not ETAs. Best Regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201213448.gn30...@melusine.alphascorpii.net
Re: Misc Developer News (#24)
On Tue, Feb 01, 2011 at 10:34:48PM +0100, Alexander Reichle-Schmehl wrote: > * Goswin von Brederlow [110201 21:29]: > > > squeeze release live microblogging > [..] > > Is there a ToDo list of things that need to happen during the release > > process, idealy with ETAs? Something that gives an overview without the > > distractions of funny and otherwise interesting facts about Debian? > > Yes, there are checklists. But TTBOMK there are not ETAs. http://wiki.debian.org/HowToRelease (which has not been edited since 2009) -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110201225905.gk2...@glenfiddich.ikibiki.org
Re: package testing, autopkgtest, and all that
Hi Ian, First a brief question: > The source package provides a test metadata file > debian/tests/control. This is a file containing zero or more > RFC822-style stanzas, along these lines: Do you still have somewhere that awk package demo package which had debian/tests/ ? Currently our archive does not carry any package having debian/tests/ (unfortunately). Just a brief summary for such a ignorant DDs as myself who did not know about those additional projects in Ubuntuland before they got mentioned in this thread: Ubuntu "Testing Automation" project has been going on for a while: https://wiki.ubuntu.com/Testing/Automation , with active (i.e. actually being developed/used) components such as - checkbox (package in Ubuntu): user-land tool (packaged and available in Ubuntu) to provide primarily hardware testing, with some basic software tests available; reporting back to launchpad.net with gathered information on hardware. - mago (package in Ubuntu): built on top of LDTP (package in Debian), provides testing of GNOME GUI. - qa-regression-testing: collection of unit and regression tests for various components (from kernel to xine and apache) of the systems. Is not designed for distribution to the users (yet?) All of the above approaches seems to separate testing "materials" from the actual packages. Both mago and checkbox come with user interfaces, thus enabling users to test/validate their own systems without requiring setting up any virtual environment. And they ship their tests along (there seems to be some discovery mechanisms but I haven't checked in detail yet). On the other hand, Ian's autopkgtest aims to provide a unified testing framework built around packages, so that it becomes possible for us, maintainers, to equip packages with necessary tests batteries; which could be reused by others (e.g. QA teams). So it seems to go closer toward the goals of qa-regression-testing project above, but tries to scale via making tests materials provided by the corresponding maintainers in the source packages. (As is now at least) it requires relatively complex setup of the system to start crunching the tests batteries, thus not user-oriented. For our purposes of testing scientific applications, as it was previously mentioned and exposed in the "case studies" on http://neuro.debian.net/proj_debtest.html page, we want the cocktail of all the above solutions ;-) with less accent on GUI testing but with convenient user-interface not requiring root access (besides possibly installation of the tests batteries). And it seems that the autopkgtest basis, maybe with some functionality from checkbox and mago (e.g. for collecting relevant software/hardware statistics and running basic system tests) could unroll into the ultimate solution for our goals. Unfortunately the core aspect of the current autopkgtest - relying on tests in source packages -- imho to be not the ideal solution to target both sides of the userbase (i.e. maintainers/QA vs mortals). https://wiki.ubuntu.com/AutomatedTesting associated with autopkgtest addresses the FAQ on why source packages: ,--- | Q. Why put the tests in the source package ? | | A. Other possibilities include a special .deb generated by the source | (which is a bit strange and what happens to this .deb and will make it even | harder to reuse upstream test suites), or putting them in the .deb to be tested | (definitely wrong - most people won't want the tests and they might be very | large) or having them floating about separately somewhere (which prevents us | from sharing and exchanging tests with other parts of the Free Software | community). The source package is always available when development is taking | place. `--- Ian -- could you please unroll your arguments a bit? I still do not see why source packages are beneficial besides build-time testing (which we often do already without any additional framework) In our view ideal solution from the user's (or maintainer/QA) point of view should involve exactly that -- interaction with binary packages since that is what everyone knows how to deal with, e.g.: sudo apt-get install apache2-tests adt-run apache2 or even, having installed X tests batteries adt-run --all # to run all "installed" tests batteries We could also complement it with sudo adt-install --all-relevant which would install test batteries complementing installed software packages, thus providing tailored coverage for a particular user needs. To accomplish above with tests only in source packages, would require apt-src like infrastructure (and do version/dependencies tracking on them), and moreover why should I care to keep sources on my (user's) system at all! What is relevant for testing seems to be: testing materials and already installed applications. And that is what other (checkbox/mago/qa-regression-testing) frameworks rely upon. And sure thing, for maintainers/QA it could get more evolved indeed req
Bug#611776: ITP: ranger -- A vim-inspired filemanager for the console.
Package: wnpp Severity: wishlist Owner: Qijiang Fan * Package name: ranger Version : 1.4.1 Upstream Author : Roman Zimbelmann * URL : http://ranger.nongnu.org * License : GPL Programming Lang: Python Description : A vim-inspired filemanager for the console. Ranger is a free console file manager that gives you greater flexibility and a good overview of your files without having to leave your *nix console. It visualizes the directory tree in two dimensions: the directory hierarchy on one, lists of files on the other, with a preview to the right so you know where you'll be going. The default keys are similar to those of Vim, Emacs and Midnight Commander, though Ranger is easily controllable with just the arrow keys or the mouse. The program is written in Python (2.6 or 3.1) and uses curses for the text- based user interface. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110202033152.3300.80449.reportbug@Miaoxin
Please add my ID for Link Exchage
Hi SEO Please add my ID for Link Exchage *ejaz.webmas...@gmail.com*
Re: package testing, autopkgtest, and all that
On Tue, Feb 01, 2011 at 06:17:45PM -0500, Yaroslav Halchenko wrote:
> Unfortunately the core aspect of the current autopkgtest - relying on
> tests in source packages -- imho to be not the ideal solution to
> target both sides of the userbase (i.e. maintainers/QA vs mortals).
Thanks for this "related work" research Yaroslav, I found it to be very
helpful for this discussion.
> Ian -- could you please unroll your arguments a bit? I still do not
> see why source packages are beneficial besides build-time testing
> (which we often do already without any additional framework)
Not that you are explicitly saying they are not, but let me stress that
support for automated testing shipped in the source package is
useful. That way maintainers can keep them in sync with the package,
pretty much as software developers keep test suites in sync with the
code base, by committing them along side the code itself (and possibly
even doing feature commits that check in both the code and the
corresponding test at the same time).
What you are requesting, if I got it right, is support for having the
*possibility* of shipping tests elsewhere, possibly even not in a
package available in the archive. That can indeed come handy in various
scenarios, such as a separate test team with their own batteries of
tests (e.g. someone mentioned that other distros have distro-wide
regression test suites; such initiative can benefit from the extra
feature you are proposing). I also observe that the dependency
interface in the current spec is already pretty sane to handle that: if
the tests are shipped as part of the source package they can benefit
from the "@" syntax, otherwise they'll need to be explicit.
All that considered, I'd like to know the rationale of this initial
design choice as well. In particular, it would be nice to know if anyone
see disadvantages in having *also* (rather then "instead") support for
running tests which are not part of a source package.
> So, where do we start/continue sharing the thoughts on a tentative
> DEP? ;)
Let's see first if we have all the arguments on the table already,
thanks to this thread. I'm willing to co-drive a DEP to finalize the
spec, although I definitely need helping hands (hint, hint!).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
