Re: DFSG violations in Lenny: Summarizing the choices
Le lundi 10 novembre 2008 à 03:28 +0100, Marco d'Itri a écrit : > Myself, I'd like a Debian fork with RHEL kernels anyway... lol -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505185: ITP: libweakref-perl -- API to the Perl weak references
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: libweakref-perl Version : 0.01 Upstream Author : Tuomas J. Lukka <[EMAIL PROTECTED]> URL : http://search.cpan.org/dist/WeakRef/ License : Same as Perl Programming Lang: Perl, C Description : API to the Perl weak references A patch to Perl 5.005_55 by the author implements a core API for weak references. This module is a Perl-level interface to that API, allowing weak references to be created in Perl. . A weak reference is just like an ordinary Perl reference except that it isn't included in the reference count of the thing referred to. This means that once all references to a particular piece of data are weak, the piece of data is freed and all the weak references are set to undef. This is particularly useful for implementing circular data structures without memory leaks or caches of objects. This is a dependancy of libace-perl (ITP #468760), which is a dependancy of BioPerl. Is the Debian Perl group interested in hosting this package? Otherwise we will host it in Debian Med. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Daniel Baumann wrote: so then call them 'Debian Foo' team, since this is what they are and no different to the various teams we have already (where some of them are not limited being 100% packaging oriented; e.g. kde team that releases livecds). Strangely enough people are so keen on all this naming issues that the technical part in the beginning of the announcement did not deserved any comment so far. This fits perfectly into my observation that the thread about renaming on the CDD list attracted more people than any other technical topic before. Your remark above just ignores that the concept tries to profit from synergies inside these projects which for instance are reflected in these tasks or bugs pages, a common technique to build metapackages etc. The interesting thing in all the business I'm doing since several years is that all the technical infrastructure which is used in Debian Med and Debian Edu is instantly available for instance in Debian Science or potential other projects. The main idea behind this stuff is that we are factorising our tools to work for a specific $WORKFIELD$. This makes a difference to technical projects like debian-live - and strangely enough this concept seems to remain a well hidden secret even if I'm constantly talking about this. everything else is, imho, useless waste of time explaining and defining things in terminology that does not matter for 99% of the people here The push in the work of the Debian Science team (which formerly just was a simple mailing list) might be a clear sign that finding a common structure based on common technologies is a successful method to push a project. (ymmv, no offence intended et al. i'm glad and thankful for what you do in and arround debian, but the naming game isn't one of them). I did not felt offended and I accept that people do not like the naming game. You can believe me that besides the business on the mailing list a lot of other burden was on my shoulders and that I personally was the one who hated this game even more than anybody else here. If you had faced so many missunderstandings about the things you want to promote just *because* the name implies a different concept you are using for your project you would probably have drawn the same consequence. If we now would be able to continue *working* for the concept and stop spending time criticising the name itself (the time for this is over as I tried to explain) or the renaming process in general which is definitely a waste of time I would be really happy. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#505185: ITP: libweakref-perl -- API to the Perl weak references
Le Mon, Nov 10, 2008 at 02:30:54PM +0100, Dominique Dumont a écrit : > Charles Plessy <[EMAIL PROTECTED]> writes: > > > This is a dependancy of libace-perl (ITP #468760), which is a dependancy of > > BioPerl. > > > > Is the Debian Perl group interested in hosting this package? Otherwise we > > will > > host it in Debian Med. > > WeakRef is obsolete. > > The weaken and isweak functions are now provided by Scalar::Util which > is part of core perl since perl 5.007003. > > Debian Med programmers should change "use WeakRef" to something like > "use Scalar::Util qw/weaken/". Thanks for the hint, I will contact Upstream about this issue. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 2008-11-10 at 13:28 +0100, Andreas Tille wrote: > On Mon, 10 Nov 2008, Neil Williams wrote: > > > I guess what are talking about here is the mirrors. Do all Blends use > > unchanged Debian mirrors? > > Yes. What else would you expect if it says _inside_ Debian? A Debian > Pure Blend has no separate mirror - THIS is the basic idea of the concept. That is where I found "Blends" confusing - it conjures up images of mixing two different things into one. What you are describing is (to me) more filtering or remixing, not blending. Maybe it's my professional bias - I'm used to doing admixtures, blends, compounding and formulation and the terms have quite specific (pharmaceutical) meanings. A + B = C (blending A with B to make a new, bigger, C) (Think blending chocolate into cake mix to get a chocolate cake or blending a strawberry flavour into a cough mixture. What you get has a larger volume/mass.) What Blends is describing is actually something that is not possible with "real-world" blending - substituting a strawberry flavour for a raspberry flavour in an existing product - quite possibly reducing the total volume/mass of the final product. It works because the "product" (Debian) is itself a mixture that has both flavours available and the blending happens *before* the real-world product (the installation) exists: D = (A + B + C) M = (A + C) where D == Debian and M could be Debian Med. Yes, A and C are being blended together but they are already blended together in the bigger D - it's just that D comes with B as the default and C as optional. (i.e. anyone can install normal Debian and then install the Med packages on top, what Debian Med wants to do is install the Med packages by default, skipping the bits that are not necessary.) That's more like deciding whether to make the cake with icing only in the middle instead of jam in the middle and icing on top. Shuffling components around and tweaking to make it fit. What Emdebian Grip does is make a smaller cake, still with the jam and icing, whilst still allowing you to skip the icing if preferred. (Emdebian Crush makes a very small gluten-free cake without jam or icing - fundamentally changing the nature of the result by modifying the ingredients themselves.) What M is doing is "raising the priority" of C so that it becomes the default install, ahead of B. I can see that being useful in Emdebian too. Blending is a form of adding and mixing. Blends appears to be about subtracting, remixing and customising. In this respect, a Blend that prioritises XFCE ahead of GNOME and/or ext2 ahead of ext3 would be a useful basis for Emdebian Grip. There is still a grey area though - someone could easily run the Emdebian Grip scripts on a Debian Med install after downloading from the normal Debian mirrors, in order to reduce total installation size without the benefits of reducing the cache data sizes. Indeed, the scripts could run as a hook within the download process. Thankfully, I don't think many people will want to do that (at least not for the majority of packages) because it is quite wasteful of bandwidth and CPU resources. The disjuncture here is similar to how colours are blended in printers versus in images. A printer / painting palette is closer to my understanding of blending - you can only add, not subtract, so colours get closer to black the more blending you do. An image palette works the other way, the more colours you blend, the closer you get to white. Blends works on RGB (light), blending works on CMYK (ink). It is this topsy-turvy understanding of "blend" that was confusing me and may well confuse others. > > If so, what are Blends blending? > > All mixtures are inside the Debian package pool. Out of these mixtures > we want to fit the taste of a certain user group. ok > So for you Emdebian was, is and will be a Debian Internal Project which > is listed at the place where it belongs to. This is what I wanted to > say when I asked for having a look at the doc[2] - the name is choosen > for a concept Emdebian does not really fit into. > > To say it once more: I like your Emdebian effort but it is orthogonal > to the user specific field scope. For instance: We might consider > an Emdebian Med for medical stuff using embedded devices (which is in > fact very interesting). I'd never have thought about Emdebian Med - don't know why, but I always had the impression that Debian Med packages were quite large. There is certainly scope for such a variant. > > I'm hoping that Grip will be seen differently - as a normal Debian > > install, just smaller. Whatever changes might be necessary to actually > > deploy Grip, I will be seeking to fold those changes into the relevant > > Debian packages. > > I hope you do not feel discriminated - but it is just not true that > every project inside Debian now has to use the name we have choosen > for a specific internal concept. I'm just trying to get it straight in my head. :-) Several peo
Bug#505182: ITP: libmath-random-perl -- random number generators
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: libmath-random-perl Version : 0.71 Upstream Author : John Venier and Barry W. Brown URL : http://search.cpan.org/dist/Math-Random/ License : same conditions as Perl, plus some public domain, plus some BAD NEWS. Programming Lang: Perl Description : random number generators Math::Random is a Perl port of the C version of randlib, which is a suite of routines for generating random deviates. See "RANDLIB" for more information. . This port supports all of the distributions from which the Fortran and C versions generate deviates. The major functionalities that are excluded are the multiple generators/splitting facility and antithetic random number generation. These facilities, along with some of the distributions which are included, are probably not of interest except to the very sophisticated user. If there is sufficient interest, the excluded facilities will be included in a future release. The code to perform the excluded facilities is available as randlib in Fortran and C source. I am interested in libmath-random-perl because it is a dependancy of the new upstream release of BioPerl. A preliminary package is almost ready. However, quoting from README: THE BAD NEWS. We adapted or modified many routines published in the ACM's Transactions on Mathematical Software. The ACM has copyright on these routines (see the ACM statement on software policy in the POD/man page). Commercial incorporation of these routines into products to be sold requires permission and perhaps payment to the ACM. But if you don't plan to sell them, enjoy. (Note, however, that algorithms per se cannot be copyrighted; see 17 USC 102(b).) libmath-random-perl is therefore non-free. Is the Debian Perl team interested in hosting this package ? If not, we will host it in Debian Med. Have a nice day, -- Charles Plessy Debian Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > it took a little longer than I expected but I finally launched > > http://screenshots.debian.net [...] > Have fun and let me know what you think. Please do not reduce images in size. The screenshots of, for example, dillo and amiwm are horrible. If you have a guideline of having a maximum size of 800x600 pixels, just give an error when someone uploads a screenshot that is larger than that. A link to packages.debian.org for every package would also be nice. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Announcement: Debian Pure Blends news
2008/11/10 Andreas Tille <[EMAIL PROTECTED]>: > On Mon, 10 Nov 2008, Miriam Ruiz wrote: > >> I'm not exactly sure that I like the new name, to be honest. > > Well, the renaming was announced on debian-custom list and all lists > of existing CDDs (also for instance on Debian Junior list[1]). And, > yes, you are not the only one who is not really happy, but this name > has won the poll and I also asked[2] whether "people insist on a > condorset voting". So there was a chance to take some influence for > people who are involved. I know, I've been extremelly busy these last weeks and I couldn't join the discussion. Please don't take my comment as an active opposition to that name, it is not. In fact it doesn't bother me too much how we call them, but it's the concept I'm interested in. All I was saying is that I don't particurally like the game, but if it has been voted and the rest of the people likes it, I can live with it :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Montag, 10. November 2008, Guus Sliepen wrote: > On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > > it took a little longer than I expected but I finally launched > > > > http://screenshots.debian.net > > [...] > > > Have fun and let me know what you think. > > Please do not reduce images in size. The screenshots of, for example, > dillo and amiwm are horrible. If you have a guideline of having a > maximum size of 800x600 pixels, just give an error when someone uploads > a screenshot that is larger than that. In the "guidelines" I suggest not to upload screenshots larger than 800x600 if the uploader doesn't want automatic reduction. Too large images cannot be viewed properly (e.g. I wouldn't be able to enjoy a 1600x1280 image on my screen) by most users. So I thought that 800x600 is a good compromise. > A link to packages.debian.org for every package would also be nice. Okay, will do. And I'll add proper URL routing so that packages.debian.org will be able to access screenshots directly, too. Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: This is a digitally signed message part.
Re: Announcement: Debian Pure Blends news
2008/11/10 Miriam Ruiz <[EMAIL PROTECTED]>: > that I don't particurally like the game, but if it has been voted and s/game/name/ Sorry, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
screenshots.debian.net goes beta
Fellow developers... it took a little longer than I expected but I finally launched http://screenshots.debian.net after two weeks of programming fun. It is an effort to help users get an idea what a certain application does and how it looks like by offering screenshots. It was suggested by Roberto in January 2008 and I re-raised the discussion in July. Please take a look at the site, consider uploading screenshots of your favorite application and give some feedback. The approach is rather open. Everybody can upload screenshots. But they won't be visible until a member of the admin team approves them (to make sure we don't catch spam and porn). As soon as the application is stable I'd like to get 1-2 people on the admin team to watch the moderation queue. (If you see your own screenshots it's because I identify browsers by a cookie I send so that mistakenly uploaded images can be removed by the uploader.) Have fun and let me know what you think. Cheers Christoph P.S.: Bear with me if the service is down for a minute or two. I'm deploying a few minor updated to fix bugs I get reported. -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: This is a digitally signed message part.
Re: screenshots.debian.net goes beta
On Mon, 2008-11-10 at 15:29 +0100, Christoph Haas wrote: > On Montag, 10. November 2008, Guus Sliepen wrote: > > On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > > > it took a little longer than I expected but I finally launched > > > > > > http://screenshots.debian.net > > > > [...] > > > > > Have fun and let me know what you think. > > > > Please do not reduce images in size. The screenshots of, for example, > > dillo and amiwm are horrible. If you have a guideline of having a > > maximum size of 800x600 pixels, just give an error when someone uploads > > a screenshot that is larger than that. > > In the "guidelines" I suggest not to upload screenshots larger than 800x600 > if the uploader doesn't want automatic reduction. Too large images cannot > be viewed properly (e.g. I wouldn't be able to enjoy a 1600x1280 image on > my screen) by most users. So I thought that 800x600 is a good compromise. 800x600 would be a good compromise provided that the original is available. William signature.asc Description: This is a digitally signed message part
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > it took a little longer than I expected but I finally launched > http://screenshots.debian.net First of all thanks a lot for the effort, the result is already really cool and in perspective it is amazingly useful! > Have fun and let me know what you think. On the guidelines: - You state that screenshot will be released under the same term of the screenshot-ed package, why so? It seems to me rather arbitrary and makes impossible to bundle all screenshot together on a media and distribute them under a consistent license. Suggestion: just name a license and stick to it. Then an usability comment: the only link under each screenshot is "request removal". IMO it is too "tempting", because it is the large and because it is the only link. Suggestion: replace it with the classical "X" icon with a tooltip, and make it "less important" by adding some other link, e.g., the suggested link to packages.debian.org. Out of curiosity, do you already have an API for accessing screenshot data externally? I guess the packages.d.o are interested in that, and for sure I'm interested in that to add a TODO item in the PTS for missing screenshots (probably just for some class of packages, we'll see). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 12:11 AM, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > - You state that screenshot will be released under the same term of > the screenshot-ed package, why so? It seems to me rather arbitrary > and makes impossible to bundle all screenshot together on a media > and distribute them under a consistent license. > > Suggestion: just name a license and stick to it. screenshots are derivative works (according to SPI legal counsel): http://lists.debian.org/debian-legal/2008/08/msg00016.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:16:06PM +0100, Guus Sliepen wrote: > Please do not reduce images in size. The screenshots of, for example, dillo > and > amiwm are horrible. If you have a guideline of having a maximum size of > 800x600 pixels, just give an error when someone uploads a screenshot that is > larger than that. Why impose such a barrier to entry for contributers? I think resizing images is a fantastic thing to provide. I do think the page lengths, or result count per page, could be increased. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
2008/11/10 Andreas Tille <[EMAIL PROTECTED]>: > We realised that the old name Custom Debian Distributions just sended > the wrong message to outsiders: The conclusion that CDDs are something > else than Debian was to "obvious" if people did not read the relevant > documentation. So we finally found a raw consensus for a new name: > >Debian Pure Blends I'm not exactly sure that I like the new name, to be honest. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 2008-11-10 at 12:32 +0100, Andreas Tille wrote: > On Mon, 10 Nov 2008, Neil Williams wrote: > > > I was never particularly clear on why "Custom" was a bad name to use. > > Actually "distribution" was the worst part of the old name. ok > Before we have another round of discussing names: Could everybody > who is really interested in the projects please have a look into > the paper[1] and see if they identify with the things described there. ack > IMHO Emdebian does not really fit into this. That's why I mentioned the flavours - traditional Emdebian is different, but that is what will be the Crush flavour. Grip will be straight Debian, just with smaller packages. > To be a Debian Pure Blend > everything has to be inside (pure) Debian. For Emdebian Grip, this does apply (albeit that the scripts themselves are in development and waiting for the Lenny release before being uploaded). > We just try to make sure > that people understand this fact. If you would like to call Emdebian > a "Custom Debian Distribution" this is perfectly fine now because this > term is now not covered any more by a concept we are using which Emdebian > does not really fit into. You see, that's my problem - Emdebian Crush is very customised. Crush will take out big chunks of Debian (like perl :-)) and Crush involves cross-building (or rebuilding) all relevant packages. Emdebian Grip is quite different - Crush will be based on Grip (in that the files taken out by Grip will also be taken out in Crush) but Grip *only* removes files from packages, it doesn't change the functionality or behaviour of the packages themselves. The files concerned are /usr/share/doc/package/*, /usr/share/man/*, /usr/share/info/* etc. and Grip will make use of TDebs, DEB_VENDOR and Dpkg::Class as that support becomes available. Grip also sets Recommends to off. Packages can be "gripped" after download from normal mirrors but that loses the benefit of reducing the size of the package cache data and reduced sizes of the downloaded packages themselves, so Grip will support a customised mirror with fewer, smaller, packages. I guess what are talking about here is the mirrors. Do all Blends use unchanged Debian mirrors? If so, what are Blends blending? Emdebian Grip will use the same kind of support as Blends - a customised installer that uses the Grip mirror, customised package selection (XFCE as the default "desktop" install), customised install setups (ext2 preferred over ext3 as many Grip devices will be solid state storage). As such, Emdebian Grip could be the ideal choice for putting Debian onto a netbook like the Aspire1 and Eee. Once things start to work, I'll be using my Aspire1 to test Emdebian Grip and then see about working with the Eee team to iron out the details. The idea will be to get a Debian install onto a netbook without having to change the defaults or fiddle around with post-install configuration - i.e. a USB/net installer that does the right thing, out of the box. Emdebian Grip *is* intended to be Debian, just 20% smaller (maybe 30% if I can get it that small) and with support for the kind of tweaks that small devices might need in order to run Debian (like ext2 and XFCE instead of ext3 and GNOME/KDE). The intention is to have Grip generation entirely automated, even working as a repository update hook. Emdebian Crush is a derivative, yes. When released, it will be described in the form: Emdebian 1.0 (based on Debian 5.0 "Lenny") etc. I'm hoping that Grip will be seen differently - as a normal Debian install, just smaller. Whatever changes might be necessary to actually deploy Grip, I will be seeking to fold those changes into the relevant Debian packages. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Announcement: Debian Pure Blends news
On Mon, Nov 10, 2008 at 10:26:46AM +0100, Andreas Tille wrote: > Renaming Custom Debian Distributions to Debian Pure Blend > - - > [3] http://cdd.alioth.debian.org/blends ^^^ .oO( Have you thought about renaming the Alioth project? CNAMEs do matter. ) ... thanks for the initiative! -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Announcement: Debian Pure Blends news
On Mon, 2008-11-10 at 11:53 +0100, Miriam Ruiz wrote: > 2008/11/10 Andreas Tille <[EMAIL PROTECTED]>: > > > We realised that the old name Custom Debian Distributions just sended > > the wrong message to outsiders: The conclusion that CDDs are something > > else than Debian was to "obvious" if people did not read the relevant > > documentation. So we finally found a raw consensus for a new name: > > > >Debian Pure Blends > > I'm not exactly sure that I like the new name, to be honest. I'm confused by the new name - what are we blending and why confuse "Pure" and "Blend" in the same name? Emdebian is a customised Debian too - we will have two flavours soon, a functionally-identical but smaller Debian based on Squeeze (Emdebian Grip) and a maximally reduced flavour with functional changes called Emdebian Crush. http://www.emdebian.org/emdebian/flavours.html I was never particularly clear on why "Custom" was a bad name to use. There is Debian and there are variations of Debian that are customised for particular roles. Within those variations, flavours and sub-projects also exist. I can't see the reasoning for "Pure" "Blends" - doesn't make any sense to me. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: DFSG violations in Lenny: Summarizing the choices
On Mon, Nov 10, 2008 at 12:56:26PM +1030, Karl Goetz wrote: > Why are they making hardware that can transmit on *any* frequency? Why > are they not making hardware that transmits in the 2.4GHz ISM band > perhaps with firmware to 'fine tune' it? Seems strange to pour lots of > money into making an all-band radio then locking it to a 500MHz band. As you seem to know about the physics, please provide the specs for a proper hardware-based bandpass-filter for the 2.4GHz ISM band, so you can't leaf this band without hardware modification. Sure, the hardware limits it already, the antenna and sender produce a ressonance circuit. But this can include a bandwidth of several GHz. Bastian -- Vulcans do not approve of violence. -- Spock, "Journey to Babel", stardate 3842.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, Nov 10, 2008 at 8:07 PM, Neil Williams <[EMAIL PROTECTED]> wrote: > I'm confused by the new name - what are we blending and why confuse > "Pure" and "Blend" in the same name? > > Emdebian is a customised Debian too - we will have two flavours soon, a > functionally-identical but smaller Debian based on Squeeze (Emdebian > Grip) and a maximally reduced flavour with functional changes called > Emdebian Crush. Emdebian is a more of a Debian-derived distribution (like Ubuntu/Debian-Edu), Debian Pure Blends (and the old CDDs) are simply a group of people working within Debian to make Debian itself suitable for a specific audience. I do think the new name is much better than the old one, but I agree that it still isn't perfect. I think "raw consensus" is roughly equal to "rough consensus". -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Montag, 10. November 2008, Paul Wise wrote: > On Tue, Nov 11, 2008 at 12:11 AM, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > - You state that screenshot will be released under the same term of > > the screenshot-ed package, why so? It seems to me rather arbitrary > > and makes impossible to bundle all screenshot together on a media > > and distribute them under a consistent license. > > > > Suggestion: just name a license and stick to it. > > screenshots are derivative works (according to SPI legal counsel): > > http://lists.debian.org/debian-legal/2008/08/msg00016.html So are we safe as long as we don't include non-free packages and claim that the screenshots are licensed under the terms of the application itself? IANAL and find that gibberish from your quoted posting pretty hard to understand. (It's hard enough to understand legal texts in my native language.) Christoph -- ~ ~ ".signature" [Modified] 1 line --100%--1,48 All signature.asc Description: This is a digitally signed message part.
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 4:46 PM, Christoph Haas <[EMAIL PROTECTED]> wrote: > On Montag, 10. November 2008, Stefano Zacchiroli wrote: >> On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: >> > it took a little longer than I expected but I finally launched >> > http://screenshots.debian.net >> >> First of all thanks a lot for the effort, the result is already really >> cool and in perspective it is amazingly useful! > > Thanks. I love positive feedback. Developers often tend to point out errors > way more than enjoying what's already there. :) Great job! I am looking forward when this will be available from packages.debian.org. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Montag, 10. November 2008, Miriam Ruiz wrote: > 2008/11/10 Christoph Haas <[EMAIL PROTECTED]>: > > I can even offer JSON, SOAP, XML, whatever if needed. Some URL that > > can be used in an IMG/SRC tag should probably be sufficient for > > packages.d.o. I'll soon document the URL schema so everybody can use > > it. Just let me know what information you need and I'll try providing > > a proper API. > > I'm using fixed 324x240 thumbnails for goplay and its derivatives. It > would be quite straightforward to make the program able to download > thumbnails from there when they cannot be found locally, if we can do > something about the size. Do you have a fixed size for thumbnails? The large images are no larger than 800x600 and the thumbnails are no larger than 160x120. I retain the aspect but shrink the images if they are larger than these limits. So if you want to upload a 320x240 image then the large image will be kept that way (as it's no larger than 800x600) and just a thumbnail is generated. So I store exactly two versions as files (to prevent having them resized on-the-fly). You could get the large version and shrink it yourself if that's sufficient. I don't have the "original" image available after reducing it to 800x600 any more. I'm open to suggestions though. Christoph signature.asc Description: This is a digitally signed message part.
Bug#505209: ITP: yagtd -- utility to help organize your to-do lists
Package: wnpp Owner: Max Vozeler <[EMAIL PROTECTED]> Severity: wishlist * Package name: yagtd Version : 0.2.4 Upstream Author : MiKael NAVARRO <[EMAIL PROTECTED]> * URL : https://gna.org/projects/yagtd/ * License : GPL Programming Lang: Python Description : utility to help organize your to-do lists yagtd is a very simple utility designed to make the management of your to-do list quick and easy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
2008/11/10 Christoph Haas <[EMAIL PROTECTED]>: > So are we safe as long as we don't include non-free packages and claim that > the screenshots are licensed under the terms of the application itself? Yes, in my opinion that should be enough. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
Le Mon, Nov 10, 2008 at 01:51:05PM +, Neil Williams a écrit : > That is where I found "Blends" confusing - it conjures up images of > mixing two different things into one. This tempts me a lot to mix stable and backports.debian.org (once it exists) in our shiny new blender :) By the way, I really want to thank Andreas for his courage to manage the renaming of the CDD concept. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
2008/11/10 Christoph Haas <[EMAIL PROTECTED]>: > I can even offer JSON, SOAP, XML, whatever if needed. Some URL that can be > used in an IMG/SRC tag should probably be sufficient for packages.d.o. > I'll soon document the URL schema so everybody can use it. Just let me > know what information you need and I'll try providing a proper API. I'm using fixed 324x240 thumbnails for goplay and its derivatives. It would be quite straightforward to make the program able to download thumbnails from there when they cannot be found locally, if we can do something about the size. Do you have a fixed size for thumbnails? Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
set unbound does not run default by /etc/default/unbound (Re: Bug#500176: This bug is still around and release-critical
Hi,
On Wed, 8 Oct 2008 12:16:53 +0900
Hideki Yamane <[EMAIL PROTECTED]> wrote:
> > I see no proper fix, except using an /etc/default file, which is ugly.
>
> Using /etc/default/unbound is reasonable, I think. Some of daemon packages
> (e.g. rsync) are not started by default because it is set in its /etc/default
> file.
For lenny, it should be fixed to work on most of environment that is used,
if it is ugly, though. I made a patch for this issue, please consider to
apply it for the pacakge.
# or anyone will fix it, please :-)
--
Regards,
Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
http://wiki.debian.org/HidekiYamane
diff -urN debian.orig/changelog debian/changelog
--- debian.orig/changelog 2008-10-08 11:56:40.0 +0900
+++ debian/changelog 2008-11-09 10:52:40.0 +0900
@@ -1,3 +1,14 @@
+unbound (1.0.2-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/{unbound.init,unbound.default}
++ set not start by default, to avoid that port 53 blocking by other name
+ servers will cause install problems
+ * debian/unbound.prerm
++ fix lintian "unbound: maintainer-script-hides-init-failure prerm:5" error
+
+ -- Hideki Yamane (Debian-JP) <[EMAIL PROTECTED]> Sun, 09 Nov 2008 10:52:13 +0900
+
unbound (1.0.2-1) unstable; urgency=low
* New upstream release;
diff -urN debian.orig/unbound.default debian/unbound.default
--- debian.orig/unbound.default 2008-10-08 11:56:40.0 +0900
+++ debian/unbound.default 2008-11-09 09:27:50.0 +0900
@@ -1,3 +1,11 @@
+# Do you want to start unbound?
+# only allowed values are "true" and "false".
+# if you already use other DNS server, they would listen port 53,
+# so unbound fails to start. Please adjust, then set "true".
+
+UNBOUND_ENABLE=false
+
+
# config file path
#DAEMON_OPTS="-c /etc/unbound/unbound.conf"
diff -urN debian.orig/unbound.init debian/unbound.init
--- debian.orig/unbound.init 2008-10-08 11:56:40.0 +0900
+++ debian/unbound.init 2008-11-10 17:42:47.0 +0900
@@ -1,6 +1,29 @@
#!/bin/sh
+set -e
+
+### BEGIN INIT INFO
+# Provides: unbound
+# Required-Start:$network $remote_fs $syslog
+# Required-Stop: $network $remote_fs $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: validating, recursive, caching DNS resolver
+# Description: Unbound is a recursive-only caching DNS server which can
+#optionally perform DNSSEC validation of results. It
+#implements only a minimum amount of authoritative service
+#to prevent leakage to the root nameservers: forward lookups
+#for localhost, reverse for 127.0.0.1 and ::1, and NXDOMAIN
+#for zones served by AS112. Stub and forward zones are
+#supported.
+#Unbound implements a number of security features, including
+#chrooting and privilege dropping. The Debian init script
+#will populate a chroot by default.
+#
+### END INIT INFO
+
NAME=unbound
+UNBOUND_ENABLE=false
DESC="recursive DNS server"
DAEMON=/usr/sbin/unbound
CHROOT_DIR=/var/lib/unbound
@@ -10,7 +33,18 @@
. /lib/lsb/init-functions
-test -f /etc/default/$NAME && . /etc/default/$NAME
+if [ -f /etc/default/$NAME ]; then
+ . /etc/default/$NAME
+ case "x$UNBOUND_ENABLE" in
+ xtrue|xfalse) ;;
+ *) log_failure_msg \
+ "Value of UNBOUND_ENABLE in /etc/default/$NAME must be either 'true' or 'false';"
+ log_failure_msg \
+ "not starting unbound daemon."
+ exit 1;
+ ;;
+ esac
+fi
install_chroot() {
if [ "$CHROOT" != "no" ]; then
@@ -40,14 +74,22 @@
case "$1" in
start)
-log_daemon_msg "Starting $DESC" "$NAME"
-if daemon_stopped; then
-install_chroot
-fi
-if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
-log_end_msg 0
+if "$UNBOUND_ENABLE"; then
+ log_daemon_msg "Starting $DESC" "$NAME"
+ if daemon_stopped; then
+ install_chroot
+ fi
+ if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE \
+ --name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
+ log_end_msg 0
+ else
+ log_end_msg 1
+ fi
else
-log_end_msg 1
+ if [ -s "$UNBOUND_CONFIG_FILE" ]; then
+ log_warning_msg \
+ "$NAME daemon is not enabled in /etc/default/$NAME, not starting..."
+ fi
fi
;;
@@ -61,14 +103,19 @@
;;
restart|force-reload)
-log_daemon_msg "Restarting $DESC" "$NAME"
-start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME --retry 5
-uninstall_chroot
-install_chroot
-if start-stop-dae
Re: screenshots.debian.net goes beta
2008/11/10 Miriam Ruiz <[EMAIL PROTECTED]>: > 2008/11/10 Christoph Haas <[EMAIL PROTECTED]>: > >> I can even offer JSON, SOAP, XML, whatever if needed. Some URL that can be >> used in an IMG/SRC tag should probably be sufficient for packages.d.o. >> I'll soon document the URL schema so everybody can use it. Just let me >> know what information you need and I'll try providing a proper API. > > I'm using fixed 324x240 thumbnails for goplay and its derivatives. It > would be quite straightforward to make the program able to download > thumbnails from there when they cannot be found locally, if we can do > something about the size. Do you have a fixed size for thumbnails? s/324x240/320x240/ Sorry for the mistake. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505208: ITP: pythontracer -- Python programs execution tracer and profiler
Package: wnpp Severity: wishlist Owner: Sandro Tosi <[EMAIL PROTECTED]> * Package name: pythontracer Version : 8.10.16 Upstream Author : Eyal Lotem <[EMAIL PROTECTED]> * URL : http://code.google.com/p/pythontracer/ * License : GPLv3 Programming Lang: Python/C Description : Python programs execution tracer and profiler Lets you see your Python program's execution as a tree of function invocations, each tree node exposing the real time, and CPU time (user/sys) of that call. This project consists of two main components: A Python tracer that can run your Python programs (much like "cProfile" and friends). A Gtk+ based GUI that can show the trace results. It uses a tiny auxiliary library written for it "graphfile" to allow append-only writing and reading static DAG's directly from file without reading it whole into memory at any stage. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Montag, 10. November 2008, Stefano Zacchiroli wrote: > On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > > it took a little longer than I expected but I finally launched > > http://screenshots.debian.net > > First of all thanks a lot for the effort, the result is already really > cool and in perspective it is amazingly useful! Thanks. I love positive feedback. Developers often tend to point out errors way more than enjoying what's already there. :) > On the guidelines: > > - You state that screenshot will be released under the same term of > the screenshot-ed package, why so? It seems to me rather arbitrary > and makes impossible to bundle all screenshot together on a media > and distribute them under a consistent license. > > Suggestion: just name a license and stick to it. If it's legally feasible I'd like to put all work under the MIT license and be done with it. I hope someone with a "legal" background can help a little here. > Then an usability comment: the only link under each screenshot is > "request removal". IMO it is too "tempting", because it is the large > and because it is the only link. Suggestion: replace it with the > classical "X" icon with a tooltip, and make it "less important" by > adding some other link, e.g., the suggested link to > packages.debian.org. I'll think of something. :) Although clicking on it comes up with a text entry field to the request isn't immediately filed. Previously I had an "are you sure" popup instead. > Out of curiosity, do you already have an API for accessing screenshot > data externally? I guess the packages.d.o are interested in that, and > for sure I'm interested in that to add a TODO item in the PTS for > missing screenshots (probably just for some class of packages, we'll > see). Thanks to the framework used (Pylons) I can fully control which URL does what. I intend to provide a URL that can be used for packages.debian.org to display the screenshots. Possibly like: http://screenshots.d.n/package/foobar/firstscreenshot I can even offer JSON, SOAP, XML, whatever if needed. Some URL that can be used in an IMG/SRC tag should probably be sufficient for packages.d.o. I'll soon document the URL schema so everybody can use it. Just let me know what information you need and I'll try providing a proper API. Christoph signature.asc Description: This is a digitally signed message part.
Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Neil Williams wrote: I was never particularly clear on why "Custom" was a bad name to use. Actually "distribution" was the worst part of the old name. Before we have another round of discussing names: Could everybody who is really interested in the projects please have a look into the paper[1] and see if they identify with the things described there. IMHO Emdebian does not really fit into this. To be a Debian Pure Blend everything has to be inside (pure) Debian. We just try to make sure that people understand this fact. If you would like to call Emdebian a "Custom Debian Distribution" this is perfectly fine now because this term is now not covered any more by a concept we are using which Emdebian does not really fit into. Kind regards Andreas. [1] http://cdd.alioth.debian.org/blends/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Neil Williams wrote: I guess what are talking about here is the mirrors. Do all Blends use unchanged Debian mirrors? Yes. What else would you expect if it says _inside_ Debian? A Debian Pure Blend has no separate mirror - THIS is the basic idea of the concept. If so, what are Blends blending? All mixtures are inside the Debian package pool. Out of these mixtures we want to fit the taste of a certain user group. Emdebian Grip *is* intended to be Debian, just 20% smaller (maybe 30% if There is no conflict. There are other things inside Debian than Debian Pure Blends. Originally the concept was called "Debian Internal Projects" [1] and originally the name "Custom Debian Distribution" was invented to avoid mixing up these user oriented projects from technical projects (like Emdebian, Debian-Installer, Debian-Live etc.). It just turned out that the name CDD immediately caused the wrong assumption (because of the distribution term) that it is a distribution which is based on Debian but *different* and our main focus is on telling people that we are *not* different. So for you Emdebian was, is and will be a Debian Internal Project which is listed at the place where it belongs to. This is what I wanted to say when I asked for having a look at the doc[2] - the name is choosen for a concept Emdebian does not really fit into. The intention is to have Grip generation entirely automated, even working as a repository update hook. To say it once more: I like your Emdebian effort but it is orthogonal to the user specific field scope. For instance: We might consider an Emdebian Med for medical stuff using embedded devices (which is in fact very interesting). I'm hoping that Grip will be seen differently - as a normal Debian install, just smaller. Whatever changes might be necessary to actually deploy Grip, I will be seeking to fold those changes into the relevant Debian packages. I hope you do not feel discriminated - but it is just not true that every project inside Debian now has to use the name we have choosen for a specific internal concept. Kind regards Andreas. [1] http://www.debian.org/devel/#projects [2] http://cdd.alioth.debian.org/blends -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: Summarizing the choices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Palfrader wrote: > On Sat, 08 Nov 2008, Theodore Tso wrote: > >>Fortunately for us, at the >> moment I am not aware of large numbers of highly popular laptops or >> servers for which non-free firmware is necessary before the firmware >> would be able to access the network. > > HP DL360 G5: > firmware-bnx2 >(Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet) > > Yes, I was really thrilled when I found out we can't install lenny in > any sane way on debian.org hardware. That really sums it up nicely for me... Since a kernel containing sourceless firmware won't be shiped with debian and won't be called a debian kernel, to me it seems obvious that a computer running such firmware can not be called a computer runing the debian OS. I think debian should not lie to it's users and should amend the first sentence on www.debian.org accordingly: > Debian is a free operating system (OS) for your computer. ...provided you don't want to use wireless or some other hardware that requires sourceless firmware [footnote/link to a list]. With the hence large list of exceptions it will be misleading to say "debian is a free OS for _your_ computer". Debian should also admit at a prominent position of the web sites and the release notes that their own servers won't run debian and that most likely few of their developers run debian on a computer that has a working wireless or a working gsm etc. (The options for wireless are summarized in [1]. I'd really like to know the fraction of DDs who will run plain debian and do without sourceless stuff on all their computers, but I guess it will become increasingly and embarrassingly small...) The lengths of the various threads are an indication that there is no simple way out of this dilemma. In my personal opinion it would be better to amend the social contract instead of moving in the direction that debian (purely) won't run on a large fraction of current hardware. Yes, I'd love to only have firmware (and bioses) with sources, but since this seems unrealistic for the foreseeable future, as a user I'd prefer to have support for firmware _inside_ debian instead of _outside_ of it (in non-free, and opening a whole bunch of other non-free along with it). It will leave me in an awkward position, if the firmware that controls my network connectivity will _not_ be supported by the OS, at least at the level that (security) updates of the firmware will be added to releases and point releases. Along the promise of free software, the social contract also promises that the projects priorities are it's users. I think that the tremendous success of ubuntu is mainly based on their better priorities for the users, while debian's impression of focussing on the interests of their own developers promotes users away from debian. There are much to many professionals who use debian on 100% of their servers, but admit of using ubuntu on their home computers. I think the best way out of this dilemma is to add a 'non-free firmware' section and make this section part of official debian. A provision is that the firmware is not run on the main processor. A distinction between sourceless firmware loaded by the OS (turning it non-debian) and that present by other means (in agreement with the SC) is pointless. In fact, it is often better to have firmware loaded by the OS compared to have firmware 'hard wired' to the chip, since the latter case makes upgrades much more cumbersome for the user. By sticking to the social contract in the present form, debian pushes hardware vendors in the opposite direction (firmware on the chip) and thus will make it more difficult for their users. Of course that's all only my humble opinion. [Disclaimer: I am not a DD. ] Cheers, Johannes [1] http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkX9owACgkQC1NzPRl9qEVBNwCfZULiVU4eEBO2kvVk7z4418oz Q3cAnRaX9bVeRppO+G16SMXhNO8OoHDq =ogFL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
* Andreas Tille [Mon, 10 Nov 2008 10:26:46 +0100]: > Hello, Hi Andreas, > So we finally found a raw consensus for a new name: > Debian Pure Blends What does "raw consensus" mean here? It doesn't seem to be an existing English idiom... :-) [Maybe you meant "rough", I don't know.] Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505194: ITP: clawsker -- Configuration tweaker for Claws Mail
Package: wnpp Severity: wishlist Owner: Ricardo Mones <[EMAIL PROTECTED]> * Package name: clawsker Version : 0.5.0 Upstream Author : Ricardo Mones * URL : http://www.claws-mail.org/clawsker * License : GPLv3+ Programming Lang: Perl Description : Configuration tweaker for Claws Mail Clawsker is an applet to edit the so called Claws Mail hidden preferences. . Claws Mail is a fast, lightweight and feature-rich MUA with a high number of configurable options. To keep the binary small and fast some of these preferences which not widely used are not provided with a graphical interface for inspection and/or modification. . Users wanting to edit such preferences had to face raw edition of their configuration files, now you can do it with a convenient GTK2 interface using Clawsker. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Stefano Zacchiroli wrote: On Mon, Nov 10, 2008 at 10:26:46AM +0100, Andreas Tille wrote: Renaming Custom Debian Distributions to Debian Pure Blend - - [3] http://cdd.alioth.debian.org/blends ^^^ .oO( Have you thought about renaming the Alioth project? CNAMEs do matter. ) Yes, I have. Actually this would be my next step. I just wanted to make the renaming process public and then take the next steps. I also plan to ask for a new mailing list debian-blends but leaving the list debian-custom for SimpleCDD issues. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: Summarizing the choices
On Sat, Nov 8, 2008, Thomas Bushnell BSG wrote: > Why not just support it in non-free exactly the way we do other things? Indeed. Arguably, documentation is even more important than making non-Free firmware trivially-accessible to users, and users might be tempted to add non-free to their repo selections to get to the documentation. So, if splitting out non-free-firmware is an argument to help avoid users accidentally getting software that's in non-free installed on their computers, then splitting out the documentation would be even more of a priority to accomplish this goal. I consider documentation far more important because it's pertaining to the Free Software that Debian ships, whereas the firmware is for hardware that Debian doesn't ship, and that (i) is mostly irrelevant, or (ii) doesn't really require the firmware, or (iii) is relatively easy to replace. Say, even a WiFi card soldered to the motherboard can be "replaced" by a USB WiFi interface. So, if you consider seriously the introduction of a non-free-firmware repo, please take the opportunity to introduce a non-DFSG docs repo as well. Best, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
Andreas Tille wrote: > Yes. What else would you expect if it says _inside_ Debian? A Debian > Pure Blend has no separate mirror - THIS is the basic idea of the concept. so then call them 'Debian Foo' team, since this is what they are and no different to the various teams we have already (where some of them are not limited being 100% packaging oriented; e.g. kde team that releases livecds). everything else is, imho, useless waste of time explaining and defining things in terminology that does not matter for 99% of the people here (ymmv, no offence intended et al. i'm glad and thankful for what you do in and arround debian, but the naming game isn't one of them). Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Miriam Ruiz wrote: We realised that the old name Custom Debian Distributions just sended the wrong message to outsiders: The conclusion that CDDs are something else than Debian was to "obvious" if people did not read the relevant documentation. So we finally found a raw consensus for a new name: Debian Pure Blends I'm not exactly sure that I like the new name, to be honest. Well, the renaming was announced on debian-custom list and all lists of existing CDDs (also for instance on Debian Junior list[1]). And, yes, you are not the only one who is not really happy, but this name has won the poll and I also asked[2] whether "people insist on a condorset voting". So there was a chance to take some influence for people who are involved. Kind regards Andreas. [1] http://lists.debian.org/debian-jr/2008/09/msg3.html [2] http://lists.debian.org/debian-custom/2008/10/msg2.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [IVBB-Spam-Verdacht] Re: Announcement: Debian Pure Blends news
On Mon, 10 Nov 2008, Adeodato Simó wrote: What does "raw consensus" mean here? It doesn't seem to be an existing English idiom... :-) [Maybe you meant "rough", I don't know.] Yes, sorry - I intended to writh rough (perhaps I should ask co authors for announcements next time). In practice the consensus was reached on a ddole poll. Kind regards Andreas. -- http://fam-tille.de
ITP: Elmer -- Finite element software for multiphysics problems
Package: wnpp Severity: wishlist Package name: elmerfem Version: 5.4.1 Author: CSC -- IT Center for Science Ltd (Finnish Ministry of Education) License: GPL URL: http://www.csc.fi/elmer/ Elmer is an open source mutiphysics simulation package developed by CSC in collaboration with Finnish universities, research institutes and industry. It includes physical models of fluid dynamics, structural mechanics, electromagnetics, heat transfer and acoustics, for example. These are described by partial differential equations which Elmer solves by the Finite Element Method (FEM). Elmer uses METIS (or its free counterpart Scotch) for mesh partitioning, and (P)ARPACK, UMFPACK, BLAS/LAPACK and hypre to solve the sparse linear systems resulting from FEM discretization. It includes pre- and post-processors, and several examples illustrating simulation of various physical phenomena. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: DFSG violations in Lenny: Summarizing the choices
Am 2008-11-08 15:29:44, schrieb Thomas Bushnell BSG: > It seems to me that, if this is really true, then the hardware > manufacturers have been lying to the FCC for years, claiming that the > user cannot reprogram the card, without explaining that, in fact, it's > just that users may not know how to, but that they can do so without any > hardware mucking. Not realy since in Europe a WiFi Card has for exanlep only 100mW (which allow an operativ-radius of arround 300m) while in Australia and the USA it can have 400mW and you can reach your AT on over 3 miles... My 68 AP's "Proxim Tsunami MP.11a" run with 800mW in Strasbourg/France and Kehl/Germany, BUT, you need a commercial License for it. And of course, you CAN harm others if not correct implemented and tested. Exactly the same WiFi Chip is used on Consumer WiFi cards... Now load the firmware from the Proxim Tsunami MP.11a into your PCMCIA or ExpressCard... Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
how far is Debian Edu from Debian?
Hi, http://ftp.skolelinux.org/skolelinux/etch_needs_love.html and http://ftp.skolelinux.org/skolelinux/lenny_needs_love.html now show (part of) the answer to the question "how far is Debian Edu from Debian?": Source packages in Debian etch main: 10225 Source packages in Debian Edu etch local: 25, number of identical packages in percent: 99.75500 Source packages in Debian Edu etch-test local: 27, number of identical packages in percent: 99.73500 Source packages in Debian lenny main: 12275 Source packages in Debian Edu lenny local: 0, number of identical packages in percent: 100.0 Source packages in Debian Edu lenny-test local: 5, number of identical packages in percent: 99.95900 (This is due to the fact that our lenny currently _is_ identical to Debian, because we only use lenny-test for development at the moment.) regards, Holger pgp7YQf4b9uuf.pgp Description: PGP signature
Re: DFSG violations in Lenny: Summarizing the choices
Am 2008-11-09 12:19:06, schrieb Josselin Mouette: > Why in the world would we do that when we have all that???s needed to > simply move the firmware images to non-free? And what, if peoples do not want to use non-free but get there hardware working? The best would be to create a new flavour called "firmware" which IS non-free but seperated from the flavour "non-free". Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: DFSG violations in Lenny: Summarizing the choices
Am 2008-11-10 09:54:24, schrieb Johannes Wiedersich: > I think the best way out of this dilemma is to add a 'non-free firmware' > section and make this section part of official debian. A provision is But this should be a "volatile" archive, which allow the upload of new firmware releases and not let the users stuck with old outdated firmware Note: On any of my computers I have "contrib" and "non-free" NOT configured. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: DFSG violations in Lenny: Summarizing the choices
Am 2008-11-10 12:56:26, schrieb Karl Goetz: > Why are they making hardware that can transmit on *any* frequency? Why > are they not making hardware that transmits in the 2.4GHz ISM band > perhaps with firmware to 'fine tune' it? Seems strange to pour lots of > money into making an all-band radio then locking it to a 500MHz band. Because the differnt LAWs in the world? The WiFi chip must support 2.1-2.8 GHz where the UPPER/LOWER frequencies are disallowed in 90% of the world... Making 3 differnt WiFi chips would let the cost explode... And of course, some of the Consumer Chips exist in Industrial/Military grade... There is NO need to develop TWO different chips, it is only about quality testing likefor Solar-Cells. The A-Ware goes into the space tecnology, the B-Ware is for industrial use and the C-Ware for standard Solar-Power Plants and Consumers... Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Who owns /etc/default/locale?
On Sun, 2008-11-09 at 18:43 +0100, Andreas Metzler wrote:
> Frank Lin PIAT wrote:
> []
> > I have question which is directly related: shouldn't a package own and
> > declare all the configuration files that it uses, even if it doesn't
> > install or modify it?
> [...]
>
> No. Not all configuration files can be managed as dpkg conffiles.
I did not wrote that all configuration file should be conffiles : I
wrote that all (well known) configuration files should be tracked.
Some configuration files are used by packages but they aren't declared
anywhere. Also, as I mentioned, those file aren't necessarily removed by
the package when it is purged.
For example, on my laptop I've used a quick script to check
if /etc/default/* files are declared by the scripts located
in /etc/{init.d,cron.*}... as you can see, almost half of them don't
belong to any package.
apache2.2-common uses /etc/default/apache2 owned by apache2.2-common
exim4-base uses /etc/default/exim4 NOT OWNED
live-helper uses /etc/default/live-helper_autobuild owned by
live-helper
acpid uses /etc/default/acpid owned by acpid
apache2.2-common uses /etc/default/apache2 owned by apache2.2-common
apt-proxy uses /etc/default/apt-proxy owned by apt-proxy
atftpd uses /etc/default/atftpd NOT OWNED
avahi-daemon uses /etc/default/avahi-daemon owned by avahi-daemon
bluez-utils uses /etc/default/bluetooth owned by bluez-utils
initscripts uses /etc/default/bootlogd owned by initscripts
clamav-daemon uses /etc/default/clamav-daemon owned by clamav-daemon
console-tools uses /etc/default/locale NOT OWNED
cpufrequtils uses /etc/default/cpufrequtils owned by cpufrequtils
cron uses /etc/default/cron owned by cron
cron uses /etc/default/locale NOT OWNED
cups uses /etc/default/cups owned by cups
dbus uses /etc/default/dbus owned by dbus
dhcp3-server uses /etc/default/dhcp3-server NOT OWNED
dnsmasq uses /etc/default/dnsmasq owned by dnsmasq
exim4-base uses /etc/default/exim4 NOT OWNED
gdm uses /etc/default/locale NOT OWNED
hal uses /etc/default/hal owned by hal
initscripts uses /etc/default/halt owned by initscripts
hdparm uses /etc/default/hdparm owned by hdparm
ifupdown uses /etc/default/ifupdown owned by ifupdown
ifupdown uses /etc/default/ifupdown owned by ifupdown
irda-utils uses /etc/default/irda-utils NOT OWNED
console-common uses /etc/default/locale NOT OWNED
klogd uses /etc/default/klogd owned by klogd
cpufrequtils uses /etc/default/loadcpufreq NOT OWNED
cpufrequtils uses /etc/default/powernowd NOT OWNED
initscripts uses /etc/default/locale NOT OWNED
initscripts uses /etc/default/devpts owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
initscripts uses /etc/default/mountoverflowtmp NOT OWNED
initscripts uses /etc/default/devpts owned by initscripts
initscripts uses /etc/default/tmpfs owned by initscripts
network-manager uses /etc/default/NetworkManagerDispatcher NOT OWNED
network-manager uses /etc/default/NetworkManager NOT OWNED
nfs-common uses /etc/default/nfs-common NOT OWNED
nfs-kernel-server uses /etc/default/nfs-kernel-server NOT OWNED
openbsd-inetd uses /etc/default/openbsd-inetd NOT OWNED
partimage-server uses /etc/default/partimaged owned by partimage-server
pcmciautils uses /etc/default/pcmciautils NOT OWNED
portmap uses /etc/default/portmap NOT OWNED
rsync uses /etc/default/rsync owned by rsync
sane-utils uses /etc/default/saned owned by sane-utils
sl-modem-daemon uses /etc/default/slmodemd NOT OWNED
sl-modem-daemon uses /etc/default/sl-modem-daemon owned by
sl-modem-daemon
openssh-server uses /etc/default/ssh owned by openssh-server
sysklogd uses /etc/default/syslogd owned by sysklogd
udftools uses /etc/default/udftools owned by udftools
acpi-support uses /etc/default/acpi-support owned by acpi-support
The scriptlet I used:
for x in $(grep --binary-files=without-match -R -E "/etc/default/[^
$].*[^~]" /etc/{init.d,cron.*} | sed -e 's#\([^:]*\):.*
\(/etc/default/[[:alnum:]_-]*\).*#\1:\2#' | sort -u | grep -v
':/etc/default/rcS' ) ; do script="${x##*:}"; cfg="${x%%:*}" ; pkg=
$(dpkg -S "$cfg" | sed -e 's/:.*//') ; owner=$(dpkg -S $script
2>/dev/null | sed -e 's/:.*//' ) ; echo -n "$pkg uses ${x##*:} " ; if
[ "$owner" ] ; then echo "owned by $owner" ; else echo "NOT OWNED" ;
fi ; done
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
Hi, With a new option added to the list, the discussion period is extended again, by a week, starting 10 Nov 2008 21:28:29. The proposals, tentatively, as reproduced below. |+---+---+---+---+---| || 1 | 2 | 3 | 4 | 5 | |+---+---+---+---+---| | Robert Millan <[EMAIL PROTECTED]>| 1 | 1 | 1 | | | | Bas Wijnen <[EMAIL PROTECTED]> | 1 | | | | | | Manoj Srivastava <[EMAIL PROTECTED]> | 1 | 1 | | | 1 | | Holger Levsen <[EMAIL PROTECTED]> | 1 | 1 | 1 | 1 | | | Peter Samuelson <[EMAIL PROTECTED]> | 1 | 1 | 1 | | | | Hubert Chathi <[EMAIL PROTECTED] | 1 | 1 | 1 | | | | Andreas Barth <[EMAIL PROTECTED]>| | | | 1 | | | Alexander Reichle-Schmehl <[EMAIL PROTECTED]> | | | | 1 | | | Reinhard Tartler <[EMAIL PROTECTED]> | | | | | | | Bernd Zeimetz <[EMAIL PROTECTED]> | | | | 1 | | | Neil McGovern <[EMAIL PROTECTED]> | | | | 1 | 1 | | Frans Pop <[EMAIL PROTECTED]> | | 1 | 1 | | | | [EMAIL PROTECTED] (Rémi Vanicat) | 1 | 1 | 1 | 1 | | | "John H. Robinson, IV" <[EMAIL PROTECTED]> | | | | | 1 | | Lars Wirzenius <[EMAIL PROTECTED]>| | | | | 1 | | Damyan Ivanov <[EMAIL PROTECTED]> | | | | | 1 | | Colin Tuckley <[EMAIL PROTECTED]> | | | | | 1 | |+---+---+---+---+---| || 7 | 7 | 6 | 6 | 6 | |+---+---+---+---+---| #+TBLFM: $2=vsum(@[EMAIL PROTECTED])::$3=vsum(@[EMAIL PROTECTED])::$4=vsum(@[EMAIL PROTECTED])::$5=vsum(@[EMAIL PROTECTED])::$6=vsum(@[EMAIL PROTECTED]) ,[ Proposal 1: reaffirm the Social Contract ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that we promised to deliver a 100% free operating system | (Social Contract #1); | | 3. Given that we have known for two previous releases that we have | non-free bits in various parts of Debian, and a lot of progress has | been made, and we are almost to the point where we can provide a | free version of the Debian operating system, we will delay the | release of Lenny until such point that the work to free the operating | system is complete (to the best of our knowledge as of 1 November 2008). ` ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress on DFSG compliance | issues; however, they are not yet finally sorted out; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the packages distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat fixing of DFSG violations as | a best-effort process. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, dec
Re: screenshots.debian.net goes beta
Hi Christoph, many thanks for this effort - I admit I started dreaming of such a thing in the beginning of this year - it does not happen that often that dreams become true that fast. ;-) On Mon, 10 Nov 2008, Christoph Haas wrote: Thanks to the framework used (Pylons) I can fully control which URL does what. I intend to provide a URL that can be used for packages.debian.org to display the screenshots. Possibly like: http://screenshots.d.n/package/foobar/firstscreenshot I can even offer JSON, SOAP, XML, whatever if needed. Some URL that can be used in an IMG/SRC tag should probably be sufficient for packages.d.o. Yes, this is exactly what I would need. A python API would be really great. I would like somethin like def GetScreenshotsURLS( ): ... return The entry of the dict should be 'None' / '' or something like that if there is no screenshot available and if a screenshot is available a string which enables to address icon and screenshot (of latest program version in case several versions are available). In addition to this I would love to get some information about languages the screenshot is available - in case you would like to implement screenshots in different languages. I'll soon document the URL schema so everybody can use it. Just let me know what information you need and I'll try providing a proper API. I would like to add screenshots to the entries on the Debian Pure Blends tasks pages like http://debian-med.alioth.debian.org/tasks/imaging.html I would like to put a link to "Upload screnshot for package foo here" in case there is no screenshot and an icon which links to the real image in case there is one. If we would have even an i18n screenshot I would link to the apropriate language or alternatively to the English default (and add a link "Upload screenshot for package foo in language bar"). Thanks again for your effort Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 04:46:10PM +0100, Christoph Haas wrote: > Thanks. I love positive feedback. Developers often tend to point out > errors way more than enjoying what's already there. :) My pleasure :) > > Suggestion: just name a license and stick to it. Given the comment from pabs (which gave me a good WTF moment), I withdraw this request of mine. > > Then an usability comment: the only link under each screenshot is > > "request removal". IMO it is too "tempting", because it is the large > > and because it is the only link. Suggestion: replace it with the > > classical "X" icon with a tooltip, and make it "less important" by > > adding some other link, e.g., the suggested link to > > packages.debian.org. > > I'll think of something. :) Although clicking on it comes up with a > text entry field to the request isn't immediately filed. Previously > I had an "are you sure" popup instead. Note that I haven't said that users will request removals by mistake, I'm sure they will withdraw as soon as they see the popup (or whatever else). Still, if the link is "too tempting", people will click on it, just loosing time, while they can be directed to more useful targets. Maybe I'm drifting too much on HCI here :) > Thanks to the framework used (Pylons) I can fully control which URL does > what. I intend to provide a URL that can be used for packages.debian.org > to display the screenshots. Possibly like: > http://screenshots.d.n/package/foobar/firstscreenshot OK, REST interface would be nice. > I can even offer JSON, SOAP, XML, whatever if needed. Some URL that IMO the BTS has taught us that SOAP is the good way to go, on top of that we can have whatever programming language API we need. Additionally, the PTS needs kind of "all at once" listing, a place from which we can download at each PTS pulse a mapping package/screenshot(s), to avoid hammering screenshots.d.n with per-package requests. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > Have fun and let me know what you think. Thank you for this; it looks very nice! Some quick comments: * don't list packages with only pending screenshots in the list of screenshots. There's a few packages at the moment listed as " 0 (1 waiting for approval)" which just clutter the list, since there's nothing to see yet :) * There are 14 pages and the navigation is truncated to 'Page: 1 2 3 .. 14 >'. Could you (optionally) display links to all pages? Or alter the number of results per page (increase, or make user configurable)? * an optional list of packages with screenshots which displayed the thumbnail would be nice. * It would be nice if the homepage column pointed at something more Debian specific, e.g. the packages page. I was going to suggest the PTS page, but of course that's developer-oriented and this is user-oriented. packages.debian.org/foo shows more useful info for existing Debian users, and includes the homepage from the control field where available. * what does the search field operate on? A search for 'games' shows up gridlock.app which contains 'games' in the short description, and is in category games. I'm not sure which it matched on. If only the short text, it would be nice to search on other criteria. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 12:02:24AM +0100, Stefano Zacchiroli wrote: > IMO the BTS has taught us that SOAP is the good way to go, on top of > that we can have whatever programming language API we need. I'd agree that it's tought us the value of *an* API, but I (at least) have yet to love SOAP. Excerpt from debgtd: ... def reload_backend(self, bugs): model = self.model # fetch the details of all of these bugs # christ, someone point me at something which will make the # following clear. foo = self.server.get_status(bugs)[0] if 1 == len(bugs): # work around debbts unboxing "feature" hash = foo['value']._asdict() if hash['id'] in model.bugs: bug = model.bugs[hash['id']] model.update_bug(hash) ... I might just be being stupid, and one layer of boxing was conditional and is actually a design feature of BTS in particular, but I couldn't believe how many layers of dicts-inside-lists-inside-something-else there were for various queries. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
Miriam Ruiz wrote: I'm not exactly sure that I like the new name, to be honest. I saw the name and initially thought it was related to blender. http://www.blender.org/ Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
Hi, > | Reinhard Tartler <[EMAIL PROTECTED]> | | | | | | I think you've missed to count <[EMAIL PROTECTED]> here. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505224: RFP: freecad -- An extensible CAx program (alpha)
Package: wnpp Severity: wishlist Owner: Robert Millan <[EMAIL PROTECTED]> * Package name: freecad Version : 0.7.1672 * URL : http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page * License : LGPLv2.1+ Programming Lang: C++, Python Description : An extensible CAx program (alpha) FreeCAD is a CAx RAD based on OpenCasCade, Qt and Python. It features some key concepts like macro recording, workbenches, ability to run as a server and dynamically loadable application extensions and it is designed to be platform independent. . Currently, FreeCAD can import and display CAD models in IGES, STEP, and BRep formats and meshes in STL, BMS, AST and Wavefront OBJ formats. Editing and modeling features are currently somewhat limited. A preliminary package is available at: http://people.debian.org/~rmh/freecad/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
Noah Slater wrote: [...] > > I do think the page lengths, or result count per page, could be increased. > +1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Montag, 10. November 2008, Jon Dowland wrote: > On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > > Have fun and let me know what you think. > > Thank you for this; it looks very nice! > > Some quick comments: > > * don't list packages with only pending screenshots in the list of >screenshots. There's a few packages at the moment listed as " 0 >(1 waiting for approval)" which just clutter the list, since there's >nothing to see yet :) Good idea. Put on the todo list. > * There are 14 pages and the navigation is truncated to 'Page: 1 2 3 .. >14 >'. Could you (optionally) display links to all pages? Or alter >the number of results per page (increase, or make user configurable)? I'll change the pager radius to 10. Will be fixed in the next deployment. > * an optional list of packages with screenshots which displayed the >thumbnail would be nice. You mean a list where each package shows the screenshots right in the list? That's a nice idea. Minimizes clicking and loading. Put on the todo list. > * It would be nice if the homepage column pointed at something more >Debian specific, e.g. the packages page. I was going to suggest the >PTS page, but of course that's developer-oriented and this is >user-oriented. packages.debian.org/foo shows more useful info for >existing Debian users, and includes the homepage from the control >field where available. The version I'll deploy tomorrow contains a link to packages.d.o/PACKAGENAME. I loved the idea to point directly to the homepage though because that's likely where users search for more information before installing software. > * what does the search field operate on? A search for 'games' shows up >gridlock.app which contains 'games' in the short description, and is >in category games. I'm not sure which it matched on. If only the >short text, it would be nice to search on other criteria. Currently it's a case-insensitive search over the package name and short description. I'm open to suggestions. Thanks for your constructive feedback. I'm looking forward to the next version (which will even be faster because I'm moving to another VPS). Cheers Christoph -- A guess is just a guess until you turn it into a pie chart. Then it's an analysis. (Scott Adams) signature.asc Description: This is a digitally signed message part.
Re: screenshots.debian.net goes beta
Christoph Haas wrote: > Fellow developers... > > it took a little longer than I expected but I finally launched > > http://screenshots.debian.net Great! thanks for your great job > > after two weeks of programming fun. [...] > > Please take a look at the site, consider uploading screenshots of your > favorite application and give some feedback. The approach is rather open. [...] > > Have fun and let me know what you think. * When browsing the packages list it would be great if you could also provide links to browse packages by name (e.g. A, B, C, etc, you get what I mean). * Have you considered storing more information together with the images? (the version of the package is what I believe is the most relevant missing information). * And what about letting the package uploaders upload the screenshots of their packages on their own without requiring any further moderation? all is needed is a maintainer-gpg key relationship and some sort of incoming queue where images are uploaded (packagename_version.ext) and then the output of md5sum foo_0.1.png bar_0.2.png | gpg --clearsign is uploaded (or sha1sum if you are paranoid). This has the following advantages: a) batch image uploads can be done, b) no interaction is required via the web interface, c) validating the incoming data is as simple as running gpg with the DDs and DMs --keyring, md5sum -c mybatchupload.asc, and then making sure the key owner has upload rights for those packages. > > Cheers > Christoph Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 9:08 AM, Raphael Geissert <[EMAIL PROTECTED]> wrote: > * When browsing the packages list it would be great if you could also provide > links to browse packages by name (e.g. A, B, C, etc, you get what I mean). > * Have you considered storing more information together with the images? (the > version of the package is what I believe is the most relevant missing > information). Version info would be useful for providing a list of packages with outdated screenshots in any given dist (sid/etch). Also, I think multiple screenshots per package are needed so that the packages.d.o/sid/foo and packages.d.o/etch/foo pages can point to the right screenshots. s.d.n/outdated/sid/a s.d.n/outdated/etch/b Also need lists of packages without screenshots for a given dist: s.d.n/needed/sid/a s.d.n/needed/etch/b -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 12:32 AM, Christoph Haas <[EMAIL PROTECTED]> wrote: > So are we safe as long as we don't include non-free packages and claim that > the screenshots are licensed under the terms of the application itself? > IANAL and find that gibberish from your quoted posting pretty hard to > understand. (It's hard enough to understand legal texts in my native > language.) In theory, yeah just main/contrib should be safe. There could be issues with say, emulator screenshots showing non-free games or Microsoft Office in wine, BeOS in qemu or a game in contrib with non-free graphics or a game in main with a mod from outside Debian or something. The other thing is that for the purposes of screenshots.d.n the fair use provisions in some jurisdictions might be enough, the PDF produced by SPI legal counsel discusses this. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505251: ITP: libnet-amazon-s3-tools-perl -- Command line tools for Amazon AWS S3
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: libnet-amazon-s3-tools-perl Version : 0.07 Upstream Author : Mark Atwood URL : http://search.cpan.org/dist/Net-Amazon-S3-Tools/ License : LGPL Programming Lang: Perl Description : Command line tools for Amazon AWS S3 These S3 command line tools allow you to manipulate and populate an S3 account. Refer to the documentation (pod and man) for each of the tools. . This Net::Amazon::S3::Tools module is mostly just a stub, to hoist the bundling and installation of the executable scripts that make up the actual tools. I did not manage to set ACLs with s3cmd, so I did a Google search and found this set of tools that fit my purpose. Is the Perl team interested in having it in its repository ? If not, another possibility would be to have it on collab-maint or in a co-maintained repository dedicated to computer clouds. I strongly believe in team work, and if nobody shows interest to co-maintain, I will simply conclude that the package is too trivial and not interesting enough for Debian anyway, and close the ITP. PS: Although I claimed sometimes that I will only packages programs relevant to life sciences, this is actually the case here as I intend to prepare a Debian Med image for the Amazon elastic computer cloud :) Have a nice day, -- Charles Plessy Debian Med packaging team http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)
Michelle Konzack dijo [Sun, Nov 09, 2008 at 08:24:44AM +0100]: > Sorry, I am not nativ english spaker... > And yes is is what I have meant... Neither am I, so I'll try to get this point across one last time. > And there are several 100 cases where in general the projects are 100% > open, but for some security reasons there are major parts NOT OPEN and > since such software/firmware is the KEY of the device, it is useless > without the blob. > > Maybe Debian should allow (very exceptionel) such sensible software to > ship in main together with the Main-Software... > > My Hardware is no exception... > (...) > Now, if non-free is not on the CD/DVD or the firmware is not shiped with > main you are unable to install Debian on a TablePC or such because you > can not access the internet... Debian has long been known for putting its promises (SC) first. And without judging your (or other's) motivations and needs not to publicly distribute the sources for your firmware. I'm not saying it's bad that you keep it closed - you have completely legitimate reasons to do that. Now, what about the fact that Debian cannot be installed from its official ISOs if your hardware is in use? Maybe it's a wireless card, maybe a hard disk controller. Sadly, the official CD-ROM won't be able to use it. But - If you put the Extra Firmware udev, available as a simple file you can put on a USB stick or a spare CD-ROm, the installation will happily proceed. Enough for you? :) -- 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: DFSG violations in Lenny: Summarizing the choices
Theodore Tso <[EMAIL PROTECTED]> wrote: > Another consequence of making it easy for the users to add non-free to > the repositories so they can download firmware necessary to make their > hardware useful is that a huge number of users may end up enabling > non-free just to make their hardware work, and then they may end up > installing even more non-free packages on their system. This is actually true for me. I would like to keep away non-free software from my system, but I also want to receive updates for the package firmware-iwlwifi, so I have to add the non-free section. For me firmware is just something different and it might be a good thing to have a seperate section for that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: new proposal
On Mon, 2008-11-10 at 16:25 -0600, Manoj Srivastava wrote: [...] > ,[ Proposal 2: allow Lenny to release with proprietary firmware ] [...] > | 4. We give priority to the timely release of Lenny over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware as part of > | Debian Lenny as long as we are legally allowed to do so. > | > | (Since this option overrides the SC, I believe it would require 3:1 > | majority) > ` [...] > ,[ Proposal 5: allow Lenny to release with firmware blobs ] > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); [...] > | 4. We give priority to the timely release of Lenny over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware as part of > | Debian Lenny as long as we are legally allowed to do so, and the > | firmware is distributed upstream under a license that complies > | with the DFSG. > ` [...] So far as I can see, the only significant difference between #5 and #2 (or #3) is the requirement that upstream distributes "under a license that complies with the DFSG". But it is surely irrelevant whether the licence text says we can modify the source when the copyright holder is deliberately withholding the source. (Further, in some cases the licence is GPLv2 which requires us to redistribute the source we don't have - though thankfully there are only 1 or 2 such cases left.) So why do you claim that #2 and #3 override the SC but #5 doesn't? Ben. signature.asc Description: This is a digitally signed message part
Re: screenshots.debian.net goes beta
On Tue, 2008-11-11 at 00:20 +0900, Paul Wise wrote: > On Tue, Nov 11, 2008 at 12:11 AM, Stefano Zacchiroli <[EMAIL PROTECTED]> > wrote: > > > - You state that screenshot will be released under the same term of > > the screenshot-ed package, why so? It seems to me rather arbitrary > > and makes impossible to bundle all screenshot together on a media > > and distribute them under a consistent license. > > > > Suggestion: just name a license and stick to it. > > screenshots are derivative works (according to SPI legal counsel): > > http://lists.debian.org/debian-legal/2008/08/msg00016.html And yet reviewers don't ask for permission to make screenshots, but seem to be comfortable with assuming that this is fair use. Ben. signature.asc Description: This is a digitally signed message part
Re: Announcement: Debian Pure Blends news
Andreas Tille wrote: > Your remark above just ignores that the concept tries to profit from > synergies inside these projects which for instance are reflected in > these tasks or bugs pages, a common technique to build metapackages etc. that's not my point; my point is that i don't see why a bunch of teams in Debian that make use of a common set ot tools/technics/$whatever should, just because of the fact that they use this common set, be carrying a special and confusing *different* name than the other teams terminology does. or in other words: probably every team is using/sharing some piece of tools/technics/$whatever with another team or that another team uses too - overlapping is always good and often happens. so why make some teams special and name them different? > If we now would be able to continue *working* for the concept and > stop spending time criticising the name itself (the time for this is > over as I tried to explain) or the renaming process in general which > is definitely a waste of time I would be really happy. again no offence intendet, but this is why this comes up all the time: you discuss something on your sub-project internal mailinglist that nobody else except sub-project members reads, then you guys decide on something, and present the result on d-d-a. since the topic is far broader and covers more people than just the already existing sub-projects, all other people do feel the need to discuss this as *they* see it the first time (through the d-d-a posting). the excact same situation happened when you announced 'dish' at debconf. to avoid such things, especially with defining naming terminology for things that covers such broad aspects of debian, a poll on your sub-project only mailinglists is probably not enough, and imho at least one of either d-devel or d-project should be CC'ed too to get peoples awareness *in the first place* and right at the beginning of the decission making, and not at the end. Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Debian Pure Blends news
On Tue, 11 Nov 2008, Daniel Baumann wrote:
to avoid such things, especially with defining naming terminology for
things that covers such broad aspects of debian, a poll on your
sub-project only mailinglists is probably not enough, and imho at least
one of either d-devel or d-project should be CC'ed too to get peoples
awareness *in the first place* and right at the beginning of the
decission making, and not at the end.
Ahh, OK - got the point. I do not assume that another renaming process
will be done any time soon - but if something else happens that might
interest more people I might consider CCing debian-{devel,project}. I
just hesitated to CC more than 6 lists (these were clearly related) and
I'm afraid that other people would have considered this kind of mails
as spam, but perhaps it makes sense to reach even more people.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
canonical list of port-specific CPP symbols
Hi, Is there a canonical list of symbols defined by each of the Debian architectures, e.g. do I test for Sparc using __sparc or __sparc__ ? How about m68k, hppa, etc? My first guess was that would be contained on http://ports.debian.org/ but no such luck. Thanks, -Steve signature.asc Description: Digital signature
Re: For those who care about bts-link: call for adoption
Quoting Pierre Habouzit ([EMAIL PROTECTED]): > Hi, > > As some of you may know, I've been the original creator of bts-link[0]. > Though, I have currently neither the motivation, nor the time to > maintain it, or run it on a regular basis[1]. > > I believe bts-link has become an important piece of our infrastructure, > especially for packagers with huge user base, but not only. This is why > it's more than time that I give bts-link to people that have the time to > care about the beast. Instead of doing huge threads cutting hairs in four pieces about whatever vote we should have in order to be sure not releasing lenny in the upcoming year, isn't there *really* someone in the crowd who would volunteer to maintain bts-link? As a package maintainer with a few upstreams having their own bugzilla (more particularly samba), bts-link has been an incredibly useful tool for me. Everybody know that *I* am personnally completely unable to maintain such beast but I know there are certainly many people among DD who can. So, pretty please, someone volunteer. Maintaining bts-link even deserves abandoning some package maintainance or whatever. We really need it. I think that the proposal made by Christoph Berg is, as of now, the most reasonable. Maybe it could be discussed during the upcoming Extremadura session (Nov 26-30) which is meant to be, among other, a QA session ? Actually, it could be a good idea for you to attend, Pierrebut for what I know of your usual schedule, that might be hard to arrange. signature.asc Description: Digital signature
