Re: Snort: Mass Bug Closing
* Marc Haber ([EMAIL PROTECTED]) [030826 16:05]: On Mon, 25 Aug 2003 09:24:41 +0200, Magnus Ekdahl [EMAIL PROTECTED] wrote: For users without an internet connection Marc Haber maintains the clamav-data package which includes a static database. As well as the clamav-getfiles package to update it from a computer with internet access. And daily, untested packages are built automatically on gluck and are aptable from deb http://people.debian.org/~zugschlus/clamav-data/ / Add a debconf-question about adding this to sources.list? 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
Accepted netpbm-free 2:9.25-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 21 Aug 2003 17:25:56 +0200 Source: netpbm-free Binary: netpbm libnetpbm9 libnetpbm9-dev Architecture: source i386 Version: 2:9.25-1 Distribution: unstable Urgency: low Maintainer: Andreas Barth (sponsored by Steve McIntyre) [EMAIL PROTECTED] Changed-By: Andreas Barth [EMAIL PROTECTED] Description: libnetpbm9 - Shared libraries for netpbm. libnetpbm9-dev - Development libraries and header files. netpbm - Graphics conversion tools. Closes: 150815 187395 196852 199047 204890 206162 Changes: netpbm-free (2:9.25-1) unstable; urgency=low . * moved to alioth, new maintainer, and found a way to handle upstream (this means that from now on we're treating netpbm-free as a native package) * pnmnorm replaces pgmnorm, pamoil replaces pgmoil * Uses POSIX-compatible commands. Closes: #204890 * Documentation bug. Closes: #199047, #206162 * Defaults to a fillorder at tifftopnm. Closes: #150815 * Build-dep libpng10. Closes: #196852 (for woody: change this yourself back) * Speed up pnmscale with =256 colors. Closes: #187395 * Rewrote upstream Makefiles in a a bit more sensible way. * removed jbig support due to patent issues. Files: b85ba06b160c504fc20ab1e9ec9f4fa9 686 graphics optional netpbm-free_9.25-1.dsc 92a2e19e47e499943a628ff503026947 1893777 graphics optional netpbm-free_9.25-1.tar.gz 85cd1ead71abadf3926742962c91a9ae 1130472 graphics optional netpbm_9.25-1_i386.deb 43f2468e48bef0dff8173a38d3a47f20 65862 libs optional libnetpbm9_9.25-1_i386.deb 8cdf7b242c6481c8572d4117ed30d66c 104212 devel optional libnetpbm9-dev_9.25-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Sp9kfDt5cIjHwfcRAvtGAJwN9tgpM1cW6Uho1txCzjcwUhZKtACgofi3 tQieNkkQC0o55jTMjdlpLVg= =CkSu -END PGP SIGNATURE- Accepted: libnetpbm9-dev_9.25-1_i386.deb to pool/main/n/netpbm-free/libnetpbm9-dev_9.25-1_i386.deb libnetpbm9_9.25-1_i386.deb to pool/main/n/netpbm-free/libnetpbm9_9.25-1_i386.deb netpbm-free_9.25-1.dsc to pool/main/n/netpbm-free/netpbm-free_9.25-1.dsc netpbm-free_9.25-1.tar.gz to pool/main/n/netpbm-free/netpbm-free_9.25-1.tar.gz netpbm_9.25-1_i386.deb to pool/main/n/netpbm-free/netpbm_9.25-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: stack protection
* Milan P. Stanic ([EMAIL PROTECTED]) [030825 16:50]: On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote: On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote: Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. What should be done for the few years that we probably have to wait for such programs to be written? There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note just some. They are not 100% secure, but they are more secure than software written by ISC. ftp is deprecated. (I do usually recommend WebDAV as non-anon-ftp-replacement and http as anon-replacement.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: stack protection
* Milan P. Stanic ([EMAIL PROTECTED]) [030823 11:50]: On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote: Allowing the system administrator to write to /dev/mem as part of debugging the kernel is a feature. UID 0 must have rights to do everything. root can format filesystem, by mistake or by intention. Can you explain that to me why? Why must there be a user id that can do everything? (The only thing UID 0 can't do is to exclude itself from access to a piece of the system.) Why is it necessary that UID 0 can tamper with kernel space in cirumvention of the interfaces from the kernel on a production system after startup? Why is it necessary that the same UID that can bind to low ports can also read any files? It's convinient that UID 0 can do that at startup, at development, at debugging or at system initalization. But not in a running production environment. Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix security sucks is a bug. The problem isn't with UID 0, but with bugs in software. Why does each server need to be started by UID 0 and therefor the startup programm can do everything? Why does my news server need root, or a dhcp server, or ...? I can't understand that. I do understand that it is easier to have an almighty UID 0. But I really would like a system where the existence of UID 0 is no longer necessary but optional. I think that the problem cannot be solved in wrong place. It isn't possible to have secure DHCP server by fixing kernel, but by writing secure (OK, with less bugs) DHCP server. I've never seen a programm that's really secure. There are programms with more bugs or with less bugs. So it's always strictly necessary to make programms fail safe, so that failing does as less harm as possible. A error in a dhcp server should just make dhcp fail, and have no negative impact on security. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: GR: Disambiguation of Section 4.1.5 of the constitution
I would suggest a small modification: * Manoj Srivastava ([EMAIL PROTECTED]) [030822 07:05]: + 5.2 Initially, the list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers provided they agree with a 3:1 majority. + 5.2 The list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers only by changing this clause, which needs + according to 5.1 a 3:1 majority. Advantage: This makes the list in 5.2 the authoritative list, which makes it easier later to see which documents are in fact foundation Documents. (Or to speak in computer slang: normalization of data.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Patents, gimp-nonfree and LAME
* Jose M. Fdez ([EMAIL PROTECTED]) [030822 21:05]: Patent on LZW algorithm expired so the support for GIF and TIFF images is now back in the main Gimp package. I hope this is not true, otherwise it would be a RC-bug. According to http://www.gnu.org/philosophy/gif.html the unisys patent | does not expire in most of Europe until 18 June 2004, in Japan until | 20 June 2004 and in Canada until 7 July 2004. (It is expired in the US.) (That is the cause why ppmtogif will stay in netpbm-nonfree until 7 July 2004, so it's not in netpbm-free at sarge release.) Cheers, Andi - netpbm maintainer - -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: stack protection
* Goswin von Brederlow ([EMAIL PROTECTED]) [030822 22:15]: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. According to http://www.kroah.com/linux/talks/ols_2003_udev_talk/ http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Kroah-Hartman-OLS2003.pdf this is very small. But - I'm not even near a kernel expert. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Matt Zimmerman ([EMAIL PROTECTED]) [030806 22:20]: On Wed, Aug 06, 2003 at 03:16:12PM -0400, Nathanael Nerode wrote: If these people are being delayed for a reason, the reason needs to be written down publically in the appropriate place. I disagree; if the applicant knows why they are being delayed, then the fact that this information is not published on the website does not indicate that the process is broken. According to the mails I get from more than one applicant they're not always informed to the causes of the delays. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Goswin Brederlow ([EMAIL PROTECTED]) [030806 05:35]: Kalle Kivimaa [EMAIL PROTECTED] writes: BTW, has anybody done any research into what types of package maintainers tend to go MIA? I would be especially interested in a percentage of old style DD's, DD's who have gone through the NM process, people going MIA while in the NM queue, and people going MIA without ever even entering the NM queue. I'll try to do the statistics myself if nobody has done it before. And how many NMs go MIA because they still stuck in the NM queue after years? Should we ask them? :) Many. While cleaning up the ITPs/RFPs I asked many packagers about the status of their package and got quite often a package is more or less ready, but I'm waiting of DAM-approval because I don't want the hassle of another sponsored package, or, what's worse a package was ok some time ago, but as Debian doesn't want me I stopped fixing it. Sad. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Tollef Fog Heen ([EMAIL PROTECTED]) [030806 11:20]: * Adam Majer | My definition of MIA for DD: Doesn't fix release critical bugs for | his/her package(s) within a week or two and doesn't respond to | direct emails about those bugs. I guess I'm MIA, then, since I have an RC bug which is 156 days (or so) old, which is waiting for upstream to rewrite the program. It seems to me that you're responding to emails. ;-) (But: It seems usefull to me if a maintainer is writing status to each RC-bug within two weeks if the bug isn't closed; however, up to six weeks are acceptable once in a while, e.g. because of holidays.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Matt Zimmerman ([EMAIL PROTECTED]) [030806 14:50]: On Wed, Aug 06, 2003 at 04:56:59AM +0200, Goswin Brederlow wrote: I know of several DDs and non-DDs thinking about creating a Debian2 (or whatever named) project due to this and other lack of responce problems and the group is growing. The danger is already there and should not be ignored. Why is this a danger? This is one of the freedoms provided by free software, which we work hard to promote. Because it would be a waste of work, time and energy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Matt Zimmerman ([EMAIL PROTECTED]) [030806 16:20]: On Wed, Aug 06, 2003 at 03:56:34PM +0200, Marc Haber wrote: But splitting the entire project is a freedom I would hate to see exercised. In my opinion, things that threaten a project split to happen should be avoided before the split happens. Debian can't please everyone, any more than other projects can. That is why there are choices. Certainly it is good that the freedom of choice exists. However, it is even better if no-one sees a need for doing the split. That doesn't reduce the necessity of having the freedom of choice 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
Re: NM non-process
* Matt Zimmerman ([EMAIL PROTECTED]) [030806 16:20]: On Wed, Aug 06, 2003 at 03:33:38PM +0200, Andreas Barth wrote: * Matt Zimmerman ([EMAIL PROTECTED]) [030806 14:50]: Why is this a danger? This is one of the freedoms provided by free software, which we work hard to promote. Because it would be a waste of work, time and energy. Not if the projects have different goals. I haven't seen different goals from debian, but just frustration. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NM non-process
* Josip Rodin ([EMAIL PROTECTED]) [030806 18:35]: Heh :) If I hadn't responded to it manually, it would have gotten ignored as spam (nobody cared enough to write a nice formail -r message because it happens rarely enough and the spambounces would waste us more resources). [policy of d-d-a] Yes, I can see the problem. However, it would have helped me much if this policy would have been clearly stated at http://lists.debian.org/debian-devel-announce/ (should I open a bug, or can it be fixed without?). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: About NM and Next Release
* Noah L. Meyerhans ([EMAIL PROTECTED]) [030806 19:20]: In fact, I believe the whole DAM process would be more effective if we *required* that you made non-trivial contributions to Debian *before* the DAM would create an account for you. I second. At cleaning up wnpp I saw more than once mass filled ITPs by a person hoping to get DD (the last is only assuming), and that were then retitled by QA any time later and are now about to be closed. It's IMHO not the optimal way to get a DD in filling two ITPs, uploading both packages and then expect to become a DD immediatly. Additionally (strictly my opinion here, others will undoubtedly disagree), I believe that Debian's long release times are caused by it being too big, rather than not big enough. Mostly true. It's true for the next web immage gallery, but if someone is adding e.g. a language teaching software this would really be a good contribution. (I'm not speaking in opposit to adding another web image galery. But if the galery has any non-trivial bugs I personally would encourage developers to work on other items, and rather drop the code, except it has addworthy features compared to all other programms. However, as long as anyone volunteers to keep the package in a good state, and it doesn't put burden on debian, it's ok to keep it.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: debconf 2005 in Vienna, Austria
* Matthias Urlichs ([EMAIL PROTECTED]) [030803 08:35]: A few years ago in Germany there was a huge stink raised by the environmentalists (rightly so, IMHO) because the mid-range trains running on nonelectrified trains sometimes ran with two Diesel locomotives so that the coffee machines in the train bistro could get enough juice. :-/ This is still valid, e.g. on Munich - Zürich, as the German goverment declines to electrify this line (and also declines to let the Swiss do it). But we're now heavily off-topic. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: CUPS should be the default print service in Debian/Sarge
* Joe Wreschnig ([EMAIL PROTECTED]) [030802 10:05]: CUPS is configurable via ordinary text configuration files like most Unix programs, a web interface (which is what I use), GNOME or KDE frontends, probably a number of miscelleaneous toolkit frontends, too... Personally, I'm surprised there's still people with printers who *haven't* tried CUPS. For the vast majority of situations, it's incredibly easier to configure, and usually more reliable about output, than lprng. I failed configuring CUPS for my rather simple setup here, and so I switched to LPRng. (Perhaps the HOWTO for the text interface was just too bad, I don't know. Printer is a HP Laserjet 4L, and CUPS is that of woody. LPRng did go to working instantly.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: debconf 2005 in Vienna, Austria
* Sven Luther ([EMAIL PROTECTED]) [030731 11:20]: On Thu, Jul 31, 2003 at 10:22:34AM +0200, Oliver Kurth wrote: There is also a direct night train, takes 9:30 hours. Just look at http://www.bahn.de. But trains would be much more expensive, i think, than a common (full) bus. Prices for groups in trains have remarkable dropped in the last years. But - nobody knows what 2005 will be, as the carrier Deutsche Bahn makes fundamental changes to their price system every half year. Well, there is no need to make a decission on the means of transportation now. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: lvm2 maintainer needed
* Wichert Akkerman ([EMAIL PROTECTED]) [030728 21:32]: Is anyone willing to maintain lvm2? Its last upload was over a year ago and its listed maintainer does not seem to be a Debian developer according to db.debian.org . According to packages.qa.d.o was the lastest upload in 2003 (though it is strange that the Date in the changes says something of 2002, but the version number ensures that it was 2003). Above all, did you try to reach the maintainer by private mail first? Not being a DD is not a cause to not be asked. (Though the both RC-bugs should be fixed soon.) And: If you searched e.g. by google, you would have noticed his new mail adress [EMAIL PROTECTED], and that he still is activley maintaining debian packages (I needed less than one minute for that). Perhaps you should read Chapter 7.4 of the developers reference. Even if a maintainer is MIA, you should post to debian-qa first according to reference, and this maintainer is not MIA. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Why back-porting patches to stable instead of releasing a new package.
* Luca - De Whiskey's - De Vitis ([EMAIL PROTECTED]) [030723 14:35]: ... said that your points are good, it may be useful to define a forum for the discussion of cases like phpgroupware or snort. In the end i whould say that there must be a general behaviour, but we should leave space for discussion: packages are not all the same. I don't like the pessimistic approach of saying we discourage: i would rather say that the behaviour described in Policy/developers-reference are trusted, solid but general, and that some particular cases may be discussed on debian-whatever list. Than a normal user can't rely on a specific behaviour of debian. No, what I would like more is an special distribution stable-updated where applications could be added in cases where it is _very_ usefull to put them there. But what I would like more is if we get out sarge soon. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Why back-porting patches to stable instead of releasing a new package.
* Jesus Climent ([EMAIL PROTECTED]) [030723 18:50]: On Wed, Jul 23, 2003 at 04:45:54PM +0200, Andreas Barth wrote: That applies to data-files (or very similar things) like spamassasin. There should be in the README.Debian given a location for the backport by the maintainer. Spamassassin needs more than data files, since the rules relay on funtions only available in the new spamassassin perl modules, so a backport is a hell lot of a backport, if even can be called like that since in most cases is a complete rewrite. I spoke of functional data-files, that means: packages where the package has not (only) code, but much of the value is data. At spamassasin this _is_ the case with the spam-detecting-code. _If_ the maintainer thinks he should giv woody-users regulary a new version of this package, than he should be able to do this (e.g. via a line in the README-file). This doesn't break anything, and users using this package (should) know that they're leaving the guarded place of debian stable. But I want to emphasize that getting nearer a new stable release would be much better than discussion how to allow users to use updated applications in stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#200163: ITP: png2ico -- command-line PNG to ICO converter
* Artur R. Czechowski ([EMAIL PROTECTED]) [030708 19:50]: On Tue, Jul 08, 2003 at 06:21:39PM +0100, Thomas Thurman wrote: ppmtowinicon in the netpbm package which works beautifully. http://bugs.debian.org/200332 There was Cc: to debian-devel. Perhaps you should read the referenced bug reports and discussion on d-d. The title of 200332 is ITA: netpbm -- Graphics conversion tools. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Close old RFP/ITPs?
* Petter Reinholdtsen ([EMAIL PROTECTED]) [030707 01:05]: I have several packages which I am interested in getting packaged, but I am neither the requester nor a reader of debian-wnpp. Your assertion is thus wrong in at least one case. I believe it would be a bad idea to close RFPs just because no one responds when you ask for it. I use a script to keep track of the progress of the packages I am missing, and it will not detect new comments in the BTS entry. Be assured, I took the answers here serious, and I will look into each RFP whether it is still usefull before doing the next step (that is sending mail asking for other opinions). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#200332: O: netpbm -- Graphics conversion tools
* Steve McIntyre ([EMAIL PROTECTED]) [030707 16:20]: I realise that I may have just put off anybody who might have taken netpbm, but I wouldn't want to see people pick it up expecting an easy job. We might even be better off dropping the whole package completely, but for the fact that it has quite a lot of dependents. As you said, we should make at least a silent transition. IMHO we should split netpbm to a netpbm-legacy (to where all the programms are transfered) and then substitut the programms on a step-by-step basis with wrappers to usable[1] programms in netpbm-* (or already existing) packages). [1] usable means: have usable licences and a manpage. This would also mean that bugs to netbm are usually not fixed, and new versions not integrated in debian. As speaking alone doesn't help I have ITAed netpbm. 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
Anyone to adopt LingoTeach - a language teaching programm?
Hi everyone, LingoTeach is a language teaching programm, and a debian package is available - but the original maintainer is not going to maintain it any more because he changed off debian. A language teaching application would be a rather cool thing to have, so I would like the inclusion (but I have too many projects right now on my hands to maintain it myself). The last changes are from April on sid, so it's much newer than a lot of packages. The official description is | LingoTeach is a language teaching application, uses GTK2 and teaches | English, German, Chinese and Spanish. There is sound, too. Well, does anyone stand up for this cool application? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
* Thomas Viehmann ([EMAIL PROTECTED]) [030705 23:50]: So why is the recommendation against skipping the ITP to aviod problems in ftpmaster review not right? A (strong) recommendation for doing ITPs right is right and usefull. But - all foreseeable problems should be handeled at ITP-time, and that's not the case. So the recommendation is right, but it doesn't solve the problem Marc spoke of. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
* Thomas Viehmann ([EMAIL PROTECTED]) [030705 09:35]: Marc Haber wrote: Well that's the purpose of ITP-bugs against wnpp I think, because they are CC'd to debian-devel for public review. Please show me a single ITP bug number where ftpmaster has said this package will not go into the archive, I will reject it on upload. There's numerous ITPs where e.g. licensing (seems to be a main issue with ftpmaster) has been discussed (the last I recall is #199874 dated 2003-07-03). Andreas Tille, who critized the license in #199874 is according to http://www.debian.org/intro/organization not ftpmaster. So ... If you're too cool to do proper ITPs then don't complain about the debian processing for new packages not working for you. ... is not right. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
* Colin Watson ([EMAIL PROTECTED]) [030705 10:50]: On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote: Additionally, I would like to seriously propose establishing a pre-upload interface to ftpmaster so that a developer could learn that he is writing a package pending rejection after upload _before_ spending time on building that package. I find it disturbingly impolite to say sorry, we don't want your volunteer work _after_ the work has been done. So, let me get this straight: you think that if a volunteer does some work then it should be accepted into Debian unconditionally? No matter what? Because that's what you seem to be saying. Marc is doing it the other way: He want an interface to reject a package before substantial work has been spent on it. So there shouldn't be this conflict any more, which would be a good thing. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
* Colin Watson ([EMAIL PROTECTED]) [030705 12:05]: On Sat, Jul 05, 2003 at 11:08:04AM +0200, Andreas Barth wrote: * Colin Watson ([EMAIL PROTECTED]) [030705 10:50]: On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote: Additionally, I would like to seriously propose establishing a pre-upload interface to ftpmaster so that a developer could learn that he is writing a package pending rejection after upload _before_ spending time on building that package. I find it disturbingly impolite to say sorry, we don't want your volunteer work _after_ the work has been done. So, let me get this straight: you think that if a volunteer does some work then it should be accepted into Debian unconditionally? No matter what? Because that's what you seem to be saying. Marc is doing it the other way: He want an interface to reject a package before substantial work has been spent on it. So there shouldn't be this conflict any more, which would be a good thing. That's pointless, I think. If I were an ftpmaster I would not be willing to render an opinion on a package before I actually saw the package, especially if I were going to be held to that opinion later (and, if I wasn't, what's the point)? There are several reasons why a package could be rejected. Some are global reasons (means: independent of the way the maintainer packaged) and some are local, e.g. sloppy packaging, abusing scripts or pointless descriptions. The discussion is only about global reasons, as wrong license, we don't need this package or simmilar. This reasons could be discussed before making the package quite as easy as afterwards. 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
Close old RFP/ITPs?
Hi, is it usefull/ok to close old RFP/ITP-entrys? old means for me more than year since the last mail for ITP, and 2 years for RFP. Of course I would write mail first whether the package is still wanted or if the packaging is still in order, and only close if no answer for a month. Comments? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Close old RFP/ITPs?
* Sam Hocevar ([EMAIL PROTECTED]) [030705 14:50]: On Sat, Jul 05, 2003, Andreas Barth wrote: is it usefull/ok to close old RFP/ITP-entrys? old means for me more than year since the last mail for ITP, and 2 years for RFP. Of course I would write mail first whether the package is still wanted I do not think old RFPs should be closed, at least on the sole basis that they are old. Even if the submitter is no longer interested, other people may be, and there is no way to know how many they are. A clean-up is probably needed though, for instance #186174 (xyzzy) is a rather silly RFP, it should at most be a wishlist bug for whatever console games package we have. It's much more difficult to make an cleanup on a not formal criterium, and almost impossible for myself. However, if I ask in mail this mail would also be forwarded to debian-wnpp, and any reader there could answers that a package seems usefull and therefore the RFP should not be closed. So I think this is fair enough and if neither the original requester nor any reader of debian-wnpp sees need for a package it really doesn't need to be packaged any more. To Marc: You are right, ITPs should be treated as RFPs in this case and retitled accordingly. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
* Mark Brown ([EMAIL PROTECTED]) [030705 16:05]: On Sat, Jul 05, 2003 at 02:56:30PM +0200, Josip Rodin wrote: OK, so basically you think ftpmaster people should spend review each ITP for such global rejection reasons, then? You can't expect this to happen in any remotely timely fashion, at least not with this many ftpmasters and this many hours in a day. Not to mention that it's still possible that a package may have a problem which is not obvious until the package is seen. Nobody said that ftpmaster must see all problems from ITP. But - every problem that is seen at ITP time saves volunteer time for more usefull things. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: 469 packages still using dh_undocumented, check if one is yours
* Goswin Brederlow ([EMAIL PROTECTED]) [030704 05:35]: I came accross some sources still using dh_undocumented so I did a quick search through sids *.diff.gz files. Here is the result: [...] libapache-mod-dav You must have done something wrong as since 1.0.3-6 dh_undocumented is not longer used by libapache-mod-dav. (And 1.0.3-6 is also in sarge for a while now.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: 469 packages still using dh_undocumented, check if one is yours
* Bernd Eckenfels ([EMAIL PROTECTED]) [030704 20:50]: On Fri, Jul 04, 2003 at 07:24:20PM +0200, Artur R. Czechowski wrote: OTOH, maybe dh_undocumented should be removed from debhelper with prior notice? This program does nothing and should no longer be used. well, this would break compatibility. IMHO i think it is enough to add a lintian check (well, i guess this is already the case) and add a todo on the package overview page. It _is_ already the case, also for linda. And you can get results quite easy from http://lintian.debian.org/reports/Tlink-to-undocumented-manpage.html So no need for a extra tool. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Counter-Proposal: Architecture Versions and Architecture Features
* Julian Mehnle ([EMAIL PROTECTED]) [030627 21:05]: I understand that the your proposed extensions to the Debian package system are based on the concepts of sub-archs and meta-sub-archs (I'd call these pseudo-sub-archs or alias-sub-archs, though). I have already proposed a more genereal extension based on arch versions (essentially equivalent to sub-archs, except that an order is implicitly defined), and features. I'll explain it in more detail, because I think that a more general approach would also be more flexible for potential future requirements in the Debian package system. Thanks for your proposal. IMHO it is important that we are going to adopt one or the other proposal rather soon, so that it could be used in sarge. I think both proposals have their specific advantages, and we must try to combine these. Now to comments: Every base arch (alpha, i386, mips, ...) can, but isn't required to, have one or more explicit versions (as I said, these are equivalent to sub-archs). An arch version gets appended to the base arch name as .version, the default version being 0. Thus, i386 would be equivalent to i386.0, and subsequent versions could be i386.1, i386.1foo, i386.2, and so on. Arch versions are ordered alphabetically, with higher versions including the functionality of all lower versions, i.e. higher arch versions must be downwards compatible. Example: i386 = i386.0 i386.1 i386.1foo i386.2. The problem with this is: It works only if all relevant processor makes can be seen as a chain by inclusion, i.e. there is only one heir to each processor version. However, with AMDs Opteron on one side and the certainly next Intel processor on the other side there will be two childs with different features, so this fails. You can of course make it with Independently, every arch can, but isn't required to, have one or more special features beyond what the base arch version supports. A feature gets appended to the arch name/version as +feature. For i386, there could be features like fpu, mmx, sse, sse2, etc. A single arch specifier can name any number of features, e.g. i386+3dnow, or i386.6+mmx+sse. ... but this has the disadvantage of being unexact. What to do if a processor has three features, but in the special case the packages allows only two of them at a time? Or to make it worse say processor A supports maximum subarch 7, and feature A, but feature A can only be used really fast in subarch 6; packages in subarch 7 must also be built because they are faster on processors without feature A? In your proposal one is bound to suboptimal matches in special cases, and even a very good package maintainer can't get around. The argument that special cases are seldom won't match here because: The whole subarch-system is only needed in special cases. I don't believe that vi will get substantial speed improvements because of subarch specific versions (otherwise show me figures). ;-) Because of this in my proposal exact matches are possible. There is only one case where unexact must be used, and this is when a new subarch comes to existence. The subarch information that could be stored in your modell can be also be stored in my modell, but also more complex information. (You break up the subarch-info from my modell to several pieces. In my modell there would be a subarch _i586 and _i586-mmx, and with an unexact match packages for _i586 are also used for _i586-mmx, unless there is a better, i.e. exact match.) There is one obvious advantage of your proposal: The archive selection code needs to know less of subarchs. But, as new subarchs aren't created every day (unlike new version of ordinary packages) it's IMHO ok to save magic code in the selection programms. It won't get real large. The other advantage is that it consumes less space in the Packages file. But, as subarchs are needed on relativly few packages this is IMHO ok because of the more mightier abilities. Available packages in the fictitious pool: (A) pool/contrib/q/quake2/quake2_0.2.1-4_i386.deb (B) pool/contrib/q/quake2/quake2_0.2.1-4_i386.5+mmx.deb (C) pool/contrib/q/quake2/quake2_0.2.1-4_i386.6+3dnow.deb Do I see it right that the package names are nowhere noted but created by s/arch/best_match/ on the fly? I specified the different files on purpose in the Packages-File, as it might be useful in special cases to use different filenames - or to use one file for different subarchs. 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
[proposal] subarchitectures (was: Bug#198158: architecture i386 isn't i386 anymore)
* Michael Banck ([EMAIL PROTECTED]) [030626 08:20]: On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote: What does oppose us to make subarchitectures quite more easy than now? (That would also be useful for the AMD Opteron and the like that could use normal i386-code, but can profit from optimized code.) Nothing opposes it, we're just missing something: The correct patch. I would start with a proposal first before writing code. Below is a draft, comments to it? (I know it doesn't specify every detail. It is a start, not more nor less, and it should be expanded if acceptable in general. Also a list of subarchitectures must be created. I'm also willing to produce code once this or another proposal is accepted.) DRAFT - Subarchitectures for debian [0.1] Subarchitectures are an extension to a given architecture that provides optimized binaries that work only (optimized) on a part of machines of the whole architecture. For example: Code using the MMX-extensions can not work on all i386-machines. In this text I will use architecture_subarchitecture or _subarchitecture in examples if speaking of a subarchitecture (e.g. i386_i386). This text speaks only of the debian archive and the user interface at installing packages. If this proposal is adopted it must be expanded to the packaging tools of course. Goal: The addition of subarchitectures must not break the current archiving system, but enhance it. On the other hand, it must be easy to use and most transparent to the users. I assume that most packages need not to be present in an extra subarchitecture-specified version in the archive, otherwise it would be useful to make a full new architecture. control-Files: The syntax of the control-Files is extended in the following way: The field Filename gives the default file for this package. It must be able to run on each machine of the given architecture, as tools not knowing of subarchitectures will use this file. (Of course it might be neccassary to use the standard emulator provided by debian as discussed at the moment for i386_i386. And I didn't say make good performance. No, it just must run. It might be really very suboptimal, e.g. using much too much emulation code as in optimized for _i686, opcodes from _i586, running on _i386, and opcode emulation in the default linux kernel by debian.) It is possible to specify another file for subarchitectures with Filename[+-]subarchitecture, e.g. Filename-i486. A '-' says: Use this file exactly for the given subarchitecture. A '+' means: For this and any 'higher' subarchitecture, unless there is a closer match. '+' has the advantage of making the control-files a bit smaller, but might be too unfocussed. So both alternatives are given, and the package maintainer can choose which one suits better in his case. Meta-Subarchitectures: Sometimes it is usefull to put some subarchitectures together again by a specific criterium like existence of a MMU. For this meta-subarchitectures can be used. Creating of new subarchitectures (and exceptions to the said): If a new subarchitecture is created there are usually no specific files for it at the beginning. But it is usually suboptimal to start at the very beginning and the lowest common denominator for the whole architecture. So at selecting the filename of an old package for a new subarchitecture the selecting tools uses instead a predefined other subarchitecture. (As a simple example just imagine Debian is running on _i286, _i386 and _i486 and we just created new _i486. If a system using _i486 is installing an old package, the selection tools just behaves as the system is _i386.) Old is a package that gives a Standards-Version where the given subarchitecture was not defined. Packages only for parts of the architecture: Sometimes a package is only usable on specific subarchitectures because of allowing to manipulate specific things, eg microcode updates, http://packages.debian.org/microcode.ctl. In this case the package must not specify the filename-field in the control-file. The package selection tools must show by default these packages exactly on the subarchitectures where it provide files. Such a package must make a Pre-Depend on an dpkg-Version knowing of subarchitectures and such a package must not be uploaded to woody or any older release, including security or proposed-updates. Next steps: I put this list up on http://home.arcor.de/andreas-barth/subarch.html and will update this file according to the discussion. The next steps are to get a decision whether to use subarchitectures or not, and about the above proposal. As soon as this is done the next steps are to enhance the archive tools. But step after step. 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
subarchitectures? (was: Bug#198158: architecture i386 isn't i386 anymore)
* Colin Watson ([EMAIL PROTECTED]) [030625 12:35]: The problem is that we really don't have sensible support for subarchitectures at all. This makes the job of creating such a specialized port much greater than just I have some hardware and need to make a small tweak to support it; you need to patch dpkg and make substantial changes in the archive organization to share packages between architectures, What does oppose us to make subarchitectures quite more easy than now? (That would also be useful for the AMD Opteron and the like that could use normal i386-code, but can profit from optimized code.) Of course, that doesn't resolve the actual bug right now, but ... all this mess and say well, why don't you just leave everything as it is and let us make this small kernel change, until we can standardize on gcc-3.3 with a fixed ABI? ... this is the right thing to do 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
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
* Adam Heath ([EMAIL PROTECTED]) [030624 18:50]: On Tue, 24 Jun 2003, Daniel Stone wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. Tell me when you upload this, so I can file an rc bug against it, for modifying other packages conffiles. When did you fill an rc bug against tar for modifiying other packages conffiles? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#198158: architecture i386 isn't i386 anymore
* Martin v. Löwis ([EMAIL PROTECTED]) [030622 11:50]: problem here (C++ ABI compatibility with other Linux distributions). The discussion is now about *how* to fix this bug: 1. just bump minimum supported i386-family processor to i486 1a. like 1, but just for c++-packages. 2. like 1, but bump to some other processor. this is not strictly needed to fix the bug, but it might be a good idea for other reasons. Dropping other architectures to fix this bug is probably not a good idea, as it won't fix the bug. 3. bump the supported processor, and rename the port 4. like 3, and also add an i386 distribution which does not support C++ at all 5. like 4, but support C++ in a way incompatible with other Linux distributions in the i386 distribution. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
* Marco d'Itri ([EMAIL PROTECTED]) [030622 16:35]: On Jun 22, Herbert Xu [EMAIL PROTECTED] wrote: There is no technical reason why we can't support libc5 anymore. The only reason that this is being discussed is that nobody has stood up to maintain the package. This looks like a good enough reason to me. Sorry, but I can find no RFA/O-entry for this package. That should be done first before kicking it off. And I don't remember to read anything from the current maintainer either. 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
Bug#198158: architecture i386 isn't i386 anymore
* Stephen Stafford ([EMAIL PROTECTED]) [030620 15:35]: Judging from my random contacts with users, it's a fairly usual setup to see a network of higher (500Mhz+) end hardware machines which sit on a LAN in 1918space and are masqueraded to the outside internet by a firewall/gateway running Debian on a 486 or low end pentium. I believe this to be a fairly significant proportion of our userbase and I'd oppose any move to marginalise them like this. Well, the key problem is: debian doesn't properly support the way i386+ is constructed. That does also make problems for amd64. It would be really nice to be able to just put (additional) i686- (or 64bit-)optimized binaries in place where they are usefull, but only there and without doubling every binary. An possible way is: split i386 into subarchitectures i386-[subtype] and a plain i386, where subtype is one of i486, i586, i686, For every subtype there is a list what subtypes are acceptable in addition to plain i386 to install (so a i386-i686 would also install i386-i486 and i386-i586 packages). At creating the debian packages, normally (also with Architecture: any) only the plain i386 packages are created. If it is usefull to generate also packages for one or more subtypes they must be specified explizitly at the Architecture line. This way would also have the advantage that the existing mmx, 3dnow, ... packages (that are really just making the package list larger without adding content) can be removed. 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
Accepted libapache-mod-dav 1.0.3-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 25 May 2003 21:17:08 +0200 Source: libapache-mod-dav Binary: libapache-mod-dav Architecture: source i386 Version: 1.0.3-6 Distribution: unstable Urgency: low Maintainer: Andreas Barth [EMAIL PROTECTED] Changed-By: Andreas Barth [EMAIL PROTECTED] Description: libapache-mod-dav - A DAV module for Apache Changes: libapache-mod-dav (1.0.3-6) unstable; urgency=low . * using current standards 3.5.9.0. * updated documentation * wrote/compiled manpages for dbu, lockview, fixvers * helper programms are now in /usr/lib/libapache-mod-dav * fixed linda and lintian warnings and errors Files: 01bed09bedf340ca3c428acb9712e6cf 672 web optional libapache-mod-dav_1.0.3-6.dsc fb7ed36f794583ea97c4813a2a965507 12076 web optional libapache-mod-dav_1.0.3-6.diff.gz 0b401e8db5aa9a29025f554e4cc205da 77718 web optional libapache-mod-dav_1.0.3-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj7fHTAACgkQgZalRGu6PIQdsACeIukPXL7TwV5KGHa7p/290Tlb oCMAnjoUOrngZgWirgESjCevkI+wqFeQ =5f/M -END PGP SIGNATURE- Accepted: libapache-mod-dav_1.0.3-6.diff.gz to pool/main/liba/libapache-mod-dav/libapache-mod-dav_1.0.3-6.diff.gz libapache-mod-dav_1.0.3-6.dsc to pool/main/liba/libapache-mod-dav/libapache-mod-dav_1.0.3-6.dsc libapache-mod-dav_1.0.3-6_i386.deb to pool/main/liba/libapache-mod-dav/libapache-mod-dav_1.0.3-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)
* Manoj Srivastava ([EMAIL PROTECTED]) [030604 08:20]: On Sun, 1 Jun 2003 21:50:45 +0200, Andreas Barth [EMAIL PROTECTED] said: You should really accept the decision of a package maintainer. Why so, if they are not doing the right thing? In real life there a three categories: Right, Wrong but acceptable and Wrong. It would be enough to not accept the maintainer decisions in the last case. Everything else is a waste of time. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)
* Rene Engelhard ([EMAIL PROTECTED]) [030602 01:05]: However, it really might be better to put a longer statement into changelog. _But_ it's certainly much worse to re-open a really closed bug than to make a too short changelog entry. (BTW: You should really a wrongly closed... (whithout explanation what the fix was; the Was the bug still there? No. So it was right to close the bug despite the fact that _you_ didn't like the changelog-style. make cleaner why changing of the compiler closes the Bug 194555. The situation there is fare worse than here. You shouldn't flame until you're perfekt.) aha. You say me I should respect the decision and you don't. *sigh* I didn't reopen your bug report. And - I would never spoken about that here unless you bashed a debian maintainer here and reopend a really closed bug. I actually am really busy with other Debian and RL things... Perhaps you just shouldn't try to enforce your point of view. That would make it easier. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)
* Brian Nelson ([EMAIL PROTECTED]) [030601 19:05]: FWIW, my policy has become to only politely ask maintainers in private to use more verbose New upstream version changelog entries in the future, because it seems to be a religious issue for some. That's certainly the right policy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)
* Rene Engelhard ([EMAIL PROTECTED]) [030601 18:50]: Marcelo E. Magallon wrote: On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote: * New upstream version (Closes: #193497) Meep. No. Write proper changelogs and(or close bugs the right way[tm]. That form is only acceptable for New upstream version, please package it like bugs. With all due respect: piss off. Is this a new sport in #d-d or something like that? I read that entry as the new upstream version fixes the problem reported in #193497, and looking at the BTS that is exactly its meaning. yes. And what is when someone is offline and wants to see what that bug was about? But we discussed that already enough on this list... You should really accept the decision of a package maintainer. However, it really might be better to put a longer statement into changelog. _But_ it's certainly much worse to re-open a really closed bug than to make a too short changelog entry. (BTW: You should really make cleaner why changing of the compiler closes the Bug 194555. The situation there is fare worse than here. You shouldn't flame until you're perfekt.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Accepted directory-administrator 1.3.5-1 (i386 source)
* Francesco Paolo Lovergine ([EMAIL PROTECTED]) [030522 21:35]: On Wed, May 21, 2003 at 12:31:14PM -0700, Brian Nelson wrote: * Acknowledge NMU (closes: #174301, #172803, #179036, #177616) Ugh, also this one. Do not use changelog for closing fixed bugs. Do it using BTS directly. The developers references tells that both methods are allowed in 5.11.4 http://www.debian.de/doc/developers-reference/ch-pkgs.en.html#s-ack-nmu I for myself prefer the changelog entry because it shows direct which bugs are closed by the maintainer. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Symlinking /usr/share/doc/package is not allowed
* Brian May ([EMAIL PROTECTED]) [030521 02:35]: On Tue, May 20, 2003 at 08:00:21PM +0200, Andreas Barth wrote: The policy vetoe to symlinking intends (in my interpretation) two goals. One is to ensure that the licences don't change unintendidly. This could e.g. happen if there is a global file called GPL, the packages link there copyright statement to it, and the GPL-file is incremented from GPL version 2 and later to GPL version 3 by just one misbehaving program. The other is to make sure the copyright file is always available. Both traps are avoided in the case where the documentation directory is symlinked to the base packages directory. What if the user has version 1 of abc installed, and version 2 of abc-doc installed, AND /usr/share/doc/abc-doc is a symlink to /usr/share/doc/abc, AND the copyright changed between version 1 and version 2? It seems you didn't read my mail. I said the second one depends on =first-package-version. If a user really manages to install version 2 of the base-package and version 1 of the development package, in spite of the fact that the development package depends on exactly the same version as base package, he has to live with the results. A user with root priviliges could always make a system unusable if doing too much by hand. Also builing packages with the development package after that will strongly fail, independed of the copyright notice. On the other hand, if the second package is not marked to depend on the same version, that would be a RC-bug that is to be fixed asap. Please fill a bug report regarding wrong dependencies. Also I think it is worth pointing out in this circumstance that I may want to install abc-doc even though abc is not installed or is a different version (eg. to see what the package is like before installing it). You can get that information with the changes file, or extract the package in some subdirectory. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Symlinking /usr/share/doc/package is not allowed
* Adrian Bunk ([EMAIL PROTECTED]) [030520 19:20]: Several packages in Debian depend on another package and symlink their /usr/share/doc/package to the directory of this other package. Section 13.5. of your policy says: -- snip -- 13.5. Copyright information --- Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc/package/copyright'. This file must neither be compressed nor be a symbolic link. ... -- snip -- This seems to imply that making /usr/share/doc/package a symlink is wrong, too. I don't see any objection to symlinking if both packages are created of the same sourcepackage, the second one depends on =first-package-version and (naturally) have the same copyright. The typical case is a base package and a -doc package (or -suid, or -dev). If policy is enforcing to duplicate the files that would really be just a waste of disk space with no gain at all. The policy vetoe to symlinking intends (in my interpretation) two goals. One is to ensure that the licences don't change unintendidly. This could e.g. happen if there is a global file called GPL, the packages link there copyright statement to it, and the GPL-file is incremented from GPL version 2 and later to GPL version 3 by just one misbehaving program. The other is to make sure the copyright file is always available. Both traps are avoided in the case where the documentation directory is symlinked to the base packages directory. Unless someone can convince me that my interpretation of your policy is wrong I'll start filing bugs against packages that symlink /usr/share/doc/package to the directory of another package. Of course I can't veto you of mass-filling bugs. But you really should get a consensus before mass-filling. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: plagiarism of reiserfs by Debian
* Matthew Palmer ([EMAIL PROTECTED]) [030424 02:50]: On Wed, 23 Apr 2003, Andreas Barth wrote: Can't you understand that as an author you would like that messages like this are not removed without your consent? The internet robustness principle says: Be liberal in what you accept and conservative in what you send. Modifiying code is sending, and Writing the code in the first place is also sending. I'd say that, under the circumstances for which reiserfsprogs is most likely to be used by a person, a long credits speil at the end of execution isn't overly conservative. The principles apply to everyone. That's certainly true. But this list is called debian-devel and not hans-reiser-devel. (Otherwise I would say something about misunderstandable licences etc.) therefore the debian-maintainers should be conservative in making changes against the will of the upstream maintainers. (Formally That I wholeheartedly agree with - hell, it should be put in the Developers Reference in big pointy letters. However, at the end of the day, maintainers have signed on to do the best for our users, not upstream maintainers. That's true. I said conservative and not must not. (I just don't like the attitude by a few writers here that the debian maintainer needs not to be polite to the upstream maintainer and should completly ignore his wishes. That the debian maintainer has at the end of the day to do the best for the users is not the point.) The question must be asked and answered, how are users better served - by keeping a long credits message and reiserfs, or switching to another journalling file system whose tools don't have such unpleasantness. True. But I can't remember this discussion here. 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
* Manoj Srivastava ([EMAIL PROTECTED]) [030424 05:20]: On Wed, 23 Apr 2003 17:41:58 +0200, Andreas Barth [EMAIL PROTECTED] said: You can. The _moral_ right is compatible with free software, the _formal_ right not. (And in some, rare cases the moral right is ignored. mkreiserfs could be a place like that. But that doesn't stop the moral right in general.) You seem to be impying that all forks of free software are immoral. No (perhaps my English is to bad). For example the samba-fork in Samba and Samba TNG is completly ok, for reference see http://de.samba.org/samba/tng.html. And: morale is not a 0/1-thing, in contrary to legal. So something might be morally not ok, but the alternatives may still be worse. And I'm certainly not accusing anybody if he uses the least worse alternative which still may be rather bad. 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
* David Nusinow ([EMAIL PROTECTED]) [030424 11:20]: Your message works both ways, and it's obvious to me that upstream authors should give maintainers as much respect as maintainers give them. Some simple civility is really all that's called for. Perfectly true. But this list is called debian-devel and not hans-reiser-devel, so I spoke not about Hans Reisers behaviour (what does not mean that I like his behavior). 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
* Glenn Maynard ([EMAIL PROTECTED]) [030422 05:50]: On Tue, Apr 22, 2003 at 12:25:39PM +1000, Martin Pool wrote: banner at startup is inconvenient. However just cutting it out is not a good way to resolve the bug. The maintainer made a mistake here. It ought to be obvious that removing a author/sponsor notice would be likely to offend. It's not obvious. Removing a sponsorship notice is something I'd do without a second thought; it's nothing more than advertisement and it's just as annoying to me as a banner ad. I object: There is always a cause why a certain message is output. A debian maintainer should (morally) at least ask what the upstream maintainer thinks about removing the sponsorship message and remove it against the will of the upstream maintainer only in very rare cases after appropriate discussions within the debian project. Everything else is at least very unfriendly. (I'm not speaking formally whether the removal is allowed, and consequences for the freedomsnes of the software in respect to debians guidelines. That's a totally different discussion.) 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
* David Nusinow ([EMAIL PROTECTED]) [030422 08:05]: So, ultimately, what harm does this do to the author? If all he cares about is his reputation, then he's certaintly not doing a good job of bolstering it in this particular forum. He's not representing his sponsors very well either. Can't you understand that as an author you would like that messages like this are not removed without your consent? The internet robustness principle says: Be liberal in what you accept and conservative in what you send. Modifiying code is sending, and therefore the debian-maintainers should be conservative in making changes against the will of the upstream maintainers. (Formally everytihn is different. But the world doesn't work with only viewing the formal points.) 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
* Steve Langasek ([EMAIL PROTECTED]) [030422 08:35]: On Tue, Apr 22, 2003 at 02:53:38PM +1000, Martin Pool wrote: Authors have a moral right (and a legal one in some places) not to have their work mutilated. You can assert a moral right to control how your work is used, or you can write Free Software. You don't get to do both at once. You can. The _moral_ right is compatible with free software, the _formal_ right not. (And in some, rare cases the moral right is ignored. mkreiserfs could be a place like that. But that doesn't stop the moral right in general.) 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: New project proposal: debian-lex
* Jarno Elonen ([EMAIL PROTECTED]) [030420 18:20]: Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', while But: lex is also used in many different languages than English. I don't see the strong need for an english word when there is a much better international alternative that is understand by jurisprudent people all over the world - the potential users. 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: New project proposal: debian-lex
* David Goodenough ([EMAIL PROTECTED]) [030419 19:20]: [debian-lex] In England there is a move to remove all the Latin and obscure language from the Law, so I would suggest that the project should be called Debian-law not Debian-lex. lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: New project proposal: debian-lex
* Jarno Elonen ([EMAIL PROTECTED]) [030419 21:05]: lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. The first things lex brings in my mind are lexicon and parser generators like 'flex'. Well, that's for you as an computer expert. If I ask an only-user with an university graduate, he will probably say law. 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
* David B Harris ([EMAIL PROTECTED]) [030411 13:05]: On Fri Apr 11, 11:47am +0200, Philipp Kern wrote: * Package name: exim-mysql Version : 3.36 I already packaged with one (exim compiled with mysql and tls support). I needed it personally, with the provided debian exim package a recompile is necessary to use a mysql backend. debian package mirror: http://draenor.its-toasted.org/~phil/deb-pkgs distribution: unstable component: unofficial For what it's worth, exim4-daemon-heavy includes MySQL support; this package isn't in the archive yet, I grabbed it from q.bofh.de at some point, and that's stopped working. They are in experimental, see http://packages.debian.org/cgi-bin/search_packages.pl?keywords=exim4searchon=namessubword=1version=allrelease=all At q.bofh.de are still backports to woody that work fine, also under testing. (And at least the backports are really usable and have a _very_ nice configuration setup. I can't say anything about experimental, as I haven't tried them yet.) 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 Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
