Debian Project Leader debate 2005 transcript posted to the web
Hi, Thanks to stellar efforts on the part of Helen Faulkner and Martin Krafft, the Debian project leader debates went off very well. I would like to thank them, and others who helped, on behalf of the project. A transcript of the debate can be found at URL:http://www.debian.org/vote/2005/Log-debian-dpl-debate, while the raw logs of the 4 channels involved in the debate are linked from the top page at http://www.debian.org/vote/2005/vote_001 manoj -- Hope that the day after you die is a nice day. Debian Project Secretary [EMAIL PROTECTED] http://vote.debian.org/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpFvDknQbl1U.pgp Description: PGP signature
Logs from the DPL debate posted, and a draft ballot
Hi folks, The platforms for the candidates for the project leader are available as links on the page http://www.debian.org/vote/2005/vote_001 or, http://www.debian.org/vote/2005/platforms/. The rebuttals are also in place. The following is a ***DRAFT DRAFT DRAFT*** ballot for the upcoming elections. The ordering of candidates was determined using Perl and rand() (yeah, too lazy to actually toss coins this year).. == Votinge period starts 00:00:01 UTC on March 21st, 2005. Votes must be received by 23:59:59 UTC on April 10th, 2005. This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact [EMAIL PROTECTED] HOW TO VOTE Do not erase anything between the lines below and do not change the choice names. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue till you reach your last choice. Do not enter a number smaller than 1 or larger than 7. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1= X = 7). To vote no, no matter what rank None Of The Above as more desirable than the unacceptable choices, or You may rank the None Of The Above choice, and leave choices you consider unacceptable blank. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Then mail the ballot to: [EMAIL PROTECTED] Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 46348448-74a5-40ae-a651-49704435ae8c [ ] Choice 1: Jonathan Walther [ ] Choice 2: Matthew Garrett [ ] Choice 3: Branden Robinson [ ] Choice 4: Anthony Towns [ ] Choice 5: Angus Lees [ ] Choice 6: Andreas Schuldei [ ] Choice 7: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.5 (GNU/Linux) mQGiBEHyy+gRBAD2ooetZbcbrJuCsPlXTq2oVaxUXFQjzoSnHiavDMZgGJYQX6cn w90FEBNlkFZihwgzmFQ3N5HuA2OwT9nrrNBWcCNhM9YPqhD+tZ9bBz90YJuq0O5P rT1t66j2uMXnCB2JipuxB35t+40mSyU+9RIc4z/4+G4AnQz4gJq3ZMOy/wCgmwoY OGmhXi6f3Tx2WXpjrs5NvRUD/1HlwWC8fR+T4vska4NQJf6L8xOs8YqPH+CGys0C F3WIqv/f1SqENxdIe/9drN+R58Da9Z58pJZVVtVyZVm2mrDdKGv1wNoV81rT7hoG J9bN5LWVlVGofYbU4MBpjBxSQbu4s7Hjq/xAVoMMjXRg25U3h/AM4Nl44+LmzhJC TfdABACI27eLEIdO/MLSuzIxZcHpiUcVkbA7L3CncR6o6nCQAkmDuCrjyNF4PnrG 3W1xVb/JePWlUTqz3/mRY7Y5yH3dgrFB/4oFR/t5o1tVmTnDdN+YgtUSN/jSybVq XzMELrzSKU2jza+mJD+m284EldL+ETjOmS8Eq5kUJbJu6fHIl7R7VGhlIERlYmlh biBwcm9qZWN0IGxlYWRlciBlbGVjdGlvbiAyMDA1IEtleSAoVGhpcyBpcyBhIHRl bXBvcmFyeSBrZXkga2VwdCBvbiBhIHB1YmxpYyBtYWNoaW5lKSA8bGVhZGVyMjAw NUB2b3RlLmRlYmlhbi5vcmc+iGQEExECACQFAkHyy+gCGwMFCQBuvgAGCwkIBwMC AxUCAwMWAgECHgECF4AACgkQmeUHrB3rN/xoBQCZAXsltpLhlkyRsWM8Zc5rYtoo o+EAmwQ4oqcDmP8YtL5pdL6J+lhHdQr5iEwEEBECAAwFAkHy0HwFgwBuuWwACgkQ Ibrau78kQkyD9wCfdg7bHztLfoSWocQEZvxpTPl2RhwAnikSaAW4SS0OW4dm9YK8 wX/kWjE+uQENBEHyy+gQBAC8kLQoeOh4XGeSLubG9B6A+N7E7IGyavHGkswdqaBm 8wZpN91Jkl94ml5oL/fpA871R/+FRgHe9/OveERgc6NxeiRI9VwwmNFLyFLKTUdv M6UpXxM0zyM/hrXjxftW+92lihsYuLI9X7Lw8OQlbmIrmL4Ysz3qH1p4/GTKnBE6 GwADBQP/ci/6RMtXW13YaUxB8p9SiffKS1p6pDgaeKbUDDjLH/Ldcat044UoBM3h VkUzN6MQLdKj7bgZv8xCDYZZSFf7zynfot/UD7h07TMerQ92vm1ytxC8rDJOF12B J0XVuIqUNyFQEGMQzooSNbdf6be6k5BhiV7CqYE3gTpiQAC0XCOITwQYEQIADwUC QfLL6AIbDAUJAG6+AAAKCRCZ5QesHes3/JwCAKCD19s2E1NuTFMwVXR7m9oY2SN8 YwCglFQ5hhtqKPMl3pKVWonXkETV0hY= =cSBQ -END PGP PUBLIC KEY BLOCK- == -- She's genuinely bogus. Debian Project Secretary [EMAIL PROTECTED] http://www.debian.org/vote/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpAq7GfldWM8.pgp Description: PGP signature
Re: come funziona il depends?
Il giorno gio, 17-03-2005 alle 08:34 +0100, Fabio Tranchitella ha scritto: Ciao Giuseppe, debian-policy (sezione 7.3, Virtual Packages - Provides) dice: [...] È sempre così: io avevo cercato le informazioni dove si parlava del depends e invece stavano dove di parlava del provides :-( Grazie, Giuseppe
Re: Required firewall support
Joel Aelwyn [EMAIL PROTECTED] writes: For buildds, since I don't run one as either local or DSA admin, I couldn't tell you offhand. I know what I'd *expect* them to be doing, as general guidelines, which closely resembles what I do on servers I deploy facing the net, but I don't know what they *are* doing. The SCC criteria do not require a buildd plugged in to the Debian w-b system. I have no particular reason to believe that they aren't running a sane set of firewalling rules; in fact, I would assume that they are, but I don't feel impolite enough to annoy someone's HIDS log with random checking. What is a sane set of firewalling rules? Can you be more specific and less vague? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Daniel Jacobowitz wrote: My basic idea is to have something similar to the testing migration scripts, which takes the decisions of the master copy running on ftp-master as an input. At a minimum: I think it's easiest just to assume everything's on ftp-master; for mirroring, stuff's already planned to be split onto ftp.d.o and scc.d.o anyway. The only reasons that wouldn't happen is if ports need non-developers to be able to upload, or are using up lots of disk really wastefully. - Packages in sub-testing should not be newer than the versions in testing, except on purpose. Porters need to be able to use newer versions when a particular version does not work on their architecture, but I want a by-hand element involved in that. In normal, non-schedule-pressured, non-crippling-bug mode, they would just fix the copy in the main archive and propogate that to testing, and from their to sub-testing. Okay, so we've got a new suite; is that global for all scc arches, or separate, a la subtesting-s390, say? The question there is Will s390 have a different version of the package to m68k, if one or the other is being more aggressively maintained? So, say you have foobar 1.0 in subtesting for s390, and foobar 2.0 in testing and foobar 3.0 in unstable for i386. Your buildd's been somewhat broken for a few weeks, and you haven't built foobar 2.0 or 3.0 yet, but you've got it working again now. What happens then? Do you build foobar 3.0, find out there are some s390 specific bugs, watch it go into testing anyway, not accept it to subtesting because those bugs need fixing, get 3.1 uploaded to unstable, built it, watch it go into testing, and then have it go into subtesting too? Or do you build foobar 2.0, upload your debs to unstable, find it works perfectly, and get into subtesting, then wait 'til 3.0 gets into testing before building it and finding out it has problems? Do you use the testing scripts, and thus aim to ensure subtesting's dependencies are consistent, or do you just copy debs across and hope? If the former, why bother looking at testing at all, instead of just pulling from unstable, and calling it, say, scc-testing-s390? OTOH, only pulling from testing makes it simpler to end up with something you could call etch for s390. - Internal consistency and installability would be maintained for the sub-testing repository in the same way we maintain them for testing. This allows the port to leverage the excellent work done by the release team, and not get in their way - it's completely unidirectional, nothing feeds back to the parent repository. And it allows leverage of the testing scripts - with some changes, that someone would have to pony up the time to implement, of course. One of the problems with this is that you wouldn't benefit from the hints the release team prepares for britney; which might screw you over completely. OTOH, dealing with smaller numbers of architectures is easier, so maybe some of the existing automation would be more effective; and maybe the other britney features we planned at the meeting will make this irrelevant anyway. I would really like to see some real use cases for architectures that want this; I'd like to spend my time on things that're actually useful, not random whims people have on lists -- and at the moment, I'm not in a good position to tell the difference for most of the non-release architectures. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn [EMAIL PROTECTED] writes: Fine, if you want to get pedantic, the following is a bare minimum of capabilities I would expect from any network processing on a 'real' (non-toy) network stack, where 'network stack' means everything between hardware driver and delivery of data to a userland application. It's late, so this may not be exhaustive. The guidelines do not speak of toy os. It appears that you are not aware of why this requirement is listed in the guidelines, nor of why it would be important for the secondary archive, nor of what the actual practice is on buildds. Can we replace this with a thread involving people who do know these things? The Hurd has had all the things listed on your schedule of filtering rules for longer than Linux has. All that is necessary is simple user-space tools to implement them. Do you have a specific tool that should run, or anything else? Unless marked as 'nice to have', everything above is a *must* for running even basic firewall configurations on a host expected to face the Internet. If you can do those, and configure them in some semi-sane fashion, then you probably meet the expectations reasonable people would have for basic firewalling. But what is not said here is why this particular feature is necessary for being in the secondary archive, as opposed to other features. To say, a buildd must have that feature is only sensible if the buildds are actually *using* such-and-such feature, and you, in fact, don't know that they are. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of buildds?
On Wed, Mar 16, 2005 at 11:17:42AM -0800, Thomas Bushnell BSG wrote: I was speaking specifically of porter uploads; my discussion is about the specific case of s390 complaining that they can't do their porting work (which includes simply compiling packages) because the w-b admins won't add whatever buildd. It is simply a condition of ENOTIME. The buildd is setup, activate them needs 10 minutes, adding a entries to the ACL needs less. Setting up a w-b needs 1h, doing the work by hand needs much more time. My point is that porters already have all the authority they need to build and upload packages. Everyone have the authority to do uploads. And if you have a machine, you can port something on them. Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, Elaan of Troyius, stardate 4372.5 signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
Frank Küster wrote: Unless there is an arch-specific bug in that version. The code for architecture tags in the BTS is available if I'm not mistaken. I'll add rc-s390 etc tags or similar to bugs.d.o the day sarge is released, presuming this goes ahead. No complicated patching whatsoever needed. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of buildds?
Bastian Blank [EMAIL PROTECTED] writes: It is simply a condition of ENOTIME. The buildd is setup, activate them needs 10 minutes, adding a entries to the ACL needs less. Setting up a w-b needs 1h, doing the work by hand needs much more time. But that should not stop you from attacking the existing list. Grab packages off the back end of the list, and start building. It would at least help the current problems. Catchup has started to make some progress; the current disaster buildd seems to be arm, now that mipsel has mostly caught up and s390 has turned around. So long as at least a single buildd arch is having trouble, we are all penalized. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Source of LPhoto
Hi, I found that LPhoto sounds like a nice program to have. The only link to the source I found is at http://software.lindows.com/emptypool//lindowsos/pool/main/l/lphoto which points to a direct tarball in the Linspire pool archive and this archive contains a GPL statement but contains verison 0.12 while at the latest announcement contained version 2.0. For a more recent version just look at: http://www.linspire.com/lindows_products_details.php?product_id=12418 which says in the end: ... Lphoto is an open source application - source code available. But there is no link or other sign of a downloadable source. Am I to stupid to find the source or do the people at this site have a different opinion about downloadable source than I. I wanted to issue an ITP if it is worth but wonder which link to the source I should use. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 09:46:36AM +1100, Benjamin Herrenschmidt wrote: Have we any proper way of doing multiarch setups ? The proper way to do ppc64 is to have both archs libs and 32 bits userland for most things, as ppc64 native code is slightly slower. The packages are waiting for some people. I have repeated that over and over again but it seems I have been ignored so far... glibc 2.3.2 does not properly support powerpc64. Also make sure the compiler is biarch as the kernel build will soon require this. Done. Bastian -- Our way is peace. -- Septimus, the Son Worshiper, Bread and Circuses, stardate 4040.7. signature.asc Description: Digital signature
UNSUBSCRIBE
--Faites un voeu et puis Voila ! www.voila.fr
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 09:46:36AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: Hello, This is a call for help from the 'ppc64' porters. On 05-Mar-14 16:14, Martin Michlmayr wrote: Also, as with the amd64 port, there is disagreement about the name. While ppc64 would be nicer and in line with the LSB, our current PowerPC port is called powerpc and therefore it would make more sense to call the 64 bit port powerpc64. There has been a decision of the Debian Technical Committee concerning the name of the amd64 port which basically says that the porting team should decide on the architecture name generally (see [1]). The ppc64 porters decided to use the name 'ppc64' as the package name a few month ago. .../... It's a fully 64 bits setup as it seems ? That is rather inefficient. Have we any proper way of doing multiarch setups ? The proper way to do ppc64 is to have both archs libs and 32 bits userland for most things, as ppc64 native code is slightly slower. I have repeated that over and over again but it seems I have been ignored so far... Not ignored, there is an effort, fully orthogonal to this pure-64 one, to get ppc64 biarch going. We are somewhat stopped by the work needed on the sarge release, but it will happen in the close next time. Now, there is an interest on IBM's and IBM's customer part for getting ppc64 support, and altough we have access to the augsbourg power5 box (but without virtual machine, so we can't really do kernel or installer tests), we don't have those ppc64 machine IBM mentioned could be made available, which makes work on the kernel and installer part at least less possible. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, Mar 16, 2005 at 10:24:04PM +, Scott James Remnant wrote: On Wed, 2005-03-16 at 23:14 +0100, Andreas Jochens wrote: On 05-Mar-16 22:01, Scott James Remnant wrote: On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: My concern is the same as that of the Project Leader, that the existing powerpc port is called powerpc -- and that we should at least try to be consistent with already chosen architecture names. So you would add 'powerpc64' support to dpkg if the port changes its package name accordingly? Yes, that'd be applied to the 1.13 branch straight away. However, I still do not understand why you and/or the Project Leader want to override the decision of the porters and choose a different name than the LSB specifies. I am not saying that Debian should always follow the LSB blindly, but I cannot see a good reason for deviating from the LSB in this case. Because it's a 64-bit version of an already supported architecture. Having ppc and ppc64 would be fine, as would having powerpc and powerpc64. Having powerpc and ppc64 is inconsistent. Notice that powerpc used to be called ppc back then (98ish or something such), and that the name got changed to powerpc64. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 12:10:59AM +, Scott James Remnant wrote: On Thu, 2005-03-17 at 00:31 +0100, Andreas Jochens wrote: Moreover, I seriously doubt that this is an honest argument. I think you just want to decide the architecture name yourself. No, I would just prefer consistency. You've deliberately chosen an architecture name that's jarringly different from your 32-bit variant; that's a rather bold thing to do, and I think you need to justify that. Notice that ppc64 is what is widely known in the outside world on anyone working with 64bit powerpc, that both the kernel and the toolchain use it, that all the documentation referent to it uses ppc64 and that the other distributions doin 64bit powerpc (gento, suze and redhat) use it too, as well as all cross toolchain out there. Will we want to do something different as pure dogma, despite the cost involved ? Obviously I have no power to overrule you on your choice of architecture name, but I'd like to try and appeal to some common sense in you, if there is any. Hehe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On 05-Mar-17 09:31, Bastian Blank wrote: glibc 2.3.2 does not properly support powerpc64. This is correct. Because of this, the ppc64 Port uses glibc-2.3.4. The current Debian package has been patched to use version 2.3.4 for the ppc64 port. All patches used by the current Debian glibc which are already in version 2.3.4 have been dropped for this. Only about 30 patches out of more than 100 had to be kept. The newer glibc version works quite well so far. Two other packages needed a small patch to properly run with glibc-2.3.4. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Martin Schulze wrote: not to mention the time spent by the DSA/buildd admins and the security Thanks for asking the security team how much work it is to support 11 architectures. Err... Huh? I wasn't asked? Uh? However, to clarify this for the readers who aren't involved in security: Thanks to the awesome buildd network and a stable Debian release supporting 2 architecturs is as easy or difficult as supporting 20. The difference is just waiting for one buildd reply or waiting for 19. In most of the times the package will compile fine on all architectures since it's a stable Debian release and hence its packages are supposed to be rebuildable on a stable Debian machine. There are exceptions to the rule, but they're not that common. A new S/390 kernel and a new MIPSel kernel caused some configure scripts to fail, but this can be solved quite easily (once debugged and documented) by patching the configure script, so it's just a rebuild that is required. More problematic are cases when software doesn't compile anymore on a certain architecture due to compiler problems or kernel limitations. However, these are very rare and I only remember two such cases: chbg doesn't compile on HPPA anymore and xemacs21 cannot be compiled by a buildd anymore. It causes the security team a lot more work to support more than one distribution and/or to support older software for which current patches don't work and where the code is too different to easily find out whether it is vulnerable as well or not. Supporting stable and oldstable for a year until we drop support for oldstable always causes a lot of extra work for us. Supporting more than one architecture for a given distribution is not. This, however, refers to a working buildd network. However, every once in a while one architecture fails because only one buildd is configured for stable-security and this buildd is defunct. For example, there was no working i386 buildd for a long time. Currently, there is no arm buildd (for whatever reason, I dunno). The hate architecture for many developers however, m68k, has worked quite well normally. There are about a dozen buildd machines and several of them are configured to compile stable-security. If one machine is busy or down, another one picks up the package. Additionally, this architecture has quite responsive buildd admins so problems can be discussed and resolved via irc or mail quite easily. These are features I would wish for all architectures: more than one buildd configured for stable-security and responsive buildd admins. I'm not sure if my wording was bad but apparently I offended some people not on intention. So let's clarify some pieces: The security team is very thankful for the buildd network as it simplifies the roll-out of security updates a lot. We couldn't support our distributions without this buildd network. It is an essential projects asset and an essential resource of the security team. For potato we had to compile all packages manually on the six architectures that potato was released for. When build dependencies were missing we had to ask for their installation. This bound a lot of time and energy. As the number of packages and the number of architectures grew this didn't scale well. That's why we mentioned that we cannot support woody if we need to continue building packages manually for all architectures. Unfortunately this caused a delay of the release of woody but in the end it gave us a great opportunity to support woody and concentrate not on building but on fixing problems. James and Ryan have set up and configured the buildd network and have done a great job installing it. Without their work I don't know what the security team would do now. The above explanation came from the security team only. It didn't come from the buildd admins or the system administration. These are totally different matters. Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]: Andreas Barth wrote: If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. I think it makes sense to shorten the list of arches we wait upon for testing migration, but I fail to see the usefulness of removing an arch from testing. If we don't wait for an arch, it gets out-of-sync quite soon, and due to e.g. legal requirements, we can't release that arch. (In other words, if an arch is too long ignored for testing, we should remove it, as we can't release it in any case.) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) [050317 01:30]: On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: In article [EMAIL PROTECTED] you write: I have an e3500 to replace both auric and vore (and the raid), but I haven't gotten an ok from James to do so yet. That would cut the number of sparc buildds down to one, when two are required for RC archtectures under the new proposal. That's ok because two buildd's can run on the one machine. It has 6 cpu's. That still doesn't suffice the N+1-requirement. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) [050317 03:25]: On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote: Ben Collins [EMAIL PROTECTED] writes: On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: In article [EMAIL PROTECTED] you write: I have an e3500 to replace both auric and vore (and the raid), but I haven't gotten an ok from James to do so yet. That would cut the number of sparc buildds down to one, when two are required for RC archtectures under the new proposal. That's ok because two buildd's can run on the one machine. It has 6 cpu's. That cannot be the requirement. The point has to be an additional and independently functioning piece of hardware. If the disk blows or it is compromised or something, the others should be able to continue. The requirement sucks, lets leave it at that. If the machine dies, I can have two to replace it within a day or two. Ah, so why is vore down now for some time now? If it's so easy to replace a broken machine, why don't you just do it? (And, BTW, you might be on vacation, sick, ... - we need more than just one machine.) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Andreas Barth ([EMAIL PROTECTED]) [050317 10:54]: Ah, so why is vore down now for some time now? If it's so easy to that should read as auric of course. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Sbapshots of unstable. And people would run that on their servers? Some, maybe. Are there lots of people running servers on m68k and arm? Debian/ARM is becoming viable as a handheld platform as they get 400+ Mhz CPUs and gigabytes of storage (which is all available now). Cheers, Peter (p2). signature.asc Description: Digital signature
Re: How to join a team
On Wed, Mar 16, 2005 at 09:52:35AM -0800, Thomas Bushnell BSG wrote: 3) Only some people can install the patches. [...] (3) raises the question: who chooses who can install the patches directly and who cannot? The people who run the show, just like any Free Software project. You earn the trust of the people who are in charge, over time, by providing good help, and then eventually you become one of the people in charge. That might actually be a point of dysfunction in Debian -- we're trying to merge two separate models of cooperation. On the one hand, package maintenance is, at the end of the day, a free-for-all -- any DD has the authority to upload any package to the archive (social strictures notwithstanding), but a lot of the other stuff is modelled on a more cathedralic (not a word, I hope) development model. That might go some way to explaining why a lot of DDs get *so* upset by less-than-speedy resolution of their problems in other areas, because we're so used to being able to freely wheel-and-deal with packages. - Matt signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 09:57:29AM -0800, Thomas Bushnell BSG wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Moving wanna-build to a mirror will mean that new source packages have to be in the archive for at least one mirror pulse before they get built. The m68k port has been working like that for a very long time (Since wanna-build's inception until a few months before the woody release), and that was the main reason (probably the only one) why it couldn't keep up as well as the other architectures before that time. Or it could subscribe to the announce mailing list. That would need quite some extra code to work. Wanna-build gets its input from running quinn-diff, which parses the Packages- and Sources-files. Doing this using the announce mailinglist would require quite some work to parse such mails into something wanna-build can fathom. Of course, that doesn't mean it's impossible (this is Free Software, everything is possible), just that it's easier to wait for the w-b admins to do their job than to start setting up a w-b db of your own. And, aren't we all lazy? ;-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: ... and probably not for (that is, not unless you tell me otherwise): HPGL HTML HTTPS Traditionally I think these would use an. Even if you pronounce h as haich rather than aich as another poster pointed out, many words beginning with h such as historic or horrendous require an in formal writing e.g. an historic achievement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An idea from a Debian user
On Thu, Mar 17, 2005 at 12:28:55PM +1100, Evan Cox wrote: My idea is to create a frontend program that is similar to the profile 'Midnight Commander' in Konqueror (ie screen splint into 3/4 top and 1/4 CLI) that begins with iconised area relevant to the administration task, and ends with a screen of relevant commands for the appropriate task and when appropriate some GUI features. From my point of view, a program like this would be a fantastic learning assistant in the crossover from point and click to CLI, and add a central administration section to Debian. This sort of thing could be a great teaching tool. It is not so much related to a distribution like debian, but to the *nix command line in general. Command line shells are extremely powerful, but they were never designed in a coherent and though-out fashion, so they're much harder to learn than, for example, an elegant programming language. The problem with your proposal is that it's an extremely large and complicated task if you want to do it properly. It isn't going to happen unless someone (probably not debian) puts extensive effort into it. It might also be easier to implement a new, less crufty, command line shell (and programmatic interface to standard command line tools) from scratch while one was at it. -- Peter Eckersley Department of Computer Science mailto:[EMAIL PROTECTED] IP Research Institute of Australia http://www.cs.mu.oz.au/~pde The University of Melbourne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299918: ITP: php4-kadm5 -- MIT Kerberos5 remote administration module for PHP4
Package: wnpp Severity: wishlist Owner: Cajus Pollmeier [EMAIL PROTECTED] * Package name: php4-kadm5 Version : 0.2.4 Upstream Author : Holger Burbach [EMAIL PROTECTED] * URL : http://freshmeat.net/projects/php-kadm5/ * License : GPL Description : MIT Kerberos5 remote administration module for PHP4 php4-kadm5 is a PHP extension (PECL module) which allows you to access Kerberos V administration servers. You can create, modify, and delete Kerberos V principals and policies. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.29 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: * The first rule of securing a machine exposed to the wilds is Deny by default, allow by need. Which is pretty well accomplished by only running needed services. A port without a services is an implicit deny. Sorry, but being able to cope with a hostile environment *is* a requirement in today's network, and there isn't any real way around that fact. I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Wed, 16 Mar 2005 18:30:28 -0500, Ben Collins [EMAIL PROTECTED] wrote: The requirement sucks, lets leave it at that. If the machine dies, I can have two to replace it within a day or two. If you happen to be available at that time. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Another load of typos
On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: ... and probably not for (that is, not unless you tell me otherwise): HPGL HTML HTTPS Traditionally I think these would use an. Even if you pronounce h as haich rather than aich as another poster pointed out, many words beginning with h such as historic or horrendous require an in formal writing e.g. an historic achievement. (This might be a topic without a possible conclusion!) Funny, but although I'd say an HTML file or an HTTPS url or similar, I'd say a history achievement. But then we say aich not haich here. An FAQ, too (not a fack). An SQL server, not a sequel server (my pet hate). Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug count is going to hit #300000! (was Re: Bug#299919: samba-common: ...)
On Thu, Mar 17, 2005 at 10:47:15PM +1100, Andrew Bartlett wrote: On Thu, 2005-03-17 at 12:11 +0100, Domenico Andreoli wrote: Package: samba-common Version: 3.0.10-1 Severity: minor hi, i'm seeing there is file /etc/samba/gdbcommands. it looks like it is installed by samba-common by error. could please remove it from the package? This file is used by the panic action specified by the smb.conf. This is deliberate. ah.. ok. sorry to have wasted a bug :) hey, we are near bug #30! (299925 currently. who'll ride the next?) happy hacking to all :) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, 17 Mar 2005 01:17:28 +0100, Matthias Urlichs [EMAIL PROTECTED] wrote: Given the pace 2.6 is progressing at, I expect there not to be a too late in the next months. However, upstream 2.6 is progressing fast. In the wrong direction. Which is a big disturbance :-( Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, 17 Mar 2005 01:10:53 +0100, Matthias Urlichs [EMAIL PROTECTED] wrote: Or packages are built by firewalled trusted build systems. What is the advantage of having a correctly maintained system behind a firewall? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Another load of typos
On Thu, 2005-03-17 at 23:20 +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: [snip] An FAQ, too (not a fack). An SQL server, not a sequel server (my pet hate). Well, you're 1/2 correct: A FAQ. An Ess Que Ell server. Thus I Have Spoken, Thus It Shall Be! ;) -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. You don't want give people a reason to not invite you to the hot parties. Pat Sajak, on being a Republican in Hollywood signature.asc Description: This is a digitally signed message part
Re: Required firewall support
* Marc Haber: I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. This is a bit dangerous because any invocation of apt-get install or apt-get upgrade can start new server daemons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
On Wed, 16 Mar 2005 14:44:34 +0100, Wouter Verhelst [EMAIL PROTECTED] wrote: Op di, 15-03-2005 te 16:19 -0500, schreef Anthony DeRobertis: Wouter Verhelst wrote: | You misunderstood. I don't fight generic changes to the order; I just | don't think it would be a good thing that any random developer could | prioritize his pet package. | Any random developer already has root on X thousand debian systems. We can trust him with that, but not with helping determine build order? I'm afraid it won't actually be 'helping'. I've seen enough of My package isn't built and it's urgent and the buildd admins suck! to expect what would happen. Aah, so the trick should be to implement this on the quiet. Tweak the values according to have it's progressing. Eventually you should see a reduction in complaints. It wouldn't be hard to be able to guarentee an upper bound for building, say two months. Once people stop complaining you can tell them. Maybe they won't feel so inclined to fiddle when they can see it works. That's not to say that a request to prioritize a package is to be ignored; however, the power of deciding which packages get built first should be with those that actually build the packages, rather than with those who want their packages to be built. The former are expected to be following the larger picture; the latter are not. As far as I can tell, buildd admins don't spend all day prioritising builds manually anyway. We're dealing with computers here, they don't care how complicated the calculations are. Decide where your priorities are and implement it. If you don't like to hear people complain, add a rule saying if package is older then one month, build it now. It cost you nothing and saves heaps of grief. As a bonus, repeatedly uploading new versions would keep resetting the counter, so they'd be encouraged to upload less. The current process of indefinitly starving extra packages is just silly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, 17 Mar 2005 13:52:23 +0100, Florian Weimer [EMAIL PROTECTED] wrote: * Marc Haber: I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. This is a bit dangerous because any invocation of apt-get install or apt-get upgrade can start new server daemons. I do not do that when I am directly on the 'net. otoh, policy-rc.d exists, but is a little clumsy to use these days (remedy is in NEW). Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Another load of typos
On Thu, Mar 17, 2005 at 06:47:09AM -0600, Ron Johnson wrote: On Thu, 2005-03-17 at 23:20 +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: [snip] An FAQ, too (not a fack). An SQL server, not a sequel server (my pet hate). Well, you're 1/2 correct: A FAQ. That's an eff ay cue. A eff is very awkward to pronounce. An Ess Que Ell server. Thus I Have Spoken, Thus It Shall Be! ;) gee thanks:) Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Key management using a USB key
Hi David, o Other issues? it might also be interesting to take a look at a OpenPGP Smartcard. I am experimenting with such a card at the moment and they are quite cool. On [1] you can take a look at the features. A HOWTO for those cards will be available in the next days. o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? I know of someone who set up a solution so the crypto partitions will not be mounted if the smartcard is not plugged in. With best wishes, Matze 1. http://www.fsfe.org/card/ -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) signature.asc Description: Digital signature
Re: Source of LPhoto
hi Andreas, On 2005-03-17, Andreas Tille [EMAIL PROTECTED] wrote: But there is no link or other sign of a downloadable source. Am I to stupid to find the source or do the people at this site have a different opinion about downloadable source than I. I wanted to issue an ITP if it is worth but wonder which link to the source I should use. I couldnt find any link, but the .changes file in their archive, so: http://software.linspire.com/emptypool//lindowsos/pool/main/l/lphoto/lphoto_2.0.42-0.0.0.45.lindows0.1.tar.gz bye - michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package priority change?
Before filing any bugs on this matter to the BTS, I'd like to check who is responsible for changing the priority of a package? Is it the ftpmasters or the package maintainer? The package in question is k3b, which should depend on cdrdao, but cdrdao is too low priority for that. So, either k3b needs to be lowered or cdrdao upgraded. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
On Thu, Mar 17, 2005 at 11:20:12PM +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: ... and probably not for (that is, not unless you tell me otherwise): HPGL HTML HTTPS Traditionally I think these would use an. Even if you pronounce h as haich rather than aich as another poster pointed out, many words beginning with h such as historic or horrendous require an in formal writing e.g. an historic achievement. (This might be a topic without a possible conclusion!) Funny, but although I'd say an HTML file or an HTTPS url or similar, I'd say a history achievement. That's right. Usually when you pronounce the letter 'haich', it's silent word-initially. When you pronounce it 'aich', it is audible at the start of the word. Or I _think_ that's the case. And at least for these words, they are all abbreviations, as none of them are pronouncable as acronyms. So they are all governed by the local pronounciation of 'H', not the local pronounciation of 'hotel'. But then we say aich not haich here. I'd say an HP printer or a historic occasion, but if I saw it written a HP printer I'd read it a haich-pee printer without qualm. And for some reason, everytime I try, I get a HTML document. So I'm not even consistent in my own usage. Probably because Australian English seems to be influenced by both British and American pronounciation, in the same way that route is understandable in either pronounciation, although then I know the linguistic background of the speaker's English. ^_^ However, this is a pronounciation rule, not a spelling rule, so it's up to the author to write it by speaking it out loud. So I consider these to the uncorrectable automatically, even from the standpoint of paragraph-internal consistency. ^_^ -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: bug count is going to hit #300000! (was Re: Bug#299919: samba-common: ...)
Hi, Domenico Andreoli wrote:
hey, we are near bug #30! (299925 currently. who'll ride the next?)
We're also near the Unix timestamp of 11, which will be at
2005-03-18 01:58:31 UTC.
Neither factoid is particularly helpful for getting Sargte's RC bug count
down. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi, Marc Haber wrote:
What is the advantage of having a correctly maintained system behind
a firewall?
Umm, multiple (different) safety guards in sequence, which the attacker
would have to overcome, are assumed to be more secure than just one.
Accidents happen. So do security advisories.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Announcing PostgreSQL 8.0 packages and a new PostgreSQL infrastructure
Howdy to all database enthusiasts! PostgreSQL 8.0 is out to the public for a few weeks now, and the amount of emails asking When can we get the debs? is increasing every day. In addition, the current structure and packaging of the existing PostgreSQL 7.4 packages became too clumsy and inflexible to be supported forever. So some time ago, Oliver Elphick and I developed a completely new architecture specification for PostgreSQL packages which allow to run several major versions in parallel (which finally resolves the upgrading hell) and to run arbitrarily many clusters (which makes the package much more interesting for e. g. web hosters or safe playgrounds). The detailled architecture description can be found at http://people.debian.org/~mpitt/postgresql-ng.html After some weeks of hacking and sleepless nights I am now proud to present the first usable set of 7.4 and 8.0 packages (in experimental) for this new structure: postgresql-version: server binaries postgresql-client-version: frontend programs postgresql-common: cluster management and frontend wrapper In addition, there are new packages postgresql, postgresql-client, postgresql-contrib, etc., which provide a smooth upgrade path: they register the existing database from the current Hoary PostgreSQL packages to the new multicluster structure, clean up old stuff and immediately start the server again. Please note that this process will install the 7.4 server/client. (Of course you can additionally install the 8.0 server and client to play around with the new version). There is still a lot of work to do. But I feel that the packages now are mature enough to be tested by a wider audience, and also to attract more developers :) Take the plunge today and upgrade, test, and give feedback! i386 debs for Sid (and source packages) are now in experimental. If you just dist-upgrade to the experimental packages, your sid postgresql package should automatically be upgraded to the new structure, your existing database should be configured (check with pg_lsclusters), the new cluster should run and psql etc. should behave as before. If you install postgresql-7.4 or postgresql-8.0 from scratch (i. e. without postgresql already installed), you should end up with a fully functional and running main cluster. If you are interested in development: the package is developed with tla (or bazaar) in the following repository: tla register-archive http://arch.debian.org/arch/pkg-postgresql/[EMAIL PROTECTED]/ The following projects are relevant for these PostgreSQL packages: postgresql--devel--7.4 postgresql--devel--8.0 postgresql-common--devel--1 postgresql-transition--devel--1 If you want to work on them, either just check them out and send me patches, or do it the arch way and branch off to your own repository and tell me where to merge from. Happy testing and databasing! Martin P.S. This is _not_ Sarge stuff. The detailled reasons are explained in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274043 -- 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: procmail and Large File Support
Am 2005-03-16 21:18:33, schrieb Ola Lundqvist: Hello Some people tend to have really large inboxes. I have had a number of customers that have several GB inbox. They tend to get quite a lot of attachments (reports etc) and do not have the time to delete mail. It will grow quite fast. You mean some of this Mailnglist like [EMAIL PROTECTED] ? Oh yes, there are some realy friendly people which had me subscribed to a couple of this Mailinglists... goten more then 18000 Messages in two weeks vacancy... around 500 kByte/message... Fortunatly I am using Maildir :-) Regards, // Ola Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: An idea from a Debian user
Evan Cox wrote: Hi Guys, I hope this is the right area to send this email. My apologies if I am wrong. If so, please forward to the appropriate area. I have fiddles with Linux distro's for approx 3 years, and found Debian 3 months ago. I adore it, and will be using debian from now on. I would like to offer a suggestion to the team about an idea for a package to add to Debian. This idea is the one feature that I feel is lacking and hope this idea aligns to your goals for Debian. My suggestion has come from frustration in trying to maintain Debian Sarge from the CLI. I am very use to some sort of system control center, for common tasks such as iptables, network connection/configuration, configuring hardware, repartitioning, or resizing hd's, backups etc. This could be quite a list but will stop there. My idea is to create a frontend program that is similar to the profile 'Midnight Commander' in Konqueror (ie screen splint into 3/4 top and 1/4 CLI) that begins with iconised area relevant to the administration task, and ends with a screen of relevant commands for the appropriate task and when appropriate some GUI features. From my point of view, a program like this would be a fantastic learning assistant in the crossover from point and click to CLI, and add a central administration section to Debian. Eg: I have formatted my hd with resizer format, and have separate partitions for /, /var, /usr, /home, /tmp and swap. I would like to see a graphic representation of the usage of my hd, and resize the partitions but fear making an error via the command line. This is where the program can help, by showing me a graph of this and suggesting what commands to use for the task. Please let me know if you want more info, or if ideas like this are a nuisance. Cheers Evan I don't know if it's useful to you, but there is a project underway to port SUSE's yast2 tool to Debian. See http://yast4debian.alioth.debian.org Regards, Stelian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am Do den 17. Mär 2005 um 14:13 schriebst Du:
o Especially on laptops, it might be interesting to also encrypt all of
/home and/or other parts of the harddrive to make the data unusuable
without the USB key. But how to integrate this with the other
requirements?
I know of someone who set up a solution so the crypto partitions will
not be mounted if the smartcard is not plugged in.
I made such a solution using cfs for my own laptop. I do that by
mounting a encrypted dir and then setting $HOME to the new home.
Unfortunable not all applications take care for $HOME. Most important
gimp or pan and some other.
I only do crypthome newhome to use it. The directory can be generated
by:
gpg --gen-random 2 16 | gpg --symmetric key.gpg
gpg key.gpg | cmkdir -b -- newhome
mv key.gpg newhome/..p
Here how I did this (part of .bashrc):
cryptmount()
{
if [ X$1 == X ]; then
echo Please specify a directory!
return 1
fi
if [ -d /crypt/$1 ]; then
echo Directory still mounted!
return 0
fi
if _testcrypt $1 $1.gpg; then
CDIR=$1
CPWFILE=$1.gpg
elif _testcrypt .$1 .$1.gpg; then
CDIR=.$1
CPWFILE=.$1.gpg
elif _testcrypt $1 $1/..p; then
CDIR=$1
CPWFILE=$1/..p
elif _testcrypt .$1 .$1/..p; then
CDIR=.$1
CPWFILE=.$1/..p
elif _testcrypt $HOME/$1 $HOME/$1.gpg; then
CDIR=$HOME/$1
CPWFILE=$HOME/$1.gpg
elif _testcrypt $HOME/.$1 $HOME/.$1.gpg; then
CDIR=$HOME/.$1
CPWFILE=$HOME/.$1.gpg
elif _testcrypt $1; then
CDIR=$1
CPWFILE=
elif _testcrypt .$1; then
CDIR=.$1
CPWFILE=
elif _testcrypt $HOME/$1; then
CDIR=$HOME/$1
CPWFILE=
elif _testcrypt $HOME/.$1; then
CDIR=$HOME/.$1
CPWFILE=
else
echo File $1 not found!
return 1
fi
if [ X$CPWFILE == X ]; then
cattach $CDIR $1
else
gpg $CPWFILE | cattach -- $CDIR $1
fi
return $?
}
crypthome()
{
cryptmount $1 || return 1
sleep 1
until [ -d /crypt/$1 ]; do
sleep 1
done
cd /crypt/$1 herehome
echo Home directory chaged to /crypt/$1.
}
Regards
Klaus Ethgen
- --
Klaus Ethgenhttp://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED]
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iQEVAwUBQjmSvZ+OKpjRpO3lAQKZgAgAg4u6ybSUfCCPMHm00fYSzsn+rLwi+/wp
h4m+W+vwdpPczYlkTxIKkmzLHXMdv0qnsUa37kijU4KdaVOvxQbsCcWdI3Z5yw9Q
lheUU06Zm6YNCJlm30Vavb+hhCxK1jGLrIAwb5AxeE4dtdBAGifjzauF9ilwOooN
Tq7Wqh27kn+v8VTsWzsqoLCBSLnn4YSnGHtTVqhkCiFWt6kMgiqzVcBLBfXdktIl
xKjNTE9Zn534G3yKcrxXY4SuUmANt+fliSt7WPPfXDgt8u6YG5cCpJQTjjXivTaC
4pm7IvpMpcY6bSqgDr5gZzeJ8tHEA7FKJOQjLFVBMelJ4Yz1EEE4PQ==
=zhfn
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Wed, Mar 16, 2005 at 07:32:37PM -0500, Ben Collins wrote: Ok, I can guarantee that it never dies. Sorry, but I do not believe you. Never is a very strong word. See http://lists.debian.org/debian-devel/2002/11/msg01926.html Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
On Wed, 2005-03-16 at 21:45 +0100, Pierre Habouzit wrote: Le Mer 16 Mars 2005 21:36, Ron Johnson a écrit : On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: Hello On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: [snip] File quotas will fix that in a hurry. that's definetely a (sorry) stupid answer. Because anyway, it feels not very sensible to use mbox flat file and not maildir for such big mailboxes ;) We agree. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. Jack Handey signature.asc Description: This is a digitally signed message part
Re: Another load of typos
On Fri, 2005-03-18 at 00:41 +1100, Paul Hampson wrote: On Thu, Mar 17, 2005 at 11:20:12PM +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: [snip] not even consistent in my own usage. Probably because Australian English Australians speak English?!?! ;) seems to be influenced by both British and American pronounciation, in the same way that route is understandable in either pronounciation, although then I know the linguistic background of the speaker's English. ^_^ Maybe not. I've heard Americans say it both ways. But Then, America is a Really Big Country. However, this is a pronounciation rule, not a spelling rule, so it's up to the author to write it by speaking it out loud. So I consider these to the uncorrectable automatically, even from the standpoint of paragraph-internal consistency. ^_^ -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Thanks to the good people in Microsoft, a great deal of the data that flows is dependent on one company. That is not a healthy ecosystem. The issue is that creativity gets filtered through the business plan of one company. Mitchell Baker, Chief Lizard Wrangler at Mozilla signature.asc Description: This is a digitally signed message part
Re: Another load of typos
On Fri, 2005-03-18 at 00:10 +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 06:47:09AM -0600, Ron Johnson wrote: On Thu, 2005-03-17 at 23:20 +1100, Hamish Moffatt wrote: On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: [snip] An FAQ, too (not a fack). An SQL server, not a sequel server (my pet hate). Well, you're 1/2 correct: A FAQ. That's an eff ay cue. A eff is very awkward to pronounce. All TLAs are wordified if possible. An Ess Que Ell server. Thus I Have Spoken, Thus It Shall Be! ;) gee thanks:) You're welcome. :P -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. The enemy thinks and plans and strategizes, too. signature.asc Description: This is a digitally signed message part
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 05:58:21PM +1000, Anthony Towns wrote: Daniel Jacobowitz wrote: My basic idea is to have something similar to the testing migration scripts, which takes the decisions of the master copy running on ftp-master as an input. At a minimum: I think it's easiest just to assume everything's on ftp-master; for mirroring, stuff's already planned to be split onto ftp.d.o and scc.d.o anyway. The only reasons that wouldn't happen is if ports need non-developers to be able to upload, or are using up lots of disk really wastefully. OK. I'm going to keep the two logically separated, to answer possible resource constraints, but it would certainly be easier this way. - Packages in sub-testing should not be newer than the versions in testing, except on purpose. Porters need to be able to use newer versions when a particular version does not work on their architecture, but I want a by-hand element involved in that. In normal, non-schedule-pressured, non-crippling-bug mode, they would just fix the copy in the main archive and propogate that to testing, and from their to sub-testing. Okay, so we've got a new suite; is that global for all scc arches, or separate, a la subtesting-s390, say? The question there is Will s390 have a different version of the package to m68k, if one or the other is being more aggressively maintained? I don't know. This depends mostly on the dynamics of the ports teams and on the amount of work it turns out to be. It may be that holding up for other architectures would be just as much a problem for the s390 mantainers as it is for the core release managers; or it may be that the overhead is too high to justify doing it for less than the full set. So, say you have foobar 1.0 in subtesting for s390, and foobar 2.0 in testing and foobar 3.0 in unstable for i386. Your buildd's been somewhat broken for a few weeks, and you haven't built foobar 2.0 or 3.0 yet, but you've got it working again now. What happens then? Do you build foobar 3.0, find out there are some s390 specific bugs, watch it go into testing anyway, not accept it to subtesting because those bugs need fixing, get 3.1 uploaded to unstable, built it, watch it go into testing, and then have it go into subtesting too? Or do you build foobar 2.0, upload your debs to unstable, find it works perfectly, and get into subtesting, then wait 'til 3.0 gets into testing before building it and finding out it has problems? Both of these are plausible; the difference is whether you autobuild from unstable or testing. I would prefer the former, which means your former case. Do you use the testing scripts, and thus aim to ensure subtesting's dependencies are consistent, or do you just copy debs across and hope? If the former, why bother looking at testing at all, instead of just pulling from unstable, and calling it, say, scc-testing-s390? OTOH, only pulling from testing makes it simpler to end up with something you could call etch for s390. Right. I'd want to use the testing scripts, somewhat brutalized. My hope for using testing as an input is that, come freeze time, the ports would be relatively close in versions to the release architectures. In particular, it would prevent them from getting ahead. The remaining differences can be patched up by hand. - Internal consistency and installability would be maintained for the sub-testing repository in the same way we maintain them for testing. This allows the port to leverage the excellent work done by the release team, and not get in their way - it's completely unidirectional, nothing feeds back to the parent repository. And it allows leverage of the testing scripts - with some changes, that someone would have to pony up the time to implement, of course. One of the problems with this is that you wouldn't benefit from the hints the release team prepares for britney; which might screw you over completely. OTOH, dealing with smaller numbers of architectures is easier, so maybe some of the existing automation would be more effective; and maybe the other britney features we planned at the meeting will make this irrelevant anyway. This is definitely a real problem. Architectures which stay very close to up-to-date might be able to take advantage of hints; I don't know how often that would work in practice. Maybe it would motivate additional work on the automation. I would really like to see some real use cases for architectures that want this; I'd like to spend my time on things that're actually useful, not random whims people have on lists -- and at the moment, I'm not in a good position to tell the difference for most of the non-release architectures. Sure. The idea is still half-baked. If it has merit, someone needs to finish cooking it... -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a
Re: RFA: dpatch -- patch maintenance system for Debian source packages
Hello Marc, * Marc Haber [EMAIL PROTECTED] [2005-03-16 15:43]: On Wed, 16 Mar 2005 22:40:33 +0900, Junichi Uekawa [EMAIL PROTECTED] wrote: Since I do care about dpatch, and I do use it a lot in my packages, I will be willing to help out / adopt this package. After organizing on IRC, Junichi and I will take over the package. Gergely has agreed, and an upload will be done in the next seven days. Why do I reply if you don't care about it? Thanks! Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpHkluhu4Pgq.pgp Description: PGP signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 09:31:12AM -0500, Daniel Jacobowitz wrote: On Thu, Mar 17, 2005 at 05:58:21PM +1000, Anthony Towns wrote: One of the problems with this is that you wouldn't benefit from the hints the release team prepares for britney; which might screw you over completely. OTOH, dealing with smaller numbers of architectures is easier, so maybe some of the existing automation would be more effective; and maybe the other britney features we planned at the meeting will make this irrelevant anyway. This is definitely a real problem. Architectures which stay very close to up-to-date might be able to take advantage of hints; I don't know how often that would work in practice. Maybe it would motivate additional work on the automation. Perhaps britney could be enhanced such that when a hint is carried out by the RM's, a notification mail is sent out to a subscriber list notifying them of the hint. This would allow for multiple subtestings to choose wheter or not they want to do the same thing. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package priority change?
On Thu, Mar 17, 2005 at 03:12:06PM +0200, Kalle Kivimaa wrote: Before filing any bugs on this matter to the BTS, I'd like to check who is responsible for changing the priority of a package? Is it the ftpmasters or the package maintainer? The package in question is k3b, which should depend on cdrdao, but cdrdao is too low priority for that. So, either k3b needs to be lowered or cdrdao upgraded. ftp-master, usually the maintainer changes the priority in the next upload, and replies to the mail regarding override discrepancies he gets, it lists the correct address to reply to. Both ftp-master and the package maintainer need to change it, but in the packages lists and everywhere where it matters, the ftp-master definition takes precedence. At the moment rules like a package may not depend on a lower priority package are violated reasonably often, and this is not a RC issue. See [1] for a list of those issues. It may be that someone is trying to come up with a list of suggestions to fix that, which could then be processed, but in the meanwhile, don't feel too bad when temporarily violating that rule for extra vs optional. --Jeroen [1] http://qa.debian.org/debcheck.php?dist=sidlist=priorityarch=ANY -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
#300000 I got it.:)
Hello, we reached #30: Bug#30: libcrypt-ssleay-perl: package description typo(s) and the like -- Nol Kthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Required firewall support
[ Please respect the list code of conduct; I don't request CCs, nor does ] [ my M-F-T get set as such. In other words, don't send them. ] On Thu, Mar 17, 2005 at 12:16:27AM -0800, Thomas Bushnell BSG wrote: Joel Aelwyn [EMAIL PROTECTED] writes: Fine, if you want to get pedantic, the following is a bare minimum of capabilities I would expect from any network processing on a 'real' (non-toy) network stack, where 'network stack' means everything between hardware driver and delivery of data to a userland application. It's late, so this may not be exhaustive. The guidelines do not speak of toy os. It appears that you are not aware of why this requirement is listed in the guidelines, nor of why it would be important for the secondary archive, nor of what the actual practice is on buildds. Can we replace this with a thread involving people who do know these things? The Hurd has had all the things listed on your schedule of filtering rules for longer than Linux has. All that is necessary is simple user-space tools to implement them. Do you have a specific tool that should run, or anything else? If you have all of the filtering rule support, then why is this even an issue? Write the user-space tool and you should be golden; you've got a useable firewalling implementation. What's the problem? Unless marked as 'nice to have', everything above is a *must* for running even basic firewall configurations on a host expected to face the Internet. If you can do those, and configure them in some semi-sane fashion, then you probably meet the expectations reasonable people would have for basic firewalling. But what is not said here is why this particular feature is necessary for being in the secondary archive, as opposed to other features. To say, a buildd must have that feature is only sensible if the buildds are actually *using* such-and-such feature, and you, in fact, don't know that they are. Allright, since your other email said it didn't have to be hooked up to the w-b network, and seemed to miss the point: To be sane to administer a system which is exposed to general Internet traffic, including through a NAT or other proxy, it is important to be able to control the policy for what traffic is actually passed to the userspace applications, or routed to another network on router-capable OSes (note that being able to route is not, AFAIK, a buildd requirement), That means firewalling capabilities. It's flat ing insane to expect DSA folks to try to keep a system secure if it doesn't have basic firewalling. It's that simple, and it's backed by a couple of decades of best common practice by both network and systems administrators. If you want to avoid this situation, then I suggest you explain how you intend to get things needing build from incoming to your buildd, and the results back to incoming. But you say you have this capability already, perhaps modulo userspace tools to configure it. So get someone to bang them out, and you should be good to go (or, heck, get the existing firewall config tools to support whatever you use to configure this, if they aren't excessively Linux-centric; at the very least, a workalike interface is a good place to start). -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach David Schmitt [EMAIL PROTECTED] [2005.03.16.1923 +0100]: * relaxing arch-specific to also be able to exclude KDE/GNOME from mips (until someone commits to properly support it for whatever reason he has) Why do we make a package foo's entry to testing dependent on whether foo has been compiled for all arches, including all dependencies? Why can't we have separate sid-testing propagation for each arch, then freeze testing as before, get rid of RC bugs, and release? Sure, the package set will differ across architectures, but they do already... I see the main advantage of this approach to put a little pressure onto the maintainers of less popular arches, who will have an interest to make things work for their arch, and thus might try to persuade others *on an individual basis* to fix their packages for arches which are currently not supported cleanly. Am I making sense? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Vore isn't down. On Thu, Mar 17, 2005 at 10:54:18AM +0100, Andreas Barth wrote: * Ben Collins ([EMAIL PROTECTED]) [050317 03:25]: On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote: Ben Collins [EMAIL PROTECTED] writes: On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: In article [EMAIL PROTECTED] you write: I have an e3500 to replace both auric and vore (and the raid), but I haven't gotten an ok from James to do so yet. That would cut the number of sparc buildds down to one, when two are required for RC archtectures under the new proposal. That's ok because two buildd's can run on the one machine. It has 6 cpu's. That cannot be the requirement. The point has to be an additional and independently functioning piece of hardware. If the disk blows or it is compromised or something, the others should be able to continue. The requirement sucks, lets leave it at that. If the machine dies, I can have two to replace it within a day or two. Ah, so why is vore down now for some time now? If it's so easy to replace a broken machine, why don't you just do it? (And, BTW, you might be on vacation, sick, ... - we need more than just one machine.) 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 -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Read my previous replies. On Thu, Mar 17, 2005 at 11:01:07AM +0100, Andreas Barth wrote: * Andreas Barth ([EMAIL PROTECTED]) [050317 10:54]: Ah, so why is vore down now for some time now? If it's so easy to that should read as auric of course. 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 -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #300000 I got it.:)
Am 2005-03-17 16:40:10, schrieb Noèl Köthe: Hello, we reached #30: Bug#30: libcrypt-ssleay-perl: package description typo(s) and the like Herzlichen Glückwunsch aus Strasbourg... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
also sprach Stephen Frost [EMAIL PROTECTED] [2005.03.16.1707 +0100]: What about requiring a binary upload with the source upload, but then rebuilding the binary on the buildd of the uploaded binary *anyway*? It would also address a security/trust problem with which some professional customers have expressed concerns: http://lists.debian.org/debian-security/2004/09/msg00014.html -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Orphaning some of my packages
Due to a severe lack of time, I've decided to orphan a bunch of my packages. They are, o hp48cc o electric o vipec o libmad o madplay o libid3tag I've filed bugs orphaning them, and have uploaded packages with the maintainer set to QA. Justification for this is that I'm spending much more time working on kernel related things now, and hacking on wpa_supplicant, and have next to no time for other Debian related things, unfortunately. Best regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
On Thu, 2005-03-17 at 16:51 +0100, martin f krafft wrote: also sprach David Schmitt [EMAIL PROTECTED] [2005.03.16.1923 +0100]: * relaxing arch-specific to also be able to exclude KDE/GNOME from mips (until someone commits to properly support it for whatever reason he has) Why do we make a package foo's entry to testing dependent on whether foo has been compiled for all arches, including all dependencies? Why can't we have separate sid-testing propagation for each arch, then freeze testing as before, get rid of RC bugs, and release? Sure, the package set will differ across architectures, but they do already... I see the main advantage of this approach to put a little pressure onto the maintainers of less popular arches, who will have an interest to make things work for their arch, This it what I see as the attitude of *some* people: It works on x86, x86-64 ppc. Who cares about lame old and/or arches like m68k, arm, hppa sparc? Thus, I foresee 1. even more disparity between the popular arches and the tiny ones. 2. difficulty with bugs. How do you close a bug, if it doesn't work on some arches? The open bug count would go even higher. and thus might try to persuade others *on an individual basis* to fix their packages for arches which are currently not supported cleanly. Am I making sense? Yes, but I disagree. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. You are wrong in thinking that I dislike wholehearted pacifism, though I do think it mistaken. What I object to is the circumspect kind of pacifism which denounces one kind of violence while endorsing or avoiding mention of another. George Orwell, 1944, in correspondence with a British pacifist signature.asc Description: This is a digitally signed message part
Re: NEW handling ...
On Thu, Mar 17, 2005 at 02:35:27AM +1100, Matthew Palmer wrote: On Wed, Mar 16, 2005 at 03:29:28PM +0100, Sven Luther wrote: Ideally we would see forming a little NEW-reviewing comittee which would facilitate the job of the ftp-masters. This is also in accordance of the small-team proposal in debian. It would be nice to have the opinion of the ftp-masters on this, if this seems credible, and if there are design issues with it. As far as a NEW-review team, when I raised this about a week ago, aj said that you'd effectively be ftpmasters, so why not be an ftpmaster? Well, it is clear that the ftp-master's job don't scale, they have admitted as much with both the delays in NEW handling and their participation in the Vancouver proposal. Now the idea was to find some way to help them along, and this may be the solution to it. Notice that they still have veto right so nothing can get past them if thet don't want. Having them take positive action to counter the NEW review team or the automated scripts may speed things up somewhat though. /me wonders what the ratio of really-new over not-new NEW packages are anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On Wed, Mar 16, 2005 at 07:56:58PM +0100, David Schmitt wrote: On Wednesday 16 March 2005 19:14, Matthias Urlichs wrote: Hi, Matthew Palmer wrote: As far as a NEW-review team, when I raised this about a week ago, aj said that you'd effectively be ftpmasters, so why not be an ftpmaster? Umm, no. I presume ftpmaster has other duties. Besides, eyeballing the new packages and drafting a list for ftpmaster to cross-read and implement isn't the same as implementing the actions directly; I suppose initially new ftpmasters would do the former until the old ftpmaster team is cnfident the new guys' (gals??) skills are up to the task. Where I am very surprised that nobody of the very vocal and oh-so-bored maintainers who have nothing else to than waiting for their NEW packages has started an effort to the latter effect: Collecting tidbits of information concerning the various packages rotting in NEW and making that information public. Without public information, there is no discussion. Without discussing those things (especially those ftp-masters have generally express their distrust by ignoring them) nothing will happen. Well, when one sees the response one get to tidbit of information send to the ftp-masters about one selfs package sitting in NEW, you should understand the discouragement that such kind of thrown-away work is. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Will Newton [EMAIL PROTECTED] writes: On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: ... and probably not for (that is, not unless you tell me otherwise): HPGL HTML HTTPS Traditionally I think these would use an. Even if you pronounce h as haich rather than aich as another poster pointed out, many words beginning with h such as historic or horrendous require an in formal writing e.g. an historic achievement. Actually, the word historic in the phrase an historic achievement is not pronounced by most speakers with a leading H even though in other contexts it usually does. Correct American English *always* puts an N when there is a consonant, and *never* puts one when there isn't, and the rule is how you actually pronounce the word, not how it happens to be spelled. The best advice for the cases which very by which side of the Atlantic you are on is to consistently pick one or the other. The best advice for the cases which depend on how you pronounce an acronym is to reword the sentence so that no reader will stumble. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: * The first rule of securing a machine exposed to the wilds is Deny by default, allow by need. Which is pretty well accomplished by only running needed services. A port without a services is an implicit deny. Sorry, but being able to cope with a hostile environment *is* a requirement in today's network, and there isn't any real way around that fact. I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. And just how full of attempts to root SSH are your logs? Just because you *can* cope with that (and there are situations where the fastest patch is to slap an ACL on, say, port 22 until you can fix the real problem, so that you neither lock yourself out of the box's remote access nor leave it open to the kiddies) doesn't mean it is the optimal method, or that DSA should be expected to work without fairly important security tools when asked to keep a box secure. Traffic control policy is a major part of layered security. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: NEW handling ...
On Wed, Mar 16, 2005 at 04:36:25PM +0100, Matthias Urlichs wrote: - check that the package names are sane, don't conflict, and aren't gratuitiously many (a -doc package for 10 kbytes of documentation...) (what's the current opinion on that, anyway?) Don't you think maintainers are big enough to know how to handle this kind of decisions ? or ask the NEW-team for help before uploading ? If the package causes problem, it could well be removed from the archive afterward or something. Now, again, this is probably something that can get automated, rules are fixed, and if they are not broken, automated NEW is applied (with a delay as always), while if they are broken, the reviewed NEW is applied. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Hamish Moffatt [EMAIL PROTECTED] writes: (This might be a topic without a possible conclusion!) Funny, but although I'd say an HTML file or an HTTPS url or similar, I'd say a history achievement. Ah, in a history achievement, you accent the first syllable of history, which provokes you to pronounce the H. In an historic achievement, the first syllable of historic is weak, and so most Americans (at least) do not pronounce the H, and so we use an. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn [EMAIL PROTECTED] writes: If you have all of the filtering rule support, then why is this even an issue? Write the user-space tool and you should be golden; you've got a useable firewalling implementation. What's the problem? Who said there was a problem? I was asking exactly what support was required. You started talking on about what was a toy os and the importance of this or that. It is, however, a very low priority for development, and the people who are likely to do the work would like to know exactly what is being asked. The secondary question, why is this important, is one that perhaps only the people who were at the Vancouver meeting can explain, and unless I've missed it, they have not. That means firewalling capabilities. It's flat ing insane to expect DSA folks to try to keep a system secure if it doesn't have basic firewalling. It's that simple, and it's backed by a couple of decades of best common practice by both network and systems administrators. Are the DSA people using firewalling features now? I can't see any indication in the config files of the machines I checked when you so confidently asserted they were, but I might have missed something. However, we are not expecting the DSA people to keep the system secure; SCC non-released arches don't need to provide developer machines. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach Ron Johnson [EMAIL PROTECTED] [2005.03.17.1734 +0100]: This it what I see as the attitude of *some* people: It works on x86, x86-64 ppc. Who cares about lame old and/or arches like m68k, arm, hppa sparc? Well, there seem to be no more than two ways to get rid of this problem: drop some architectures, or make people realise and embrace what Debian is all about. I am not in favour of the first, and the second seems utopic. So we're stuck. 1. even more disparity between the popular arches and the tiny ones. Supply and demand... 2. difficulty with bugs. How do you close a bug, if it doesn't work on some arches? The open bug count would go even higher. You don't close it, period. Or we introduce arch-dependent bugs and/or fixed-in-i386 etc tags... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
On Thu, 2005-03-17 at 18:00 +0100, martin f krafft wrote: also sprach Ron Johnson [EMAIL PROTECTED] [2005.03.17.1734 +0100]: This it what I see as the attitude of *some* people: It works on x86, x86-64 ppc. Who cares about lame old and/or arches like m68k, arm, hppa sparc? Well, there seem to be no more than two ways to get rid of this problem: drop some architectures, or make people realise and embrace what Debian is all about. I am not in favour of the first, and the second seems utopic. So we're stuck. Yup. 1. even more disparity between the popular arches and the tiny ones. Supply and demand... Yup. 2. difficulty with bugs. How do you close a bug, if it doesn't work on some arches? The open bug count would go even higher. You don't close it, period. Or we introduce arch-dependent bugs and/or fixed-in-i386 etc tags... Yup. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. I like my women like I like my coffee - purchased at above-market rates from eco-friendly organic farming cooperatives in Latin America. signature.asc Description: This is a digitally signed message part
Re: NEW handling ...
Hi,
Sven Luther:
On Wed, Mar 16, 2005 at 04:36:25PM +0100, Matthias Urlichs wrote:
- check that the package names are sane, don't conflict, and
aren't gratuitiously many (a -doc package for 10 kbytes of
documentation...) (what's the current opinion on that, anyway?)
Don't you think maintainers are big enough to know how to handle this kind of
decisions ? or ask the NEW-team for help before uploading ? If the package
causes problem, it could well be removed from the archive afterward or
something.
If you ask the ftpmasters, you'd be surprised...
IMHO it's easier not to let that kind of cruft get into the archive in
the first place than it is to clean up afterwards.
Now, again, this is probably something that can get automated
Sure. Some of it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
* martin f krafft ([EMAIL PROTECTED]) [050317 17:10]: Why can't we have separate sid-testing propagation for each arch, then freeze testing as before, get rid of RC bugs, and release? Because than the security team may need to fix 11 different source packages (or how many architectures we actually release) instead of 1. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Andreas Barth wrote: * Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]: Andreas Barth wrote: If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. I think it makes sense to shorten the list of arches we wait upon for testing migration, but I fail to see the usefulness of removing an arch from testing. If we don't wait for an arch, it gets out-of-sync quite soon, and due to e.g. legal requirements, we can't release that arch. (In other words, if an arch is too long ignored for testing, we should remove it, as we can't release it in any case.) Removing only the affected packages of that arch instead of the whole thing looks more sensible. Of course this assumes the core packages are kept in shape. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On Thu, Mar 17, 2005 at 06:43:52PM +0100, Matthias Urlichs wrote: Hi, Sven Luther: On Wed, Mar 16, 2005 at 04:36:25PM +0100, Matthias Urlichs wrote: - check that the package names are sane, don't conflict, and aren't gratuitiously many (a -doc package for 10 kbytes of documentation...) (what's the current opinion on that, anyway?) Don't you think maintainers are big enough to know how to handle this kind of decisions ? or ask the NEW-team for help before uploading ? If the package causes problem, it could well be removed from the archive afterward or something. If you ask the ftpmasters, you'd be surprised... well, as if they would reply me. IMHO it's easier not to let that kind of cruft get into the archive in the first place than it is to clean up afterwards. But they get a full $DELAY number of days to block it if it is needed. Now, again, this is probably something that can get automated Sure. Some of it. computers are about automating tasks so humans don't need to handle them. you only have to be clever enough to tell them to do it and they will do it. So, you are either overworked or clever, but not both :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFA: dpatch -- patch maintenance system for Debian source packages
On Thu, 17 Mar 2005 16:02:16 +0100, Nico Golde [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-03-16 15:43]: On Wed, 16 Mar 2005 22:40:33 +0900, Junichi Uekawa [EMAIL PROTECTED] wrote: Since I do care about dpatch, and I do use it a lot in my packages, I will be willing to help out / adopt this package. After organizing on IRC, Junichi and I will take over the package. Gergely has agreed, and an upload will be done in the next seven days. Why do I reply if you don't care about it? Excuse me? Would you care to explain what you mean? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Required firewall support
On Thu, 17 Mar 2005 10:03:15 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. And just how full of attempts to root SSH are your logs? A lot. What's the problem? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Do not make gratuitous source uploads just to provoke the buildds!
Andreas Barth wrote: * Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]: Andreas Barth wrote: If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. I think it makes sense to shorten the list of arches we wait upon for testing migration, but I fail to see the usefulness of removing an arch from testing. If we don't wait for an arch, it gets out-of-sync quite soon, and due to e.g. legal requirements, we can't release that arch. (In other words, if an arch is too long ignored for testing, we should remove it, as we can't release it in any case.) That would be understandable with the intention to release all arches at the same time. In this case the release should be at a different time *if* that arch is in a releasable state. Otherwise, it is not released. The point is that propagating to testing is very useful, and it still leaves the status of that arch to the porters. With testing there for SCC arches, it everyone will just point to the porters for that arch if there is a propagation problem. Mike
Re: Another load of typos
Hi Christian, On Wed, Mar 16, 2005 at 06:11:11PM +0100, Christian Perrier wrote: Sigh, I *knew* someone would say this..:-) Well, I may be unlucky enough for the tutorial about i18n/l10n handling for maintainers and translators I proposed at debconf to be accepted. If it is, I *will* have to write something anyway, so I guess that *this* (or an excerpt) could end up in the DR, yes May I suggest reporting your HOWTO mail as a bug in the developers reference? That way it is at least recorded somewhere. I'd do it but I don't want without permission. Greetings Torsten signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Andreas Tille | On Thu, 17 Mar 2005, Karsten Merker wrote: | | Some, maybe. Are there lots of people running servers on m68k and arm? | ^^^ | Perhaps not on m68k, but at least I do on sparc and mipsel, and I doubt | that I am the only one. | | Well, at least the Debian project itself is running some important servers | on Sparc hardware. We do? according to db.d.o, we have auric, kubrick and vore. auric has a dead RAID, kubrick is down and vore it the sparc buildd. Nothing important there? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 07:14:27PM +0100, Marc Haber wrote: On Thu, 17 Mar 2005 10:03:15 -0700, Joel Aelwyn [EMAIL PROTECTED] wrote: On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote: I am routinely running systems without any packet filtering capability on the network, and they are perfectly able to cope. They just only accept network connections for needed services. And just how full of attempts to root SSH are your logs? A lot. What's the problem? http://www.cve.mitre.org/cve/refs/refmap/source-BUGTRAQ.html Search for ssh. You didn't think those scripts the kiddies run appeared just to randomly annoy folks running SSH, did you? Yes, a local admin *can* just disable SSH when faced with a 0-hour announcement. So can a remote admin. The latter, however, is forced to choose between risk a compromise or risk waiting until the local admin can be present, if there isn't any firewall support. If there is, they can slap on a temporary ACL limiting access to port 22 to certain machines that are trusted (maybe they run a different version of SSH that isn't believed to be vulnerable, or maybe they're local to the 'remote' admin, whatever), and be reasonably confident that the script kiddies won't be able to get *to* the SSH daemon to compromise it, until a new SSH package can be built that addresses the vulnerability. There are other concerns which may apply (such as determining whether the SSH daemon has already been compromised, if you don't happen to have an active root shell on the machine in question), but the point stands. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: NEW handling ...
On 10231 March 1977, Sven Luther wrote: - check that the package names are sane, don't conflict, and aren't gratuitiously many (a -doc package for 10 kbytes of documentation...) (what's the current opinion on that, anyway?) Don't you think maintainers are big enough to know how to handle this kind of decisions ? NO. For many of them this is a clear no. Unfortunately. Automated NEW is IMO a thing we should never do. -- bye Joerg Von einem Besucher auf dem LT: Die 3 Microsoft-Leute auf Ihrem Stand müssen sich vorkommen wie 3 Mönche im Puff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
Sven Luther [EMAIL PROTECTED] writes: Now the idea was to find some way to help them along, and this may be the solution to it. Notice that they still have veto right so nothing can get past them if thet don't want. Having them take positive action to counter the NEW review team or the automated scripts may speed things up somewhat though. /me wonders what the ratio of really-new over not-new NEW packages are anyway. I've tried to find some information about it: $ grep '^td valign=top class=[se][ix][dp][a-zA-Z0-9+.-]*/td' new.html | sed 's/.*\(.*\).*/\1/' | wc 396 3964927 $ for i in $(grep '^td valign=top class=[se][ix][dp][a-zA-Z0-9+.-]*/td' new.html | sed 's/.*\(.*\).*/\1/' ); do grep-dctrl -eq -P ^$i$ ftp.fr.debian.org_debian_dists_sid_main_source_Sources echo $i does exist || echo $i does not exist; done | grep does exist | wc 69 2071415 so it seem that 69 of 396 packages are not really new in the queue the 17.03.2005 at 18:07:03(UTC) Rémi Vanicat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Quoting Torsten Landschoff ([EMAIL PROTECTED]): May I suggest reporting your HOWTO mail as a bug in the developers reference? That way it is at least recorded somewhere. I'd do it but I don't want without permission. Feel free to do so...this will probably be a good motivation for me to write down some other stuff. This should probably go somewhere in the DR after the part of the debconf templates style guide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
Hello On Wed, Mar 16, 2005 at 02:36:21PM -0600, Ron Johnson wrote: On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: Hello On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: Hello. I have several reports saying procmail does not support mbox folders larger than 2GB. Questions: OT here, but WTF are people smoking, to have 2GB mbox files? Some people tend to have really large inboxes. I have had a number of customers that have several GB inbox. They tend to get quite a lot of attachments (reports etc) and do not have the time to delete mail. File quotas will fix that in a hurry. Not necessary if they pay for their usage. :) Regards, // Ola It will grow quite fast. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Give a man a fish, you feed him for a day, teach him to fish, he gets mad at you for making him have to work so hard. -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On Thu, Mar 17, 2005 at 07:31:39PM +0100, Remi Vanicat wrote: Sven Luther [EMAIL PROTECTED] writes: Now the idea was to find some way to help them along, and this may be the solution to it. Notice that they still have veto right so nothing can get past them if thet don't want. Having them take positive action to counter the NEW review team or the automated scripts may speed things up somewhat though. /me wonders what the ratio of really-new over not-new NEW packages are anyway. I've tried to find some information about it: $ grep '^td valign=top class=[se][ix][dp][a-zA-Z0-9+.-]*/td' new.html | sed 's/.*\(.*\).*/\1/' | wc 396 3964927 $ for i in $(grep '^td valign=top class=[se][ix][dp][a-zA-Z0-9+.-]*/td' new.html | sed 's/.*\(.*\).*/\1/' ); do grep-dctrl -eq -P ^$i$ ftp.fr.debian.org_debian_dists_sid_main_source_Sources echo $i does exist || echo $i does not exist; done | grep does exist | wc 69 2071415 so it seem that 69 of 396 packages are not really new in the queue the 17.03.2005 at 18:07:03(UTC) A patch to lisa[1] that makes it order the 'new binaries' packages above the 'full new sources' would, I think, be appreciated. I know it might be hard to test the patch, but SELECT queries on the database work on merkel, so partially testing at least the 'does it indeed detect correctly whether the source is NEW or not' should be possible. Or you can install dak[2] and really try it out yourself. --Jeroen [1] http://cvs.debian.org/dak/lisa?cvsroot=dak [2] http://packages.debian.org/unstable/devel/dak -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging Freevo (PVR software)
I packaged Freevo for Debian and uploaded it some time ago. It has now seen some attention from the FTP masters, but I've since started using MythTV instead of Freevo. If anyone's interested in taking over the package and uploading it, drop me a message. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Andreas Barth [EMAIL PROTECTED] writes: * Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]: Andreas Barth wrote: If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. I think it makes sense to shorten the list of arches we wait upon for testing migration, but I fail to see the usefulness of removing an arch from testing. If we don't wait for an arch, it gets out-of-sync quite soon, and due to e.g. legal requirements, we can't release that arch. (In other words, if an arch is too long ignored for testing, we should remove it, as we can't release it in any case.) Not if each arch has it's own source tracking. And you already need that for snapshot fixes. Non release archs should be released by the porters alone (no burden to RMs) with a minimum of arch specific versions or patches. There should be a strong encouragement to remove software instead of patching it when it comes close to the actual release so when the port does release (after the main release) it is based on stable source for everything but last minute flaws in essential packages. Maintaining those patches in case of security updates or for the point releases again should lie with the porters. The reason why I favour this is that I have in mind that some archs will be too slow, they won't be able to keep up every day. But given an extra month they can compile the backlog or kick out out-of-sync software and release seperately with a nearly identical source tree. The remaining source changes can (and basically must for legal reasons) be contained on the binary CD/DVD set and in a branch of the scc.d.o tree. Take for example m68k. It will always be at risk of lagging a few days behind because some packages do build a few days. It is always out-of-sync longer than the other archs but it is not getting worse, it is just a step behind. That is totaly different than arm or s390 taking a deep dive getting some 300+ package backlog and having packages stuck for a month. If an arch has enough developers on it to keep stuff building, and that means supplying patches to unstable fast and early enough to get them into testing and ultimately stable I see no reason why the arch shouldn't release. Make some rule to limit out-of-sync, say no more than 1% sources differences to stable for the release. Any problems with that? 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 MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
On Thursday 17 March 2005 02:59, Quanah Gibson-Mount wrote: That's for sure but I want to be able to do automatic upgrades for the simple cases. And at least help the admin by dumping the directory before starting the upgrade and taking care of the old database files in case he decides to downgrade again later :) I don't think there is a simple case. ;) I serve ~1500 Users via nss-ldap and friends from OpenLDAP only using additional indices and schema-enhancements. Then again I also regenerate the whole LDAP tree every night from the enterprise RDBMS making me too no big candidate for automatic upgrades. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
Daniel Jacobowitz wrote:
[snip]
Okay, so we've got a new suite; is that global for all scc arches, or
separate, a la subtesting-s390, say? The question there is Will s390
have a different version of the package to m68k, if one or the other is
being more aggressively maintained?
I don't know. This depends mostly on the dynamics of the ports teams
and on the amount of work it turns out to be. It may be that holding
up for other architectures would be just as much a problem for the s390
mantainers as it is for the core release managers; or it may be that
the overhead is too high to justify doing it for less than the full
set.
I think subtesting should be done per-arch (for mips{,el}: per two-arch :-)
because the focus is different. S390 probably wouldn't care much about
a broken libusb but regards PostgreSQL as important; while for arm it
would be inverse. Broken would mean in this context rc-s390,
won't care means to remove it from subtesting-s390.
[snip]
Both of these are plausible; the difference is whether you autobuild
from unstable or testing. I would prefer the former, which means your
former case.
Autobuilding from testing won't work well AFAICS, as it introduces
another delay until rc-arch bugs are found. Building packages with
generic RC bugs and ignore them for subtesting seems to be the lesser
evil.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
On Thu, 2005-03-17 at 20:12 +0100, Ola Lundqvist wrote: Hello On Wed, Mar 16, 2005 at 02:36:21PM -0600, Ron Johnson wrote: On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: Hello On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: Hello. I have several reports saying procmail does not support mbox folders larger than 2GB. Questions: OT here, but WTF are people smoking, to have 2GB mbox files? Some people tend to have really large inboxes. I have had a number of customers that have several GB inbox. They tend to get quite a lot of attachments (reports etc) and do not have the time to delete mail. File quotas will fix that in a hurry. Not necessary if they pay for their usage. :) Well, I gotta give you that... -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. I haven't committed a crime. What I did was fail to comply with the law. David Dinkins signature.asc Description: This is a digitally signed message part
Re: NEW handling ...
On Thursday 17 March 2005 01:19, Matthias Urlichs wrote:
Hi, David Schmitt wrote:
Collecting tidbits of
information concerning the various packages rotting in NEW and making
that information public.
A list of packages-in-NEW is available on the Web, including binary
package names, bugs closed, et al.
Nothing more can be done by the average bored DD, since they cannot access
these packages, hence not do most of the necessary checks.
Isn't there a mirror of NEW on merkel?
To demonstrate what I mean, I'll take a look at the oldest packages and
collect whatever tidbits I think are necessary to decide on them:
rte (3 years): discussion on debian-legal[1] ended without answer to James
Troup question about details:
http://lists.debian.org/debian-legal/2001/10/msg00090.html
Legal status: Package DFGS-free, possibly patent-encumbered, Need checking of
video MPEG layer-2 encodings status.
kernel-linux-experimental-* (1 year): Long discussion with Maintainer in the
ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220401
Maintainer didn't answer on ITP-ping. May rot in peace.
kernel-patch-2.4-{blooper,pom} (1 year):
* Fixes for minor annoying kernel bugs
* Netfilter patch-o-matic patches to base level, IPSEC policy match
Both should be superceded by debian-kernel. Could be REJECTed.
And so on and so on. While everyone has to decide on a case-by-case basis how
to interpret this, it is a much better foundation to reason about the
packages stuck in NEW.
After collecting the obvious bits, the maintainers or available
sub-mailinglists can be pinged as it is already done with ITPs to get their
take of the matter.
For the much smaller list of packages where there still can't be any reason
found, the list can be postet to debian-devel for further perusal. But I
doubt that this list will be very long or contains packages that are very
old.
Regards, David
[1] easily found by searching for rte and debian-legal on google.
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir ber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: post-sarge transitions: slang
On Cad, 2005-03-16 at 02:33 -0800, Steve Langasek wrote: Hi Alastair, On Mon, Mar 14, 2005 at 12:30:58PM +, Alastair McKinstry wrote: * Steve Langasek | If you are planning any other transitions that will affect a lot of | packages, please let us know in advance. We will need to complete the | larger transitions as fast as possible, to get testing back into a | nearly releasable state quickly again after the release. Whats a large transition? I'm working on slang1-slang2 in a private repository; around 20 or so packages depending on it. Currently slang2 is in pre-release; I'm working with upstream to merge Debian patches into it, and building all slang1 dependencies against it. Expect patches in BTS two weeks after sarge releases. slang should, I hope, be a fairly small change; OTOH, we seem to still have conflicting slang1 and slang1a-utf8 packages in the archive (conflicting -dev packages at least), so it would certainly be nice to wrap this up and only have to carry one version of this core library for etch. Yes. Upstream has rewritten slang's unicode support, so there will only be one slang2 package going forward. Also, I am planning on obsoleting console-tools and console-data and transitioning to kbd; again, small but base change; see code ASAP to test for breakages. Any chance of getting to see this in experimental first? Yes. Thanks, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: However, we are not expecting the DSA people to keep the system secure; SCC non-released arches don't need to provide developer machines. I do not believe that this is limited to debian hosts. If an OS lacks the basic security features needed to safely stay on the internet then I think it's obvious that it's not mature and useful enough to be worth keeping it in the archive. -- ciao, Marco signature.asc Description: Digital signature
Re: RFA: dpatch -- patch maintenance system for Debian source packages
Hello Marc, * Marc Haber [EMAIL PROTECTED] [2005-03-17 21:45]: On Thu, 17 Mar 2005 16:02:16 +0100, Nico Golde [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-03-16 15:43]: On Wed, 16 Mar 2005 22:40:33 +0900, Junichi Uekawa [EMAIL PROTECTED] wrote: Since I do care about dpatch, and I do use it a lot in my packages, I will be willing to help out / adopt this package. After organizing on IRC, Junichi and I will take over the package. Gergely has agreed, and an upload will be done in the next seven days. Why do I reply if you don't care about it? Excuse me? Would you care to explain what you mean? I just asked too to be a part of the maintainer team for dpatch. regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgphvwicQNzPv.pgp Description: PGP signature
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Thursday 17 March 2005 00:21, Adrian Bunk wrote: On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote: libraries transitioned is a big point against testing: Transitions of API-compatible libraries are a pain _only_ due to testing. In unstable, such a transition can easily be done within a few days. Which leaves one with the problem that the new library might break any or all of the depending packages, which testing would catch, while transitioning unstable might not. But I have to admit that I didn't follow debian development as closely as I do now in the times before testing and thus might be arguing against the wind. Perhaps the best would be to prepare the transition beforehand in experimental and push the packages together into unstable, like GNOME and KDE did their respective last big updates? This also would be a step towards reducing dependency on work from the central teams. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: arch-specific packages and the new SCC requirements
On Wednesday 16 March 2005 20:12, Thomas Bushnell BSG wrote:
What would really win, of course, is Architecture: !hurd-i386. But
negative declarations are currently not yet supported. They should
be.
Research the problem (especially on
http://lists.debian.org/debian-{dpkg,release}/, but also include dak,
britney, w-b and whatever else there looks at the Arch: field) and create a
wellformed patch. I'm sure that would be very appreciated.
Don't expect your first version to be wellformed.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
