Re: Criticité d'un bug pour slapd ?
Je me posais la question de la criticité d'un tel bug. J'aurais tendance à penser que c'est critique : serveur qui s'arrête sans raison. Non, sûrement pas critical: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. Là, c'est le logiciel lui même qui se casse. Il n'y a pas perte de données et pas de compromission du système. Pas grave non plus: grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. Le paquet est utilisable et la faille de sécurité ne donne pas accès aux comptes des utilisateurs. serious is a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. Là, on commence à s'approcher. Cela dit, il n'y a pas violation de la policyet le bogue doit rendre le paquet non publiable, A L'AVIS DU MAINTENEUR. Je prendrais personnellement important: important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Et j'ajouterais le tag security puisqu'il y a un déni de service potentiel. Cela va attirer l'attention de la Security Team qui pourra apporter son avis. Il est important d'éviter de surestimer la criticité des bogues et de faire confiance aux mainteneurs pour l'augmenter si nécessaire. Par expérience, de nombreux responsables de paquets n'aiment pas trop les bogues surévalués.
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? When you do feel annoyed by me, why do you still reply to my mails? Trolling attitude of yours... -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
Ingo Juergensmann [EMAIL PROTECTED] wrote: On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? When you do feel annoyed by me, why do you still reply to my mails? Trolling attitude of yours... I believe Steve's volunteer work to be worth more than your volunteer work. Now, you're welcome to point out that I'm guilty of hypocrisy here, since I complained about your abuse of volunteers. But you've done so while continuing to expect them to provide you with useful services, whereas I expect nothing useful from you whatsoever. There is a line at which someone who is volunteering their time and effor is doing so in such a way that they take up more of other people's time than they save. You've crossed that line, and you show no signs whatsoever of wanting to get back on the correct side of it. As a project, Debian owes you nothing. If you're not going to make a sufficiently useful contribution to outweigh your character flaws, then it's better for you to make no contribution whatsoever. Unless you're a FPAV fan, please don't Cc: me. -- Matthew Garrett | [EMAIL PROTECTED]
Re: RunDinstallHourly
On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote: Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? I've talked about this with James Troup before. He seemed pretty receptive to speeding it up to something like twice a day, didn't seem to feel it would hit the mirrors much worse. It's possible he may still be waiting on SCC splitting up the base set of arches or the like before revisiting this. Who's SCC? If there's no technical *requirement* for this to happen first, we should go ahead with speeding up this up, precisely because it's such a good time to test its effects, both positive and negative. (Positive effects won't be so noticable right after Sarge releases) I'm assuming it would be a really easy change to revert if it has negative effects. (BTW, please note that when I or this proposal talks about the dinstall run, we're using the circa 1998 definition that includes mirror sync. The dinstall program itself aready runs every 15 minutes.) Twice daily seems more reasonable to me than hourly; Why? If you run it only twice daily, then the developers who are awake at one run will probably be asleep at the next, so there's still essentially a whole day's lapse before a developer can fix anything. I'd say a minimum of 4 times a day lets a developer see the result of his changes before the next time he goes to sleep. But the attraction of hourly is that a developer can see feedback from his changes within a couple of hours, and a developer may be able to clean up any bugs people noticed in the same sitting that he introduced them. for release purposes, another factor is how often britney runs, since that's what triggers changes in the testing suite. Doubling the frequency of britney runs seems reasonable to me, but hourly would surely be overkill considering we would still want to keep the waiting periods as they are now. The concept of RunDinstallHourly was supposed to be a more unstable-oriented approach. Anthony Towns has been playing with the testing scripts this week, giving the release team the ability to do by-hand runs of britney now. This gives us more flexibility in catching our own oversights that would otherwise push bits of testing improvements back by 24 hours at a time. This has already directly contributed to getting KDE 3.3 into testing as soon as we did -- if the dip in the sarge RC bug count is any indication, this looks like a step in the right direction. -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 06:39:23AM +, Matthew Garrett wrote: Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? When you do feel annoyed by me, why do you still reply to my mails? Trolling attitude of yours... I believe Steve's volunteer work to be worth more than your volunteer work. Now, you're welcome to point out that I'm guilty of hypocrisy here, since I complained about your abuse of volunteers. But you've done so while continuing to expect them to provide you with useful services, whereas I expect nothing useful from you whatsoever. I haven't said that he hasn't done more work than I. I just wanted to point out that this kind of game is childish. Well, if you want to play at that level, do it yourself. There is a line at which someone who is volunteering their time and effor is doing so in such a way that they take up more of other people's time than they save. You've crossed that line, and you show no signs So why you wasting more and more time with me than? whatsoever of wanting to get back on the correct side of it. As a Who decides what the correct side is? You? That's only viable for your business. Maybe you should read a Rosa Luxembur cite and respect the different opinion of other people instead of flaming them? Criticize my work in a proper way, if you like (or being able to). But going for a witch hunt should be under your level, eh? ;) project, Debian owes you nothing. If you're not going to make a sufficiently useful contribution to outweigh your character flaws, then it's better for you to make no contribution whatsoever. So, you say: Debian don't want contribution of people that other people don't like. Interesting. Unless you're a FPAV fan, please don't Cc: me. I just press g to reply to list mails. Other people (like Steve) are capable of configuring their MUAs in that way that they don't get CCs. Maybe you doing something wrong then? Please ask those people how you can rid off of off-list CC replies. -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 07:30:32AM +0100, Ingo Juergensmann wrote: On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? I said nothing of my own volunteer work, which pales in comparison to that of many. Nor was I making any judgement about the relative worth of your volunteer contributions compared to those of anyone else -- only about the historically destructive effect of your mailing list contributions, which offset the value of an awful lot of volunteer hours, and more yet if I allow myself to be dragged down by them. The us versus them pitting of volunteer contributions against each other appears to be your game alone, and is precisely the sort of thing that led me to killfile you in the first place. But it's a new year, and you have a new email address, and I'm an eternal optimist -- so as it seems to be on-point for this thread, I ask you instead of assuming: is there any hope that you'll participate constructively in the project lists in the year to come, or are you still so twisted up inside over past slights, real or perceived, that you refuse to treat developers such as James Troup, who has indeed contributed countless hours to Debian over the years, with a minimum of respect and human decency? If all you have to contribute for this year is more harping about Debian's deficiencies and issuing of ultimatums, then I might at least save myself the time of reading, don't you think? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: [volatile] status update
On Friday 24 December 2004 11.01, Steinar H. Gunderson wrote: On Thu, Dec 23, 2004 at 09:21:08PM -0500, William Ballard wrote: I was trying to think of a word for news you need to know now and will not be of much use to you in the far future. debian-devel? :-P No, that's news you don't really need to know now but which will be useful in flamewars in the future. -- vbi -- Any program that runs right is obsolete. pgpl34C7b4JfK.pgp Description: PGP signature
Re: ITP reminder emails
On Thursday 30 December 2004 10.07, Maciej Dems wrote: please notify, that many ITPs are done by non-DDs. In this case the main reason for their inactivity is the lack of a sponsor. IMHO for such ITPs, the RFS should be cc:ed to the bug, so anybody reviewing the ITP would see that it's not been dropped by the ITPer (... and, probably, thus the ITP wouldn't reach the 4 month threshold. Hopefully.) -- vbi -- Das Bedrfnis, zu Klumpen geballt herumzujubeln, ist in Berlin nicht tot zu kriegen. -- Wiglaf Droste pgpPQK0RNG7aZ.pgp Description: PGP signature
Re: Bug#287839: ITP: mxml -- small XML parsing library
hoi :) On Mon, Jan 03, 2005 at 09:13:54AM -0200, Eduardo Marcel Macan wrote: I know the basics of XML and don't really have any experience using XML libraries myself, I'm packaging it because zynaddsubfx uses it to implement an xml-like instrument definition, and zyn is one of my main interests. so when you only want zyn to work perhaps it's better to modify it to use libxml2 (you already described that the library APIs is very similar) than to introduce a new library which is only used by one package. -- Martin Waitz signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 12:06:53AM -0800, Steve Langasek wrote: Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? I said nothing of my own volunteer work, which pales in comparison to that of many. Nor was I making any judgement about the relative worth of your volunteer contributions compared to those of anyone else -- only about the historically destructive effect of your mailing list contributions, which Ah, ML contributions... misunderstanding then... :) offset the value of an awful lot of volunteer hours, and more yet if I allow myself to be dragged down by them. Yes, that's what I'm wondering about. :) The us versus them pitting of volunteer contributions against each other appears to be your game alone, and is precisely the sort of thing that led me to killfile you in the first place. Ohno, it's not my game, trust me. I've better things to do than playing such a game. Maybe I'm the one who complains most loudly, but there are DDs that agree with me in some (sometimes most or all) points, although they're not happy about my loudness (which is ok and can be questioned). But it's a new year, and you have a new email address, and I'm an eternal optimist -- so as it seems to be on-point for this thread, I ask you instead of assuming: is there any hope that you'll participate constructively in the project lists in the year to come, or are you still so twisted up inside over past slights, real or perceived, that you refuse to treat developers such as James Troup, who has indeed contributed countless hours to Debian over the years, with a minimum of respect and human decency? If all you have to contribute for this year is more harping about Debian's deficiencies and issuing of ultimatums, then I might at least save myself the time of reading, don't you think? Ah, that's a level of discussion I usually prefer. Thx. So, of course there's always hope. Usually I respond in the same way on lists as the message I'm responding to. Of course I know that one shouldn't be dragged down and be better and more polite than the others, but as you know yourself (see above) that's not always that simple. If a discussion on the list is going on in a proper way (that is staying on-topic, polite and problem and solution orientated) I'll try my best to join and contribute in the same way. Regarding James Troup... well, I still believe that he's a smart and nice person in RL. Never had any problems with that. But I ask you (and other) to respect my opinion about his Debian role as I respect and understand your opinion that is contrary to mine. I still believe that it would be better for the project when he would retire from some of his many positions, because he's too loaded with them. You may or may not agree with me on that point, but nobody is allowed to forbid me the freedom of speech to express my opinion. Questions answered? -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 06:54:51PM -0500, William Ballard wrote: On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. I started using Linux (and Debian) a couple months after Woody came out. Was woody due any day now for a year like this? To a large extent, yes. -- Colin Watson [EMAIL PROTECTED]
installing developer environ
hi, what is the apt-get package i can install for the entire developer environment ? I am building some DBD packages, but findthe stdinclude files, etc missing. -Sukhdeep
Re: installing developer environ
Sukhdeep Johar [EMAIL PROTECTED] writes: what is the apt-get package i can install for the entire developer environment ? I am building some DBD packages, but find the std include files, etc missing. Have a look at build-essential, which is documented in Debian Policy section 4.2. Cheers, Benjamin -- .''`. ; ;' ; Debian GNU/Linux | Benjamin Drieu `. `'http://www.debian.org/ | [EMAIL PROTECTED] `- pgp8YUDxq8gBf.pgp Description: PGP signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 11:16:44PM -0800, Ken Bloom wrote: On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: Twice daily seems more reasonable to me than hourly; Why? If you run it only twice daily, then the developers who are awake at one run will probably be asleep at the next, so there's still essentially a whole day's lapse before a developer can fix anything. I'd say a minimum of 4 times a day lets a developer see the result of his changes before the next time he goes to sleep. But the attraction of hourly is that a developer can see feedback from his changes within a couple of hours, and a developer may be able to clean up any bugs people noticed in the same sitting that he introduced them. I don't know about you, but I'm usually awake for at least 16 hours at a time, which gives me a 1 in 3 chance of being awake for both dinstall runs if the timing is random, and probably higher than that if the timing is optimum. But I'm not sure why I would care about being awake through both of them anyway; one of the immediate benefits of having two dinstalls a day is that everyone would be awake to see at least *one* of them, which isn't the case today. Being able to work through one dinstall in a given day is enough to let a developer upload, wait for feedback, and fix -- they wouldn't be able to see the results of the *fixes* until the next day, but if they don't know if they've fixed the bug, they bloody well shouldn't be uploading another package to the archive and stressing the autobuilder network: that developer needs improved quality assurance practices, not more frequent dinstall runs. :P And it's not like users want more frequent updates, either. Once a day is plenty often to be fiddling with apt-get; many sid users don't update nearly that often, after all. The exception is when something breaks, and you need a fix yesterday, in which case you don't want to wait for the fix to be apt-gettable from your mirror anyway: you grab it from incoming, or get a test deb from the maintainer before he's uploaded, if it's that important. Hourly dinstalls aren't going to improve on the usability of this when the mirror pulse is likely to take at least an hour to reach the edges. There are really very few concrete benefits I can see to increasing the dinstall frequency, but one in particular is to speed up debian-installer testing. Most other bugs don't require a full dinstall cycle to give people a good idea whether they've been fixed, but the installer builds out of the archive, which means that verifying the fixes for certain bugs *does* require a dinstall pulse followed by a d-i and CD build. So stepping this up to a higher frequency than once a day can help here, but stepping it up so that dinstalls happen more frequently than CD builds can be completed does not. for release purposes, another factor is how often britney runs, since that's what triggers changes in the testing suite. Doubling the frequency of britney runs seems reasonable to me, but hourly would surely be overkill considering we would still want to keep the waiting periods as they are now. The concept of RunDinstallHourly was supposed to be a more unstable-oriented approach. - testing changes are clocked by the same mirror pulse as unstable - if this is supposed to be a change that helps the release, it is important to consider the effect it will or won't have on testing, since that's the suite that's actually used for staging stable -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#53121: Online Pharmazx
Would you like inexpensive Pain Killers? http://attn.neata.com
RFS tag?
Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred
Bug#288703: ITP: chmsee -- A chm file viewer, support Chinese better
Package: wnpp Severity: wishlist * Package name: chmsee Version : 0.9.0 Upstream Author : wa chung [EMAIL PROTECTED] * URL : http://linuxfire.dhis.org/~zhong/ * License : GPL Description : A chm file viewer, support Chinese better chmsee is a viewer for Compiled HTML Help (CHM) files. It, can show the contents tree if one is available, add bookmarks, search and set encoding. What it cannot do is handle Javascript by the book. I have maintained it for some time and put the packages in http://debian.ustc.edu.cn/debian-uo/dists/sid/ustc/pool/chmsee/ (maybe this URI can't visit outside mainland China) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-2-686-smp Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) -- Li Daobing
Re: LCC and blobs
* Matthew Garrett | You have argued that drivers don't really depend on firmware, but | instead depend on the hardware expressing the correct interface. As an | example, we can compare maria-vis, which depends on the graphviz | package. maria-vis is in contrib, because it depends on graphviz, which | is in non-free. But by your argument, it doesn't actually depend on | graphviz - it merely depends on something that presents a correctly | functioning graphviz interface. This could be a piece of non-free code, | but it could also be a piece of free code, an interface to a remote | application server, or a userspace application to drive hardware that | kicks intelligent rodents until they draw the correct graph. There's no | intrinsic dependency on the non-free code. But since the non-free code | is currently the only solution that /does/ express the correct | interface, there exists a dependency on non-free code. However, if somebody writes a graphviz-client which just pushes the dot file over the network to graphviz.example.com on some port and gets a postscript file back, it can go into main. No matter what software said server is running. Correct? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 8:42 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: Regarding James Troup... [...] I still believe that it would be better for the project when he would retire from some of his many positions, because he's too loaded with them. I'm assuming you haven't spotted the recent announcement that he now has assistance with much of the day-to-day work of one of those positions? (iirc, the one you're most fond of complaining about). [fwiw, if I understand correctly, the person in question was appointed after having spent considerable time contributing to the NM process and asking can I help lighten your workload?, as opposed to I don't think you're doing a good enough job, let me do it]. Cheers, Adam
Re: New stable version after Sarge
On Jan 04, Matthew Garrett [EMAIL PROTECTED] wrote: It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? A very simple way would be to make them believe that this is true, and this is going to be hard if it's not. Let's try a different approach: everybody should ask himself is something I am doing or not doing holding the release?. And after fixing his own work then ask who is left doing or not something which is holding the release?, and start pointing fingers. (Pointing fingers may not help speeding up the release, but will be an useful distraction while we wait.) -- ciao, Marco signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems?
* Ingo Juergensmann | Unless you're a FPAV fan, please don't Cc: me. | | I just press g to reply to list mails. Other people (like Steve) | are capable of configuring their MUAs in that way that they don't | get CCs. Maybe you doing something wrong then? Please ask those | people how you can rid off of off-list CC replies. You are the one violating the Debian Mailing List Guidelines here, not Matthew. See http://www.debian.org/MailingLists/#codeofconduct -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
* Ingo Juergensmann ([EMAIL PROTECTED]) [050105 07:35]: On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? So you decided to play a my volunteer work is worth more than your volunteer work game? When you do feel annoyed by me, why do you still reply to my mails? Trolling attitude of yours... I don't understand why you try to make as many developers opposed to you as possible. For me, Steve is an very easy to work with developers, and he doesn't flame easily, so you should ask yourself what mistake you made. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 09:42:00AM -, Adam D. Barratt wrote: On Wednesday, January 05, 2005 8:42 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: Regarding James Troup... [...] I still believe that it would be better for the project when he would retire from some of his many positions, because he's too loaded with them. I'm assuming you haven't spotted the recent announcement that he now has assistance with much of the day-to-day work of one of those positions? (iirc, the one you're most fond of complaining about). Of course I have. And of course that's an important improvement, but not a real solution for the problem, IMHO. [fwiw, if I understand correctly, the person in question was appointed after having spent considerable time contributing to the NM process and asking can I help lighten your workload?, as opposed to I don't think you're doing a good enough job, let me do it]. To cite Joey: Go and read the archives - or to say it clearly: over a year ago I (and others) asked, too, how the workload can be lightened on him. No answers, no solutions. There was a long why from hey, how can we or someone else help you with your work? to this guy is overloaded with work and should retire from that position. When Joerg Jaspert is already doing the dirty daily work, why does James still needs in place then? (Except he just stays in that position for a transitional period until Joerg is taking over that task and job completely. I would recommend that transitional period for other positions as well.) And I would welcome it when in 2-3 years another person would be introduced into that position, first as a helping hand and than to replace Joerg after a transitional period, too... -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wednesday, January 05, 2005 10:05 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: [...] When Joerg Jaspert is already doing the dirty daily work, why does James still needs in place then? (Except he just stays in that position for a transitional period until Joerg is taking over that task and job completely. I would recommend that transitional period for other positions as well.) aiui, because James - or presumably some other member of -admin - needs to create the accounts once an nm has been approved (newsamosa, aka db.d.o is restricted). The most time-consuming part of DAM work is approving applicatants, which is what Joerg is now doing. afaics, once an applicant is approved, accounts are being created relatively quickly; so far it appears to be working well. Cheers, Adam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 10:59:31AM +0100, Andreas Barth wrote: I don't understand why you try to make as many developers opposed to you as possible. I don't try it, it's not my intention, but I say what I mean and think. Of course this is sometimes not the same with what the audience might want to hear. That's sad, but it's fair-minded and is more straightforward than to play to someone else, I think. For me, Steve is an very easy to work with developers, and he doesn't flame easily, so you should ask yourself what mistake you made. As already said several times: I usually respond in the same way you approach me. And especially you should know that you can discuss serious issues (be it technical or not) with me at the same time when we have a different opinion on other topics. I usually distinguish between factual discussions and flamefests/ad hominem attacks. Or do you have the impression that I haven't treated you correctly when you had questions or problems with the buildd status updates for example? -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: Accepted mozilla 2:1.7.5-1 (i386 source)
Hi, Am Mittwoch, 5. Januar 2005 11:02 schrieb Takuo KITAME: mozilla (2:1.7.5-1) unstable; urgency=high . * New upstream release (closes: Bug#288047,Bug#288044,Bug#287111, Bug#277515) ARGS. Two of those bugs at least are *NOT* new upstream release type bugs. Is it really to hard to write sensible changeslog which actually say *what* was fixed (needed for looking offline when needed...) Is it too hard to e.g. write?: * New upstream release: (closes: #...) - fixes NNTP security problem (closes: #...) - fixes this (closes: #...) - now foo is done (closes: ##...) [...] Regards, Rene -- .''`. Ren Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: New stable version after Sarge
In article [EMAIL PROTECTED], Otto Wyss [EMAIL PROTECTED] wrote: Stopping releasing might be a good idea but there should be a better way. IMO the problem is the stable release isn't updated on a regulare basis. It might be a better idea to divide Debian into subsystems which could be released much faster when needed. I agree with this. Traditional OS vendors also release the OS and the applications seperately, seems to work better.. Mike.
build problem on mips{,el}
hoi :) my package tspc could not be build on mips and I don't know why: /usr/bin/ld: cannot open output file ../../bin/tspc: Permission denied The package builds correctly on all other architectures. Any ideas? -- Martin Waitz signature.asc Description: Digital signature
Re: New stable version after Sarge
Marcelo E. Magallon wrote: [...] [0] Besides learning that there is still people in this world who seem to think that feminism is actually a solution to something. I am still amazed by that one. Thankyou for reminding us all, by demonstration, that the problems feminism tries to solve still exist within Debian :) I suspect that you are using a very narrow definition of feminism here. Your comment is insulting to people who are working to fix such problems as sexist language in Debian webpages and sexist behaviour on Debian IRC channels, let alone the more subtle and complex things that some of us, who identify as feminists, are trying to achieve. However I believe your comment is more likely to have been made in ignorance than with malice. If you are interested instead in helping us to solve some of the problems women face in their involvement with Debian (with associated benefits for Debian) drop by the Debian Women project someday and ask us what we are really doing. You are invited to be part of the solution... Helen.
Re: build problem on mips{,el}
On Wed, Jan 05, 2005 at 11:40:14AM +0100, Martin Waitz wrote: my package tspc could not be build on mips and I don't know why: /usr/bin/ld: cannot open output file ../../bin/tspc: Permission denied The package builds correctly on all other architectures. Any ideas? mips* do not use fakeroot as the root command when building, because fakeroot does not work on these architectures. Instead they must use sudo, which means that directories or files created in the clean target will not be writable by the build target. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Accepted mozilla 2:1.7.5-1 (i386 source)
Hi! Rene Engelhard [2005-01-05 11:26 +0100]: mozilla (2:1.7.5-1) unstable; urgency=high . * New upstream release (closes: Bug#288047,Bug#288044,Bug#287111, Bug#277515) ARGS. Two of those bugs at least are *NOT* new upstream release type bugs. Is it really to hard to write sensible changeslog which actually say *what* was fixed (needed for looking offline when needed...) Is it too hard to e.g. write?: * New upstream release: (closes: #...) - fixes NNTP security problem (closes: #...) - fixes this (closes: #...) - now foo is done (closes: ##...) [...] Please also always include a CAN number if available (which was the case here). With this changelog it is impossible to track security fixes. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 09:42:52AM +0100, Ingo Juergensmann wrote: On Wed, Jan 05, 2005 at 12:06:53AM -0800, Steve Langasek wrote: The us versus them pitting of volunteer contributions against each other appears to be your game alone, and is precisely the sort of thing that led me to killfile you in the first place. Ohno, it's not my game, trust me. I've better things to do than playing such a game. Maybe I'm the one who complains most loudly, but there are DDs that agree with me in some (sometimes most or all) points, Yes, there are always 'DDs' who agree with 'some' of your points. Yet, you're the only one people consistently dislike. I've tried to defend you for some time, because I thought your past help to the m68k port should not have gone unnoticed. I stopped doing so when I realised your conduct does not deserve defence. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
Jan Niehusmann wrote: Unfortunately, testing does not guarantee security updates. Of course given the security+woody tagged RC bugs #237422, #246443, #274225, #278625, #278942, #284031, #192732, #196590, #198567, #199351, #202244, #223456, #244810, #244811, #250106, #260508, #260838, #268783, #273377, #279680, #279726, #279870, #280883, #281665, #281922, perhaps stable doesn't either. All of those bugs are 1 month old and fixed in sarge. I think we've taken this security bugs arn't fixed in testing as well as in stable thing as gospel a little too long without verifying it lately. I've been checking and if testing is lagging stable at all, it's doing so by a much smaller amount than we've traditionally thought. It's not even lagging unstable too badly lately aside from kde, which was just resolved. And we do have the testing security team trying to work on improving it too. -- see shy jo signature.asc Description: Digital signature
Re: For people more knowledgeable about buildds...
On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote: Also, what is involved with putting a package back into the Needs-Build state (i.e. requeueing it)? The buildd maintainer replying to a log or running 'wanna-build' manually. With complaints about the lack of response/response times from emails to [EMAIL PROTECTED], I was just wondering if it was feasible to have an email gateway like db.debian.org has for rescheduling failed builds? I presume the majority of emails sent to [EMAIL PROTECTED] are requests for requeuing? Mostly, yes (and many of them are either bogus or superfluous, but that's a different matter). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: RFS tag?
On Wednesday 05 January 2005 09:50, Nico Golde wrote: Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. As a person looking for sponsors from time to time, I second this. B/R, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Re: Maintainer needed
On Tue, Jan 04, 2005 at 08:42:07PM +0100, Giuseppe Scrivano wrote: Hi, First of all I am not a debian developer, so I always need a sponsor to upload it, and I think that the package is not yet perfect. Maybe an expert person can handle it better. The first role of a sponsor is to check the quality of your package, discuss it with you, and to help you improve it. The uploading bit is just a final stage. If you are interested in having this in Debian, the best way to go at it is to find a sponsor. An RFP might work, but chances that it will are very slim. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 12:15:43PM +0100, Wouter Verhelst wrote: Ohno, it's not my game, trust me. I've better things to do than playing such a game. Maybe I'm the one who complains most loudly, but there are DDs that agree with me in some (sometimes most or all) points, Yes, there are always 'DDs' who agree with 'some' of your points. Yet, you're the only one people consistently dislike. Too much honor to me being the only one. How about Adrian Bunk, Herbert Xu and others? I even see publicly expressed dislikes against Sven Luther - funny enough by people that are disliked by many others themselves. I've tried to defend you for some time, because I thought your past help to the m68k port should not have gone unnoticed. I stopped doing so when I realised your conduct does not deserve defence. And now you joined the other side? Attacking instead of defending? Does that help the m68k port better? I doubt that seriously. -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: RunDinstallHourly
Steve Langasek wrote: Twice daily seems more reasonable to me than hourly; for release purposes, another factor is how often britney runs, since that's what triggers changes in the testing suite. Doubling the frequency of britney runs seems reasonable to me, but hourly would surely be overkill considering we would still want to keep the waiting periods as they are now. All of the benefits I've thought of from running dinstall more often really only apply to unstable package churn issues. Running britney more often sounds relatively orthagonal actually, though it does sound useful for those annoying transitions. -- see shy jo signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 01:06:49PM +0100, Ingo Juergensmann wrote: On Wed, Jan 05, 2005 at 12:15:43PM +0100, Wouter Verhelst wrote: I've tried to defend you for some time, because I thought your past help to the m68k port should not have gone unnoticed. I stopped doing so when I realised your conduct does not deserve defence. And now you joined the other side? Attacking instead of defending? Does that help the m68k port better? I doubt that seriously. I'm not attacking anyone. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. I guess one man's meat is another man's poison. Since I administer a large number of distant computers I view the long time between stable releases as a feature not a bug. What about saying something like: the next stable release comes in the beginning of 2006? Once a year works for me, but any more frequent would be a pain in the neck. Frankly a release every 18 months seems about right. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. Also the concept of releases when it's ready seems to be a little contrived. When *what* is ready exactly? The current system of defining a release seems to involve identifying a number is arbitrarily characteristics that will define the new version. The release occurs when they are complete and the RC bug list is low. Perhaps a date based release mechanism could be built using a new distribution, call it prestable. Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. So a package follows the following path: unstable -- testing -- prestable --(approx. 12 months)-- stable People running servers (like myself) will stick with stable. Those wanting a reasonably stable system but want the latest features run prestable. Those wanting the very latest but don't care about RC bugs run testing. Developers normally run unstable. In some ways prestable would resemble the current stable when the release manager has begun freezing it. Of course one would not want prestable to be released with critical components missing. To prevent such a thing a number of packages are identified as release essential (RE). Every RE package has to have migrated from testing to prestable for the annual release to take place. Any non-RE packages with RC bugs at release time simply do not make it into the stable release for that year. If it looks like a critical package will be ommited the release manager can always make that package RE. Although the target is for an annual release to occur, the proposed mechanism also permits the project to identify a set of features for the new release. For example, had prestable existed for 3.1 the new installer would have been listed as RE. So ... Debian would still release when its ready but everyone has a better idea of what ready means simply by looking at the RE package list. Steve
Re: RunDinstallHourly
On Wed, Jan 05, 2005 at 07:12:34AM -0500, Joey Hess wrote: All of the benefits I've thought of from running dinstall more often really only apply to unstable package churn issues. Running britney more often sounds relatively orthagonal actually, though it does sound useful for those annoying transitions. not really important right now, but anyway: britney's time-complexity in regards to the number of packages she has to work on is really bad, son in the long run it might pay off to run britney more often and on a smaller number of packages each time. cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 01:11:49PM +0100, Wouter Verhelst wrote: And now you joined the other side? Attacking instead of defending? Does that help the m68k port better? I doubt that seriously. I'm not attacking anyone. Usually this is what attackers believe. The attacked party feels different in most cases. -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
New author/maintainer for pinfo needed
Hi, I've so far maintained the package pinfo, an alternative info-file viewer. The last release has been some time ago and there are also some open bug reports. I've talked with the author about the package and he decided that he has no longer time to work on this package. Therefor the program needs a new author to be viable in the future. Ideally the new author is also a debian developer or in the new maintainer queue and would take the package over. If nobody is interested in becoming the author of pinfo, I'm going to orphan the package in a week. Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgphZQOcX31R1.pgp Description: PGP signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 04:16:49AM -0800, Stephen Birch wrote: Perhaps a date based release mechanism could be built using a new distribution, call it prestable. Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. That's how testing started off. We stopped doing this because a) it at one point stalled glibc; as a result, nothing moved to testing anymore, and when it finally did, the changes were so dramatic that testing was broken for quite some time. b) Some RC bugs are only discovered when they migrate to testing. If the promise of 'prestable' would be that it would contain NO RC BUGS, then we would have to throw those out. That would likely result in prestable being a very incomplete system. Also, adding yet another distribution that is even harder to update than testing is doesn't seem like a good idea to me. We're already having issues with testing and security; $DEITY forbid that we would make it worse. (not being a member of the release team, the above isn't guaranteed to be right in all details; but I don't think I'm way off base here) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New author/maintainer for pinfo needed
Hi Christian! You wrote: I've so far maintained the package pinfo, an alternative info-file viewer. The last release has been some time ago and there are also some open bug reports. I've talked with the author about the package and he decided that he has no longer time to work on this package. Therefor the program needs a new author to be viable in the future. Ideally the new author is also a debian developer or in the new maintainer queue and would take the package over. If nobody is interested in becoming the author of pinfo, I'm going to orphan the package in a week. I do actually use it, so unless anyone else wants to take it, I'd be happy to take it over. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 08:28:59AM +0100, Ingo Juergensmann wrote: Unless you're a FPAV fan, please don't Cc: me. I just press g to reply to list mails. Other people (like Steve) are capable of configuring their MUAs in that way that they don't get CCs. Maybe you doing something wrong then? Please ask those people how you can rid off of off-list CC replies. This is incorrect. The proper way to respond to lists in Mutt (especially on Debian lists, where it's policy) is to add the lists to subscribe, and press L (list reply). -- Glenn Maynard
Re: Ignoring the truth or Hiding problems?
On Wed, Jan 05, 2005 at 10:34:33AM +0100, Tollef Fog Heen wrote: * Ingo Juergensmann | I just press g to reply to list mails. Other people (like Steve) | are capable of configuring their MUAs in that way that they don't | get CCs. Maybe you doing something wrong then? Please ask those | people how you can rid off of off-list CC replies. You are the one violating the Debian Mailing List Guidelines here, not Matthew. See http://www.debian.org/MailingLists/#codeofconduct While you're correct--Ingo should be using list-reply, not group-reply--it's also somewhat dubious to complain about receiving CC's on list mail when you havn't set up your MFT header to say you don't want them, list policy or no. (In other words, if he actually cares enough to complain about it, he should be able to set up your headers to say what he wants, too. It's a lot more time-effective, mail for mail, than trying to teach people how to use their MUA.) -- Glenn Maynard
Re: New stable version after Sarge
On Wed, 2005-01-05 at 10:45 +0100, Marco d'Itri wrote: On Jan 04, Matthew Garrett [EMAIL PROTECTED] wrote: It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? A very simple way would be to make them believe that this is true, and this is going to be hard if it's not. Let's try a different approach: everybody should ask himself is something I am doing or not doing holding the release?. And after fixing his own work then ask who is left doing or not something which is holding the release?, and start pointing fingers. (Pointing fingers may not help speeding up the release, but will be an useful distraction while we wait.) OK, exactly what are YOU NOT DOING, now? Come on, I know you CAN'T be that busy. You only maintain a few trivial packages... come on you could NMU the kernel-source-2.[4|6] fixing all th issues. To that extent, there is only a few hundred RC bugs. Me, You ask? I am already too busy to help out. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux P.S. Of course you hopefully realize, that this is a flippant remark. signature.asc Description: This is a digitally signed message part
Re: New stable version after Sarge
Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 13:46: That's how testing started off. We stopped doing this because a) it at one point stalled glibc; as a result, nothing moved to testing anymore, and when it finally did, the changes were so dramatic that testing was broken for quite some time. Hmmm .. I didnt know that testing was originally a non-RC distribution although I have heard of the glibc pain. b) Some RC bugs are only discovered when they migrate to testing. If the promise of 'prestable' would be that it would contain NO RC BUGS, then we would have to throw those out. That would likely result in prestable being a very incomplete system. ahh .. I take your point. What about the idea of identifying a list of release essential (RE) packages? Is that the mechanism actually used to determine the relase point when testing is frozen? Forgive me if I tread a well worn path, I was not involved with Debian when woody was released so this is my first experience with a release. Steve
Re: New stable version after Sarge
* Joey Hess: I think we've taken this security bugs arn't fixed in testing as well as in stable thing as gospel a little too long without verifying it lately. I've been checking and if testing is lagging stable at all, it's doing so by a much smaller amount than we've traditionally thought. I think that's because of the pending release, in particular frozen base packages, and not representative for the whole release cycle. If a switch to a new upstream version of libc runs into problems, testing and unstable will diverge again, maybe for weeks or months. testing-security intends to solve this, though.
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 05:12:57AM -0800, Stephen Birch wrote: Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 13:46: That's how testing started off. We stopped doing this because a) it at one point stalled glibc; as a result, nothing moved to testing anymore, and when it finally did, the changes were so dramatic that testing was broken for quite some time. Hmmm .. I didnt know that testing was originally a non-RC distribution although I have heard of the glibc pain. Again, I'm not entirely sure this is exactly what happened; but I am quite sure this is what /will/ happen if we go down that road. b) Some RC bugs are only discovered when they migrate to testing. If the promise of 'prestable' would be that it would contain NO RC BUGS, then we would have to throw those out. That would likely result in prestable being a very incomplete system. ahh .. I take your point. What about the idea of identifying a list of release essential (RE) packages? Is that the mechanism actually used to determine the relase point when testing is frozen? You should ask the release managers about that. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: New stable version after Sarge
Hi Stephen! You wrote: ahh .. I take your point. What about the idea of identifying a list of release essential (RE) packages? I like that idea. We could even have a system to automagically throw buggy non-RE packages out of testing. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Experimental gaim_1.1.1-2 for Alpha
I have built this package for alpha and it does indeed work. I have bundled it up in a tgz making it easier to D/L. But all the files are there as well for individual inspection. Along with the md5sums http://www.gregfolkert.net/experimental/ not an archive by any means, but available at your discretion. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
ISMSS DomIscanInt-ATN(169.202.3.81) has deleted a message. (D N)
The mail has an attachment not with in the Security policy CONTENT FILTER, Filter Type: Advanced Content Filter Event: at CanonKZN-Attachment-Warning.txt:CONTENT , message.zip violated Action on Attachment: STRIP ,has taken the following action against the message: Delete. ___ Important Notice: Authorised Financial Services Provider Important restrictions, qualifications and disclaimers (the Disclaimer) apply to this email. To read this click on the following address or copy into your Internet browser: http://www.absa.co.za/ABSA/EMail_Disclaimer The Disclaimer forms part of the content of this email in terms of section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you are unable to access the Disclaimer, send a blank e-mail to [EMAIL PROTECTED] and we will send you a copy of the Disclaimer.
Re: New stable version after Sarge
Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: You should ask the release managers about that. Wow!! You mean the decision process is not made public? I would have thought it would be out in the open for all to see. Mind you, Debian seems to be a hotbed of emotion at times so perhaps a less visible approach is necessary :-) Steve
Re: New stable version after Sarge
Bas Zoetekouw([EMAIL PROTECTED])@2005-01-05 14:31: I like that idea. We could even have a system to automagically throw buggy non-RE packages out of testing. That wouldn't be a bad idea at all. In the recent DPL interview: http://www.newsforge.com/article.pl?sid=04/12/23/2023223 Martin indicated that Debian now contains over 10,000 packages. That is HUGE. I would think some culling has to happen at some point either using bug counts or, as has been suggested, an analysis of popcon results. Or both. Although zero package usage would also result in zero bug reports ;-) Steve
Re: origins of the Debian logo
On Tue, Jan 04, 2005 at 11:31:58AM +0200, Fabian Fagerholm wrote: Sorry for the delayed response, but here is a possible answer to the second part of the question from a semiotic perspective. Although the question was what the swirl /tries/ to symbolize, it may be of some interest what it actually might have ended up symbolizing for some people. Fasten seatbelts, please. Some time ago I saw Toy Story for the first time and noticed that Buzz Lightyear has a symbol similar to the Debian swirl in his jaw. It can be seen in these pictures: http://www.bugkid.com/toystory/pictures/011.jpg http://allearsnet.com/tp/mk/buzz7.jpg Knowing the close relation between Debian and Toy Story, it seems likely this was a source of inspiration for the swirl artist. -- Niklas Vainio [EMAIL PROTECTED]
Re: Experimental gaim_1.1.1-2 for Alpha
On Wed, 2005-01-05 at 08:55 -0500, Greg Folkert wrote: I have built this package for alpha and it does indeed work. I have bundled it up in a tgz making it easier to D/L. But all the files are there as well for individual inspection. Along with the md5sums http://www.gregfolkert.net/experimental/ not an archive by any means, but available at your discretion. BTW, someone pointed out I didn't sign the .changes file... ummm oops. First real try at building the packages for general consumption. My bad. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Ignoring the truth or Hiding problems?
Le mercredi 05 janvier 2005 07:39 -0500, Glenn Maynard a crit : While you're correct--Ingo should be using list-reply, not group-reply--it's also somewhat dubious to complain about receiving CC's on list mail when you havn't set up your MFT header to say you don't want them, list policy or no. (In other words, if he actually cares enough to complain about it, he should be able to set up your headers to say what he wants, too. It's a lot more time-effective, mail for mail, than trying to teach people how to use their MUA.) Mail-Followup-To is not part of any of the standards defining e-mail protocols. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 08:11:44AM -0500, Greg Folkert wrote: OK, exactly what are YOU NOT DOING, now? Come on, I know you CAN'T be that busy. You only maintain a few trivial packages... come on you could NMU the kernel-source-2.[4|6] fixing all th issues. No need to MMU. The debian-kernel team is doing pretty regular uploads. Sending us diffs to fix bugs is of course highly welcome.
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote: Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: You should ask the release managers about that. Wow!! You mean the decision process is not made public? I would have thought it would be out in the open for all to see. No, I mean 'I dunno, but these are the people who probably will' ;-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: RFS tag?
* Nico Golde [Wed, 05 Jan 2005 09:50:42 +0100]: From: Nico Golde [EMAIL PROTECTED] To: [EMAIL PROTECTED] ^^ is there a reason for this? breaks mutt's 'L'ist-reply... Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. Justin Pryzby has been working lately on this. you may find this thread [1] on -mentors interesting. I particularly like and fully support jvw's suggestion [2] about the forwarded status. for a more-bloated proposal, also from Justin, see [3]. [1] http://lists.debian.org/debian-mentors/2005/01/msg00037.html [2] http://lists.debian.org/debian-mentors/2005/01/msg00038.html [3] http://lists.debian.org/debian-mentors/2005/01/msg00010.html hth, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Create a system that is usable even by idiots, and only idiots will use it.
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 08:02:25PM -0600, Steve Greenland wrote: On 02-Jan-05, 15:54 (CST), Stephan Niemz [EMAIL PROTECTED] wrote: By the way, is there a guide somewhere telling how to switch an unstable system from 2.4 to 2.6? apt-get install kernel-image-2.6.whatever Also module-init-tools. I got burnt by this recently when I modularised my kernel and was mystified that my network card had disappeared. -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems?
On Wed, Jan 05, 2005 at 03:12:14PM +0100, Josselin Mouette wrote: Le mercredi 05 janvier 2005 à 07:39 -0500, Glenn Maynard a écrit : While you're correct--Ingo should be using list-reply, not group-reply--it's also somewhat dubious to complain about receiving CC's on list mail when you havn't set up your MFT header to say you don't want them, list policy or no. (In other words, if he actually cares enough to complain about it, he should be able to set up your headers to say what he wants, too. It's a lot more time-effective, mail for mail, than trying to teach people how to use their MUA.) Mail-Followup-To is not part of any of the standards defining e-mail protocols. Which just goes to show how useless and irrelevant these purported standards are. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#288769: ITP: cedilla -- ascii to postscript renderer
Package: wnpp Severity: wishlist * Package name: cedilla Version : 0.5 Upstream Author : Juliusz Chroboczek * URL : http://www.pps.jussieu.fr/~jch/software/cedilla/ * License : GPL Description : ascii to postscript renderer with unicode support An ascii to postscript renderer written with the requirements of non-ascii text in mind. While other, older ascii renderers like a2ps apparently can not easily be adapted to output accented characters or non-latin scripts properly, cedilla was written with this requirement in mind from the start. (Look at 180236 for how this ITP came into being.) -- vbi -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (60, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Re: New stable version after Sarge
On Tuesday 04 January 2005 05:58 pm, Neil McGovern wrote: Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. My I ask, how did the attacker get root? Did the user have root access that was used to install phpbb, or was a local exploit used once the user's account was compromised? Josh
Re: RFS tag?
hi, * Frederik Dannemare [EMAIL PROTECTED] [2005-01-05 12:43]: On Wednesday 05 January 2005 09:50, Nico Golde wrote: Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. As a person looking for sponsors from time to time, I second this. thats the best reason i think. there are many people who sponsor packages which they find accidental because they don't read -mentors. that would be a good solution. who is responsible for such things? regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred
Re: New stable version after Sarge
On Wed, 05 Jan 2005 04:16:49 -0800, Stephen Birch wrote: Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. I guess one man's meat is another man's poison. Since I administer a large number of distant computers I view the long time between stable releases as a feature not a bug. What about saying something like: the next stable release comes in the beginning of 2006? Once a year works for me, but any more frequent would be a pain in the neck. Frankly a release every 18 months seems about right. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. Also the concept of releases when it's ready seems to be a little contrived. When *what* is ready exactly? The current system of defining a release seems to involve identifying a number is arbitrarily characteristics that will define the new version. The release occurs when they are complete and the RC bug list is low. Perhaps a date based release mechanism could be built using a new distribution, call it prestable. Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. So a package follows the following path: unstable -- testing -- prestable --(approx. 12 months)-- stable People running servers (like myself) will stick with stable. Those wanting a reasonably stable system but want the latest features run prestable. Those wanting the very latest but don't care about RC bugs run testing. Developers normally run unstable. In some ways prestable would resemble the current stable when the release manager has begun freezing it. Of course one would not want prestable to be released with critical components missing. To prevent such a thing a number of packages are identified as release essential (RE). Every RE package has to have migrated from testing to prestable for the annual release to take place
Re: RFS tag?
hi, * Adeodato Simó [EMAIL PROTECTED] [2005-01-05 18:02]: * Nico Golde [Wed, 05 Jan 2005 09:50:42 +0100]: From: Nico Golde [EMAIL PROTECTED] To: [EMAIL PROTECTED] ^^ is there a reason for this? breaks mutt's 'L'ist-reply... Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. Justin Pryzby has been working lately on this. you may find this thread [1] on -mentors interesting. I particularly like and fully support jvw's suggestion [2] about the forwarded status. for a more-bloated proposal, also from Justin, see [3]. ah ok thanks. maybe i will contact him. regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred signature.asc Description: Digital signature
Re: LCC and blobs
On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote: However, if somebody writes a graphviz-client which just pushes the dot file over the network to graphviz.example.com on some port and gets a postscript file back, it can go into main. No matter what software said server is running. Correct? In essence, yes. Do you have a problem netcat being in main? -- Raul
Re: New stable version after Sarge
Roberto Sanchez wrote: That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? I just filed a wishlist on cron-apt about that same thing this morning: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 If you have any suggestions on how to implement that, I'm all ears. - Marc
Re: LCC and blobs
Raul Miller writes: On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote: However, if somebody writes a graphviz-client which just pushes the dot file over the network to graphviz.example.com on some port and gets a postscript file back, it can go into main. No matter what software said server is running. Correct? In essence, yes. Do you have a problem netcat being in main? That is a disingenuous comparison. netcat is to network data as hex editors are to file data. The suggested graphviz-client is very different. Michael Poole
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wednesday 05 January 2005 02:05 am, Ingo Juergensmann wrote: When Joerg Jaspert is already doing the dirty daily work, why does James still needs in place then? (Except he just stays in that position for a transitional period until Joerg is taking over that task and job completely. I would recommend that transitional period for other positions as well.) Why does he need to be replaced at all? I think Debian is better off with small teams working key positions than single people. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | No-one remembers the singer.| | The song remains. | \ Debian GNU/Linux http://www.debian.org -- Because. ---/ pgpL2HJrbsAFz.pgp Description: PGP signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 12:30:52PM -0500, Marc Sherman wrote: That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? I just filed a wishlist on cron-apt about that same thing this morning: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 doesn't apt-listchanges do that? cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: New stable version after Sarge
Quoting Robert Lemmen [EMAIL PROTECTED]: On Wed, Jan 05, 2005 at 12:30:52PM -0500, Marc Sherman wrote: That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? I just filed a wishlist on cron-apt about that same thing this morning: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763 doesn't apt-listchanges do that? apt-listchanges shows the changes since the version of the package that is currently installed. If I am running testing and only interested in upgrading packages in response to a security fix, the amount of info could get big really fast. It would need to implement something similar to logcheck. It only shows changes since the last time it showed you changes. apt-listchanges also shows all changelog entries. The first time you run apt-show-security-changelogs, it would essentially function like apt-listchanges in that it would show the changelogs since the currently installed versions, with the exception that it does a 'grep -i \[security\]' on the changelogs. After that, say if it is run in a cron job, it will show you the appropriate changelogs only if it has not already chown you that particular changelog entry. There would need to be some whay for it to track what changelog entries have and hove not already been shown. That way, if I install package foo, it knows to start showing me any security-related changelog entries for that package, but only from that point forward. -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: RFS tag?
On Wed, Jan 05, 2005 at 01:30:21PM +0100, Nico Golde wrote: hi, * Frederik Dannemare [EMAIL PROTECTED] [2005-01-05 12:43]: On Wednesday 05 January 2005 09:50, Nico Golde wrote: Hi, what about an RFS tag for ITPs or and RFS bug report for wnpp. So debian developers who like to sponsor a package don't have to read debian-mentors. I think it would be a good idea. As a person looking for sponsors from time to time, I second this. thats the best reason i think. there are many people who sponsor packages which they find accidental because they don't read -mentors. that would be a good solution. who is responsible for such things? regards nico Hi debiandeveloperfolken, this has insired a 'mako'esque idea: Debian package personals: AD#1 says I have a new VIM extension that does cool new tricks with Clippy(tm), I'm looking for a special someone to sponser VIM-CLIPPYS-RETURN. Email me at [EMAIL PROTECTED] AD#2 says I'm a DD looking for some extra packages to add to the VIM collection. If you have the project that sparks my interest, email me at [EMAIL PROTECTED] Taglike: We get new packages into Debian by bringing people together! -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 11:16:44PM -0800, Ken Bloom wrote: On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote: Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? I've talked about this with James Troup before. He seemed pretty receptive to speeding it up to something like twice a day, didn't seem to feel it would hit the mirrors much worse. It's possible he may still be waiting on SCC splitting up the base set of arches or the like before revisiting this. Who's SCC? If there's no technical *requirement* for this to happen first, we should go ahead with speeding up this up, precisely because it's such a good time to test its effects, both positive and negative. (Positive effects won't be so noticable right after Sarge releases) I'm assuming it would be a really easy change to revert if it has negative effects. (BTW, please note that when I or this proposal talks about the dinstall run, we're using the circa 1998 definition that includes mirror sync. The dinstall program itself aready runs every 15 minutes.) Twice daily seems more reasonable to me than hourly; Why? If you run it only twice daily, then the developers who are awake at one run will probably be asleep at the next, so there's still essentially a whole day's lapse before a developer can fix anything. I'd say a minimum of 4 times a day lets a developer see the result of his changes before the next time he goes to sleep. But the attraction of hourly is that a developer can see feedback from his changes within a couple of hours, and a developer may be able to clean up any bugs people noticed in the same sitting that he introduced them. Hi folks, just a question from john q. hacker: is the files associated with a project have not been changed since the last run, why is the process repeated? Could someone make the process run when the files are changed? I'm thinking of an event-based approach. -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
Re: murphy is listed on spamcop
On Sun, Jan 02, 2005 at 03:31:38PM -0800, Thomas Bushnell BSG wrote: Santiago Vila [EMAIL PROTECTED] writes: I was just following your line of reasoning: You cannot justify the bad things that happen as a result of your actions by saying that your goals cannot be reached without such bad things happening, where: action = greylisting bad things that happen = delayed email Try reducing the level of spam to a 1/10th without false positives and without delaying any email. You cannot justify graylisting by saying but this is the only way to stop spam! You *can* justify it by comparing the costs against the benefits. The worst case costs of well-implemented graylisting should be something like a short delay in an email message; the worst case of a false positive rejection can be much much worse indeed. The worst case for graylisting is the same as a false positive: undelivered mail. Yes, there are servers out there that are non-spam (like, for one known example, at least one major airline's reservation notification system) that don't attempt to re-send on a 4xx code. Note that I'm not going to argue the merits of graylisting vs. other methods, or the actual measured costs, except to point out that you can implement *your* end of the protocol perfectly, in a way that shouldn't cause any mor than a delay, and the other guy can still screw it up for you. O() notation is useful, but in the real world, one must always remember that O(n) is n*k1+k2, O(n^2) is n^2*k1+n*k2+k3 - and the values of the constants can potentially matter. A lot. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: murphy is listed on spamcop
Joel Aelwyn [EMAIL PROTECTED] writes: The worst case costs of well-implemented graylisting should be something like a short delay in an email message; the worst case of a false positive rejection can be much much worse indeed. The worst case for graylisting is the same as a false positive: undelivered mail. Yes, there are servers out there that are non-spam (like, for one known example, at least one major airline's reservation notification system) that don't attempt to re-send on a 4xx code. A key word has been dropped here, well-implemented. :) I'm not yet sure if graylisting *can* be well-implemented; I would suggest that in fact graylisting is a protocol violation. That doesn't mean you can't do it, but it does mean that you can't describe graylisting as implementing your end of the protocol perfectly: Note that I'm not going to argue the merits of graylisting vs. other methods, or the actual measured costs, except to point out that you can implement *your* end of the protocol perfectly, in a way that shouldn't cause any mor than a delay, and the other guy can still screw it up for you. More interesting are the cases where the sender is *not* doing anything wrong, by for example sending from a huge farm of servers such that the mail comes from a different IP address every time, and the graylisting recipient keeps returning 4xx. That can be solved by not returning the 4xx until after the DATA command has been received, which enable you to detect cases like this. But doing so means that you lose the load-saving benefits of graylisting (though not the spam-filtering ones). Thomas
Re: updated debian development diagram -- comments?
Kevin Mark dijo [Mon, Jan 03, 2005 at 01:08:49AM -0500]: Hi Folks, I have updated my diagram on the debian developement model. Any comments appreciated! Very nice! I expect to use it at some conferences (BTW: Looks like a nice addition to Debian Eyecatcher[1], I'll add it :) ) I'd suggest you (although I don't know .fig, so...) to try to make the labels on the arrows be horizontal - Specially the ones on the left, going from Security team .deb to testing and stable security updates, as it's easy to mis-read upload as paoidn. Greetings! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: New stable version after Sarge
Florian Weimer wrote: I think that's because of the pending release, in particular frozen base packages, and not representative for the whole release cycle. There's some truth to that, but of course many of our worst dependency knots do not involve base packages. -- see shy jo signature.asc Description: Digital signature
Re: RunDinstallHourly
Steve Langasek wrote: And it's not like users want more frequent updates, either. Once a day is plenty often to be fiddling with apt-get; many sid users don't update nearly that often, after all. But we still get good coverage of each set of changes distriuted amoung our users even if most of them update only weekly. I expect this would stay the same if dinstall ran more often. There are really very few concrete benefits I can see to increasing the dinstall frequency Besides d-i, the one case that I'm pretty sure of is the one where a maintainer uploads a buggy package and finds out during that same wake-cycle that it's broken. So instead of sitting on #debian-devel playing tetrinet all evening while his package waits to break things the next day (when he'll be off on vacation), he's able to fix it right then. We've potentially wrung more work out of this volenteer, without really bothering him at all, and spread across the project as a whole I do think that would speed up the overall pace of development. -- see shy jo signature.asc Description: Digital signature
Bug#288810: ITP: nntpswitch -- Load Balancing NNTP Router
Package: wnpp Severity: wishlist * Package name: nntpswitch Version : 0.11-1 Upstream Author : Tommy van Leeuwen [EMAIL PROTECTED] * URL : http://www.nntpswitch.org/ * License : http://www.nntpswitch.org/manual/license.html Description : Load Balancing NNTP Router NNTPSwitch forwards client connections to multiple backend servers to get it's articles. Depending on the backend server type, all NNTP commands and extensions are supported. NNTPSwitch offers extensive virtual hosting envinronments to be set up. Virtual servers can have different sets of user groups. All kinds of different access policies can be set up using access-lists, authorization lists and group lists. Each individual user or session can have its own rate-limits, bytelimits, timelimits and other tunables to make up for everything an ISP wants. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686 Locale: LANG=POSIX, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Re: updated debian development diagram -- comments?
On January 5, 2005 03:38 pm, Gunnar Wolf wrote: Debian Eyecatcher [1] [1] http://alioth.debian.org/projects/eyecatcher/ At least I presume this is what you meant to include. Stephen -- Debian the choice of a GNU generation. GPG Public Key: http://www3.ns.sympatico.ca/scormier/publickey.asc pgpqbU311h66K.pgp Description: PGP signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote: Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: You should ask the release managers about that. Wow!! You mean the decision process is not made public? I would have thought it would be out in the open for all to see. Hmm, I would've thought that after 5 months of the Same Old Story, anyone reading d-d-a would know what the preconditions are for freezing sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 02:18:37PM +0100, Florian Weimer wrote: * Joey Hess: I think we've taken this security bugs arn't fixed in testing as well as in stable thing as gospel a little too long without verifying it lately. I've been checking and if testing is lagging stable at all, it's doing so by a much smaller amount than we've traditionally thought. I think that's because of the pending release, in particular frozen base packages, and not representative for the whole release cycle. If a switch to a new upstream version of libc runs into problems, testing and unstable will diverge again, maybe for weeks or months. testing-security intends to solve this, though. If a switch to a new upstream version of libc runs into these kinds of problems again in unstable, we aren't learning from our mistakes, and it's questionable whether any amount of strategizing will put is in a position to do time-based releases. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Cant build a simple package.
Hello, I'm learning making debian packages. I choosed to learn on a very simple software: minimalist. Installing it from source is just about copying a single file (minimalist.pl) into /usr/bin and then copying its conf file into /etc/minimalist.conf I get the error message you can see at the bottom of this post. I dont understand it. Would you help me? Especially where to tell the package builder not to use 'debian/minimalist/DEBIAN/control' but 'debian/control' ? In my rules file, I have: = #!/usr/bin/make -f export DH_VERBOSE=1 configure: build: clean: install: dh_testdir cp minimalist.pl $(CURDIR)/debian/minimalist binary-indep: binary-arch: dh_builddeb binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install The error output of the command 'dpkg-buildpackage -rfakeroot' (wich is run at the top source directory): === [...] debian/rules build debian/rules build fakeroot debian/rules binary fakeroot debian/rules binary dpkg-deb: failed to open package info file `debian/minimalist/DEBIAN/control' for reading: No such file or directory dpkg-deb: failed to open package info file `debian/minimalist/DEBIAN/control' for reading: No such file or directory dh_builddeb: command returned error code 512 make: *** [binary-arch] Error 1 dh_builddeb: command returned error code 512 make: *** [binary-arch] Error 1 -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours. Tél : 02 38 76 43 65 (France)
Re: Bug#288769: ITP: cedilla -- ascii to postscript renderer
On Wed, Jan 05, 2005 at 04:43:05PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: * Package name: cedilla Version : 0.5 Upstream Author : Juliusz Chroboczek * URL : http://www.pps.jussieu.fr/~jch/software/cedilla/ * License : GPL Description : ascii to postscript renderer with unicode support An ascii to postscript renderer written with the requirements of non-ascii text in mind. While other, older ascii renderers like a2ps apparently can not easily be adapted to output accented characters or non-latin scripts properly, cedilla was written with this requirement in mind from the start. I think you want to say plaintext to postscript renderer here, since clearly text that contains non-ascii characters is not ascii. ;) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Cant build a simple package.
Rakotomandimby (R12y) Mihamina wrote: I'm learning making debian packages. I think debian-mentors@ would be more approriate. I get the error message you can see at the bottom of this post. I dont understand it. Would you help me? Especially where to tell the package builder not to use 'debian/minimalist/DEBIAN/control' but 'debian/control' ? You don't want that. You are looking for dh_gencontrol(1): DESCRIPTION dh_gencontrol is a debhelper program that is responsible for generating control files, and installing them into the DEBIAN directory with the proper permissions. Note that it won't be enough; you should really look into existing packages to see how it is done. Regards, Frederic
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 02:45:12PM -0800, Ken Bloom wrote: On Wed, 05 Jan 2005 09:36:11 +1100, Andrew Pollock wrote: On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? Wouldn't this have a flow on effect on our mirrors (or is the mirror pulse independent of the dinstall run)? Either way, if the mirror pulse only happens once a day, running dinstall more than once is going to be largely ineffective for most users isn't it? Part of this proposal would be speed up the mirror pulse to occur as frequently as dinstall. Which our mirrors may or may not be ecstatic about... If they all get cross with us because of it, we're a bit worse off... regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten!
Re: New stable version after Sarge
El mi, 05-01-2005 a las 04:16 -0800, Stephen Birch escribi: Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. I guess one man's meat is another man's poison. Since I administer a large number of distant computers I view the long time between stable releases as a feature not a bug. What about saying something like: the next stable release comes in the beginning of 2006? Once a year works for me, but any more frequent would be a pain in the neck. Frankly a release every 18 months seems about right. I agree with you on this. People using stable can not cope with upgrades each 6 months or so. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. Also the concept of releases when it's ready seems to be a little contrived. When *what* is ready exactly? The current system of defining a release seems to involve identifying a number is arbitrarily characteristics that will define the new version. The release occurs when they are complete and the RC bug list is low. Perhaps a date based release mechanism could be built using a new distribution, call it prestable. Packages qualify to be enter prestable after residing in testing for ten days and having NO RC BUGS. The idea is to keep prestable in a highly stable state at all times, a rolling stable if you will. So a package follows the following path: unstable -- testing -- prestable --(approx. 12 months)-- stable People running servers (like myself) will stick with stable. Those wanting a reasonably stable system but want the latest features run prestable. Those wanting the very latest but don't care about RC bugs run testing. Developers normally run unstable. In some ways prestable would resemble the current stable when the release manager has begun freezing it. But here lacks how packages migrate from testing to prestable. Is this a snapshot of testing at, lets say 12 months with 6 months for checking it, or does packages migrate following soe guidelines as they do right now from unstable to testing? Of course one would not want prestable to be released with critical components missing. To prevent such a thing a number of packages are identified as release essential (RE). Every RE package has to have migrated from testing to prestable for the annual release to take place. Any non-RE packages with RC bugs at release time simply do not make it into the stable release for that year. If it looks like a critical package will be ommited the release manager can always make that package RE. Ok, that is nice for RE packages. But how other packages would be handled? Without an aggressive removal policy, they can take longer for being ready that the release time. Of course, it is supposed that testing doesn't have RC bugs, but you know that is not always true. Although the target is for an annual release to occur, the proposed mechanism also permits the project to identify a set of features for the new release. For example, had prestable existed for 3.1 the new installer would have been listed as RE. So ... Debian would still release when its ready but everyone has a better idea of what ready means simply by looking at the RE package list. Why don't you put this idea in Debian Wiki? (http://wiki.debian.net/?ReleaseProposals) Thanks. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Experimental gaim_1.1.1-2 for Alpha
On Wed, Jan 05, 2005 at 09:27:50AM -0500, Greg Folkert wrote: On Wed, 2005-01-05 at 08:55 -0500, Greg Folkert wrote: I have built this package for alpha and it does indeed work. I have bundled it up in a tgz making it easier to D/L. But all the files are there as well for individual inspection. Along with the md5sums http://www.gregfolkert.net/experimental/ not an archive by any means, but available at your discretion. BTW, someone pointed out I didn't sign the .changes file... ummm oops. First real try at building the packages for general consumption. My bad. Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. It's trivial to ensure your changes file will be rejected by katie, by setting the 'distribution' field in your changelog to an unknown value. In this case, your package would also be rejected because it's a sourceful upload of a package that already has source in the archive; but if this had not been the case, you might have found yourself blamed for whatever bugs this build introduced. In any case, perhaps this particular build should have been a binary-only upload to experimental, to join the i386 build already there? Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Experimental gaim_1.1.1-2 for Alpha
* Steve Langasek [EMAIL PROTECTED] [2005-01-05 15:12]: Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. ... In any case, perhaps this particular build should have been a binary-only upload to experimental, to join the i386 build already there? Greg doesn't appear to be a Debian developer so neither of this applies. The first paragraph is good advice in general, though. -- Martin Michlmayr http://www.cyrius.com/
Re: New stable version after Sarge
Jose Carlos Garcia Sogo [EMAIL PROTECTED] wrote: I agree with you on this. People using stable can not cope with upgrades each 6 months or so. The issue isn't the frequency of new stable releases - the issue is how long a given stable release will be supported for. Releasing every 6 months wouldn't be a problem if we could support the previous two releases as well. That's probably excessive, but the optimal release length depends on how much support we can provide. -- Matthew Garrett | [EMAIL PROTECTED]
Bug#288854: ITP: phptal -- phptal is an implementation of Zope Page Templates (ZPT) for PHP.
Package: wnpp Severity: wishlist * Package name: phptal Version : 0.7.0 Upstream Author : Laurent Bedubourg [EMAIL PROTECTED] * URL : http://phptal.sf.net * License : GPL Description : phptal is an implementation of Zope Page Templates (ZPT) for PHP. TAL is a template attribute language developped and used by the ZOPE community. PHPTAL provides an implementation of this excellent template language for php. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (900, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: Experimental gaim_1.1.1-2 for Alpha
Scripsit Martin Michlmayr [EMAIL PROTECTED] * Steve Langasek [EMAIL PROTECTED] [2005-01-05 15:12]: Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. Greg doesn't appear to be a Debian developer so neither of this applies. But if he later *does* become a DD, the archive scripts might retroactively accept his old changes file if somebody uploaded it, wouldn't they? (I'd be surprised if they checked the creation date of the signature, but things sometimes do surprise me). Here I ignore the fact that a newer version would probably be in the archive by then, for this particular package at least. The first paragraph is good advice in general, though. Does it also apply to signing .dsc's? -- Henning MakholmHe who joyfully eats soup has already earned my contempt. He has been given teeth by mistake, since for him the intestines would fully suffice.
Re: Experimental gaim_1.1.1-2 for Alpha
On Wed, Jan 05, 2005 at 11:47:57PM +, Henning Makholm wrote: Scripsit Martin Michlmayr [EMAIL PROTECTED] * Steve Langasek [EMAIL PROTECTED] [2005-01-05 15:12]: Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. Greg doesn't appear to be a Debian developer so neither of this applies. But if he later *does* become a DD, the archive scripts might retroactively accept his old changes file if somebody uploaded it, wouldn't they? (I'd be surprised if they checked the creation date of the signature, but things sometimes do surprise me). Here I ignore the fact that a newer version would probably be in the archive by then, for this particular package at least. In this case, I merely failed to realize Greg wasn't a DD. Both you and Martin are correct. The first paragraph is good advice in general, though. Does it also apply to signing .dsc's? The archive scripts won't act on an uploaded .dsc without an accompanying .changes file, so this is not an issue. Moreover, signing your .dsc provides a trust path to your source code (in the case where you're making sourceful changes -- Greg did not, so probably shouldn't need to distribute a .dsc at all), so this is a good idea. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: updated debian development diagram -- comments?
Hi Kevin! * Kevin Mark [EMAIL PROTECTED] [050103 07:08]: I have updated my diagram on the debian developement model. Any comments appreciated! What is the target group of your diagramm? Since I don't think people without deeper knowledge of Debian will find your diagram easy to understand because, partly because of the akronyms, partly because you try to explain everything at once. It's much information on a small page, you know? I know, this critic lags of any hints howto do it better, but I don't have any, sorry. Yours sincerely, Alexander signature.asc Description: Digital signature
Re: New stable version after Sarge
El mi, 05-01-2005 a las 23:13 +, Matthew Garrett escribi: Jose Carlos Garcia Sogo [EMAIL PROTECTED] wrote: I agree with you on this. People using stable can not cope with upgrades each 6 months or so. The issue isn't the frequency of new stable releases - the issue is how long a given stable release will be supported for. Releasing every 6 months wouldn't be a problem if we could support the previous two releases as well. That's probably excessive, but the optimal release length depends on how much support we can provide. Yes, but I think that we are not going to be able to support more than one release (or one and a half, if testing security team works) at a time, with perhaps supporting two for some time after the release of a new stable. This is not only an infraestructure problem, but a problem of DD time and DD effort and knowledge, which for some tasks can be a bit reduced. Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 10:18:21AM -, Adam D. Barratt wrote: On Wednesday, January 05, 2005 10:05 AM, Ingo Juergensmann [EMAIL PROTECTED] wrote: [...] When Joerg Jaspert is already doing the dirty daily work, why does James still needs in place then? (Except he just stays in that position for a transitional period until Joerg is taking over that task and job completely. I would recommend that transitional period for other positions as well.) aiui, because James - or presumably some other member of -admin - needs to create the accounts once an nm has been approved (newsamosa, aka db.d.o is restricted). The most time-consuming part of DAM work is approving applicatants, which is what Joerg is now doing. afaics, once an applicant is approved, accounts are being created relatively quickly; so far it appears to be working well. Speaking as someone who has railed (more than once) against the six-to-twelve-month waiting period between AM approval and DAM review complete (as noted, once DAM approval was had, accounts happened without perceptible delay), all I will say is the following: 1) Time will tell if this helps enough 2) So far, it looks promising 3) So long as James is considered valuble and useful by the people doing the work (presumably including himself), *and the work is getting done*, I don't much care how many positions he holds. It's the whole getting done thing that seemed to be suffering from his state as a multiple-path single point of failure, and small teams is, in my opinion, a vastly better answer than multiple single-path single points of failure, even if the latter is still better than the situation as it appeared to be in the past. My only other wish is that some of the teams had a bit more transparency, or at least had it more consistantly (some FTPmaster folks are pretty good about this, and others aren't, but it appears to be the luck of the draw, at least from outside the black box, as to what you get, for one notable example - and this may well have nothing to do with James whatsoever, at least on any personal level). -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
