Re: Reproducible, precompiled .o files: what say policy+gpl?
"John H. Robinson, IV" <[EMAIL PROTECTED]> writes: > This package is buildable by tools in main. It meets the letter of the > law. The spirit seems a bit ambiguous. Good case in point, the m68k > cross-compiled stuff, where the cross-compiler used was non-free. (I > have not verified the accuracy of the non-free claim of the cross- > compiler) I don't follow that at all. As I see it, the "spirit" of the DFSG, Social Contract, and what-have-you are that Debian's main archive must be able to bootstrap itself and that packages present in it should have been constructed as such. An example was given earlier of another package (openoffice.org I believe) that supported recompilation using a different JDK. Also, I presume the cross-compiler they were referring to was gcc (I don't know of any other i386-hosted, m68k-targeted compilers capable of building the Linux kernel). gcc isn't non-free. icc *is*. Keeping that in mind *is* in the spirit of Debian. Also, I wouldn't be surprised to know their gcc cross-compiler was derived from the toolchain-source package which is in main.
Re: Reproducible, precompiled .o files: what say policy+gpl?
I am not subscribed to debian-legal. Glenn Maynard wrote: > > Consider a major, practical reason we require that packages be buildable > with free tools: so people--both Debian and users--can make fixes to the > software in the future. I agree with this. This is also not the point. You keep talking about pracakge that can only be built with a non-free compiler. The one in question can be built with a free or non-free compiler. > For example, suppose OpenSSL is built with ecc (Expensive C Compiler), > because it produces faster binaries, the Debian package is created with > it, and ends up in a stable release. A security bug is found, and the > maintainer isn't available. Can another developer fix this bug? No: > you can't possibly make a stable update with a completely different > compiler, halving the speed and possibly introducing new bugs. (Debian > is very conservative and cautious with stable updates; this is one of > the reasons many people use it.) Yes. Assuming that OpenSSL will compile properly with both gcc and ecc, and the source is not using tricks to change functionality when compiled wiht one or the other. To me, using ecc or gcc is, or at least should be, similar to using gcc -O1 or gcc -O9. Similarly, I do not consider a signifcant performance boost to be a change in functionality. I'm thinking something like this: #ifdef ecc // this enables the -S option #elif defined(gcc) // remove -S, but add in -o instead #else // neither -S nor -o available #endif In this case, the compiler used would have a significant change in functionality, and would require the build-dep on ecc, and would be contrib at best. > On the same token, users are similarly unable to exercise the level of > caution needed when making security updates on critical systems, unless > they subject themselves to whatever non-free license the compiler uses. gcc is written under the GPL. I can write a non-free program, keep the source entirely secret, and distribute my program in binary form only, with a very restrictive license. The gcc license does not contaminate the resultant binary (unless, of course, I put gcc code in my program). Similarly, the ecc license should not prevent compiling GPL'd code. If it did, ecc would be unsuitable for any purpose, period. > This is a fundamental reason it's required that packages be buildable > using free tools, and why I don't think "you can build a kind-of similar > package using free tools, but the one we're giving you can only be built > with non-free tools" is acceptable. Again, if it could only be built properly and working with ecc, I will happily agree with you until the cows come home to roost. This would be a long time, as cows donot generally roost. Specifically, this package could be built with either gcc or icc. I will accept the argument from a pragmatic standpoint, in as much a bug in icc would be harder to track down, but not from a ``it is a different package'' because of using icc instead of gcc. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Mon, 18 Oct 2004 21:46:02 -0500, Graham Wilson wrote: > Audio Tag Tool is a program to manage the information fields in MP3 and > Ogg Vorbis files (commonly called tags). Tag Tool can be used to edit > tags one by one, but the most useful features are mass tag and mass > rename. These are designed to tag or rename hundreds of files at once, > in any desired format. How's this better than easytag? Description: viewing, editing and writing ID3 tags of MP3 and Ogg files EasyTAG is an utility for viewing, editing and writing the ID3 tags of MP3 and Ogg files, using a GTK+ interface. . Currently EasyTAG supports the following features: - Viewing, editing, writing ID3 TAGs of MP3 and Ogg files, - Process all files of the selected directory, - Ability to browse subdirectories, - Recursion for tagging, removing, renaming, saving..., - Easy directory selection with a tree browser, - Supports ID3v1, ID3v1.1, and ID3v2 tags, - Scan file for automatic tagging (using masks), - Scan tag for automatic renaming file (using masks), - Rename mp3 file, - Can apply a field (artist, title,...) to all other files, - Display MP3 header informations, - Can load a character translation file. -- Joshua Kwan
Re: New ClamAV version uploaded, testers wanted
Quoting Stephen Gran ([EMAIL PROTECTED]): > Hello all, > > I have uploaded 0.80 to experimental temporarily for testing purposes > (it is also on p.d.o/~sgran). The two main concerns I have with > releasing it into the wild at this point are false positives in the jpeg > scanning code (appears to be largely the result of a bad signature, not > the engine at this point) and the upgrade path. Does this include translation changes? You usually pinged translators in such cases, so I think there are no changes, but I just want to be sure..:-)
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote: > I agree with this. This is also not the point. You keep talking about > pracakge that can only be built with a non-free compiler. The one in > question can be built with a free or non-free compiler. No, that's not what I said. I'm saying that a package built with ecc (or icc or whatever) is not the same package that you'll get if you build the same sources with gcc; it's significantly functionally different. If it wasn't significantly different, nobody would bother to compile with the non-free compiler in the first place, so it's clear that the choice of compiler matters to some people, and making a stable update that changed to gcc would be an unacceptable stable change. > > For example, suppose OpenSSL is built with ecc (Expensive C Compiler), > > because it produces faster binaries, the Debian package is created with > > it, and ends up in a stable release. A security bug is found, and the > > maintainer isn't available. Can another developer fix this bug? No: > > you can't possibly make a stable update with a completely different > > compiler, halving the speed and possibly introducing new bugs. (Debian > > is very conservative and cautious with stable updates; this is one of > > the reasons many people use it.) > > Yes. Assuming that OpenSSL will compile properly with both gcc and ecc, > and the source is not using tricks to change functionality when compiled > wiht one or the other. To me, using ecc or gcc is, or at least should > be, similar to using gcc -O1 or gcc -O9. Huh? You ignored what I said: you can't make a stable update using a different compiler, because it can introduce both performance and (more importantly) new bugs, which is completely unacceptable for a Debian stable security update. You should be using the same compiler, and the same compiler flags, too. Debian's approach to security updates is very clear: change only what's necessary to fix the bug. Are you claiming that changing from one compiler to another, or changing optimization flags, can't introduce bugs? If so, please stay away from any security-sensitive packages ... :) > gcc is written under the GPL. I can write a non-free program, keep the > source entirely secret, and distribute my program in binary form only, > with a very restrictive license. The gcc license does not contaminate > the resultant binary (unless, of course, I put gcc code in my program). > Similarly, the ecc license should not prevent compiling GPL'd code. If > it did, ecc would be unsuitable for any purpose, period. This doesn't seem relevant. -- Glenn Maynard
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Mon, Oct 18, 2004 at 10:45:59PM -0700, Joshua Kwan wrote: > Description: viewing, editing and writing ID3 tags of MP3 and Ogg files > EasyTAG is an utility for viewing, editing and writing > the ID3 tags of MP3 and Ogg files, using a GTK+ interface. Ogg files don't have ID3 tags; I trust this actually means that it uses the standard metadata tagging system of Ogg, and not ID3? -- Glenn Maynard
Re: Reproducible, precompiled .o files: what say policy+gpl?
* Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]: > On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote: > > Le lundi 18 octobre 2004 à 19:22 +0200, Wesley W. Terpstra a écrit : > > > So, when it comes time to release this and include it in a .deb, I ask > > > myself: what would happen if I included (with the C source and ocaml > > > compiler) some precompiled object files for i386? As long as the build > > > target is i386, these object files could be linked in instead of using > > > gcc to produce (slower) object files. This would mean a 2* speedup for > > > users, which is vital in order to reach line-speed. Other platforms > > > recompile as normal. > > > > > > On the other hand, is this still open source? > > > Is this allowed by policy? > > > Can this go into main? > > > > Main must be built with only packages from main. > No, that's not true. > > In addition, the packages in _main_ > * must not require a package outside of _main_ for compilation or > execution (thus, the package must not declare a "Depends", > "Recommends", or "Build-Depends" relationship on a non-_main_ > package), > > There's a difference, which is crucial. ICC may not be Free Software, > policy does not say you must only use Free Software to build a package; > it says you must not /require/ a package outside main to build it. > > The difference is subtle, but crucial. > > Wesley's software can be built using software in main. It will not be as > fast, but it will still do its job, flawlessly, without loss of > features, with the ability to modify the software to better meet one's > needs if so required. I disagree. A program is IMHO not only specified by the fact that it does certain transformations from input to output, but also by the speed it does this. If this specification can be matched by gcc, why consider using icc at all? And if not, it requires icc. (You can also consider what happens when we want to do a security update: Does the security team need to install icc, or do we want that the software runs significantly slower afterwards, and misses its specification?) If icc is required for that application, than it needs to go to contrib. If not, please compile it with gcc. 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: Reproducible, precompiled .o files: what say policy+gpl?
* John Hasler ([EMAIL PROTECTED]) [041019 00:55]: > I _think_ it would also be acceptable for you to build the debs you upload > with CC=icc. I disagree to that statement. IMHO all binary packages uploaded into debian should be the same as if autobuild. Everything else produces pain for QA, security and further NMUs. 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: Xsession doesn't use umask setting from /etc/login.defs
* Tomas Fasth | Branden Robinson wrote: | | Would pam_umask.so be a worthwhile exercise for some enterprising | | person? | | May I suggest pam_logindefs.so? No, that's a bad idea for a variety of reasons, for instance that we already have pam_limits and as pam modules often are security-critical which means we should have small modules instead of one, larger module doing more. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On Tue, Oct 19, 2004 at 08:11:32AM +0200, Florian Zumbiehl wrote: > Package: epic4-script-thirdeye > Version: 1.72-4 > Severity: minor > > I searched through the Packages file a bit for typos and the like - below > you find a diff of this package's description (a) showing what I think is > wrong and (b) how I suggest it to be corrected. > > Description: Third Eye EPIC script > Third Eye is a script for the EPIC IRC client, optimized for version > 4pre2.004. > - It's features include flood protection, nearly completely configurable ansi > + Its features include flood protection, nearly completely configurable ansi Not only is this bug a duplicate, which is immediately obvious upon opening the bugpage of this package, but you filed 63 similar bugs without mailing -devel about your intentions first. This is important, because then someone would have told you you're about to spam the BTS with 63 duplicate bugs. Please go over all your submitted bugs, and close the duplicate ones yourself, and while at it, you could apologize to the maintainers for causing them extra work for nothing. And read [1] too. --Jeroen [1] http://www.debian.org/doc/developers-reference/ch-beyond-pkging#s-submit-many-bugs -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 09:13:24AM +0200, Andreas Barth wrote: > * Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]: > > Wesley's software can be built using software in main. It will not be as > > fast, but it will still do its job, flawlessly, without loss of > > features, with the ability to modify the software to better meet one's > > needs if so required. > > I disagree. > > A program is IMHO not only specified by the fact that it does certain > transformations from input to output, but also by the speed it does > this. There can be cases where compiling software using more recent toolchain versions will result in a binary not running as fast as before (because the newer libc is a bit more bloaty, or because some aggressive optimization which was enabled before but which was deemed buggy by design afterwards, was disabled again, or whatnot). Where is the difference with using a non-free compiler? > If this specification can be matched by gcc, why consider using > icc at all? And if not, it requires icc. (You can also consider what > happens when we want to do a security update: Does the security team > need to install icc, or do we want that the software runs significantly > slower afterwards, and misses its specification?) If that is an issue, then it is also an issue for software currently in main but which is built using toolchain versions that are now no longer in main. > If icc is required for that application, than it needs to go to contrib. Indeed. However, as long as the software does indeed compile correctly using gcc, one can say that icc is not required. > If not, please compile it with gcc. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
* Glenn Maynard: >> Perhaps I should make my program 'par' command-line compatible! >> OTOH, when you have so many small files it is not convenient. > > I don't really understand the use of allowing thousands of tiny parts. > What's the intended end use? I suppose it could be used for multicast file transfer.
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Mon, 18 Oct 2004 21:46:02 -0500, Graham Wilson wrote: > Package: wnpp > Severity: wishlist > > * Package name: tagtool > Version : 0.10 > Upstream Author : Pedro Lopes <[EMAIL PROTECTED]> > * URL : http://pwp.netcabo.pt/paol/tagtool/ > * License : GPL > Description : tool to tag and rename MP3 and Ogg Vorbis files > > Audio Tag Tool is a program to manage the information fields in MP3 and > Ogg Vorbis files (commonly called tags). Tag Tool can be used to edit > tags one by one, but the most useful features are mass tag and mass > rename. These are designed to tag or rename hundreds of files at once, > in any desired format. Does it correctly handle Unicode encoded ID3v2 tags? Checking... No, it apparently doesn't. So I question the value of introducing yet another broken tool to the archive. Oh, another check... It seems not to handle correctly even Vorbis comments, which are UTF8 by definition. Definitely not mature enough, unless I've made some serious mistakes. -- Michał Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
I know this thread has progressed beyond the actual situation I asked about, but I wanted to just throw in my opinion too. On Tue, Oct 19, 2004 at 09:13:24AM +0200, Andreas Barth wrote: > A program is IMHO not only specified by the fact that it does certain > transformations from input to output, but also by the speed it does > this. If this specification can be matched by gcc, why consider using > icc at all? And if not, it requires icc. This is now also my point of view. When I started this thread, I also _felt_ that contrib was the correct place for my application, but didn't really know why. Now I can explain it better. The proposal of keeping one version in main and one in contrib also addresses my concern about usability. So, I am happy with the outcome of this discussion already. =) -- Wesley W. Terpstra
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 10:24:44PM -0400, Glenn Maynard wrote: > On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote: > > Note the exact words (I am assuming that Glenn copied them verbatim): > > the package in main must be buildable with tools in main > > Exact words are: > > In addition, the packages in _main_ > * must not require a package outside of _main_ for compilation or > execution (thus, the package must not declare a "Depends", > "Recommends", or "Build-Depends" relationship on a non-_main_ > package), > > If you build with different tools, you have a different package. "X That's true if you define a package as an exact .deb, but not if you define it as a source package (.orig.tar.gz/.diff.gz/.dsc). The latter seems to be a more useful definition in the context of compilation, IMHO. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 11:05:16PM -0400, Glenn Maynard wrote: > > find -name testing.part.\* -print0 | xargs -0 parchive a -n 16384 > > testing.par > > You're splitting into parts which are far too small. Yes, it's too small for par. It's also clear that it's too small for usenet use. However, my program is not intended to solve usenet problems. My applications are all on the level of packet switching networks. Besides, who ever complains when something is faster than they need? Or as my first computer science prof once said: Insertion sort is fine for most tasks. Sometimes you need quicksort. > It's not designed for thousands of tiny parts No, but mine is. > Most PAR operations are IO-bound (judging by drive thrashing, not from > actual benchmarks). Not to be rude, but you're mistaken here. strace it when there are many small files; it is not doing syscalls. Disk IO and/or thrashing is not the issue for small files. Maybe disk thrashing is a problem during normal par operation, but it is a minor problem compared to the computation (for my goals). [ As aside, my algorithm is also streaming; it reads the 'file' in sequence three times, so disk thrashing should not be a problem. ] > I don't really understand the use of allowing thousands of tiny parts. > What's the intended end use? Note that PAR cannot help you if the unit of failure is very small. Even one missing piece of a 'part' makes that 'part' useless. Florian already mentioned multicast, and that is my first application. Another situation is one where you have any one-way network link (some crazy firewalls [my work; arg!!]). Future (?) wireless networks might have base station with a larger range than the clients. Clients could still download (without ACKs) in this case. Perhaps your ISP has packet loss that sometimes sits at 20% (my home; arg!). If you know how TCP works, you will also know that it will nearly stop sending because it thinks the network is congested, even though the real problem is a faulty switch which drops 20% of packets seemingly at random. Using my code over UDP completely removes this problem. (However, this is dangerous because my code is also 'unfair' in the sense that it will stop all TCP traffic b/c it will not care about packet loss due to conjestion while the TCP traffic will back off) You might also use it to make a version of bittorrent where each packet is independent of the others. This would help prevent 'dead' torrents where there is no seed and all downloads stall b/c the known information overlaps. Another case might be mobile agents where PDAs exchange parts of files they are looking for whenever they run into other PDAs they can bargain with (like bittorrent). However, PDAs move when their owners move, so network sessions are interuppted at random times, and one PDA may never see the other ever again. This scheme would let a PDA broadcast a file to all nearby PDAs which could make use of the information regardless of when they leave (mid 'part'?) or whether they have already pieces of the file. Another situation I would like to apply my code to is to sensor networks where there is a stream of measurements of some variable. My code can not presently handle this correctly, but that is future work for me. I am not a very imaginative person; I am sure there are many other situations where this could be applied. From another point of view, research doesn't *need* to be practical. ;) If other people have ideas, I'd like to hear them. -- Wesley W. Terpstra
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 08:11:50PM +1000, Hamish Moffatt wrote: > On Mon, Oct 18, 2004 at 10:24:44PM -0400, Glenn Maynard wrote: > > Exact words are: > > > > In addition, the packages in _main_ > > * must not require a package outside of _main_ for compilation or > > execution (thus, the package must not declare a "Depends", > > "Recommends", or "Build-Depends" relationship on a non-_main_ > > package), > > > > If you build with different tools, you have a different package. "X > > That's true if you define a package as an exact .deb, but not if you define > it as a source package (.orig.tar.gz/.diff.gz/.dsc). The latter seems to > be a more useful definition in the context of compilation, IMHO. The quote above seems to refer to both, since it speaks of Depends and Recommends (which only apply to binary packages) and Build-Depends (which only apply to source packages). -- Colin Watson [EMAIL PROTECTED]
Re: dpkg -P backuppc fails
Hi, giuseppe:~# dpkg -P backuppc (Reading database ... 87999 files and directories currently installed.) Removing backuppc ... Stopping backuppc: ok. Purging configuration files for backuppc ... and stop... The postinst script seems to be stuck in db_purge, a line which was added automatically: ... # Automatically added by dh_installdebconf if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule db_purge fi # End automatically added section ... So it may be a bug in dpkg ? Ludo.
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 05:47:26PM -0700, Steve Langasek wrote: > On Tue, Oct 19, 2004 at 02:04:42AM +0200, Wouter Verhelst wrote: > > A difference in optimization is not relevant to a package's freedom. > > If compiling the program with a non-free compiler gains you users who would > not find the package usable otherwise, distributing binaries built with > such a compiler induces your users to be dependant (indirectly) on non-free > software. That is a freedom issue. Okay, that is a fair point. I'll leave it at that. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote: [...] > This package is buildable by tools in main. It meets the letter of the > law. The spirit seems a bit ambiguous. Good case in point, the m68k > cross-compiled stuff, where the cross-compiler used was non-free. (I > have not verified the accuracy of the non-free claim of the cross- > compiler. I didn't say that. The compiler was built from gcc sources, but the cross-compiler (as it was used) was not uploaded to the archive. > Also, this discussion is academic as the maintainer is going to split > the package into two: gcc build in main, and icc built in contrib. Given > the circumstance, I felt that this action is the best. Agreed. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On Tue, Oct 19, 2004 at 10:06:01AM +0200, Jeroen van Wolffelaar wrote: > On Tue, Oct 19, 2004 at 08:11:32AM +0200, Florian Zumbiehl wrote: > > I searched through the Packages file a bit for typos and the like - below > > you find a diff of this package's description (a) showing what I think is > > wrong and (b) how I suggest it to be corrected. > > > > Description: Third Eye EPIC script > > Third Eye is a script for the EPIC IRC client, optimized for version > > 4pre2.004. > > - It's features include flood protection, nearly completely configurable > > ansi > > + Its features include flood protection, nearly completely configurable ansi > > Not only is this bug a duplicate, which is immediately obvious upon > opening the bugpage of this package, but you filed 63 similar bugs > without mailing -devel about your intentions first. This is important, > because then someone would have told you you're about to spam the BTS > with 63 duplicate bugs. Please cool down, if you compare with #268503, this one includes a patch whereas the original did not, so it is not a duplicate but an improvement. It seems this bug submitter has made much more effort toward quality bug reports than the previous attempt at fixing typos so I see no point flaming him. I dream to receive patch in bug reports. Sending 63 patches do not really qualify as massive bug filling. Compare that with the massive bug filling entitled "The package description does not follow Debian policy" filled with severity important... > Please go over all your submitted bugs, and close the duplicate ones > yourself, and while at it, you could apologize to the maintainers for > causing them extra work for nothing. If you think it is a duplicate, you should merge them not close it summarily, especially since this one include a patch. So long for apologizing. Florian, improve your script so that the bug title include the name of the package next time. :-) Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. pgpSkLUBG4i70.pgp Description: PGP signature
Re: Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On 20041019T134416+0200, Bill Allombert wrote: > Please cool down, if you compare with #268503, this one includes a > patch whereas the original did not, so it is not a duplicate but an > improvement. In other words, it is a duplicate report with a patch. The proper thing (with respect to this individual case) would have been to send the patch to #268503 without opening a new bug. > It seems this bug submitter has made much more effort toward quality bug > reports than the previous attempt at fixing typos so I see no point > flaming him. He was not flamed; he was being corrected about an important piece of Debian etiquette. > I dream to receive patch in bug reports. Sending 63 patches > do not really qualify as massive bug filling. The issue is not whether it was massive but whether it was a mass bug report. There is a difference: the latter is usually indicated when many bugs are opened on a similar issue against several package based on a (semi)automated search for a particular kind of bug in the Debian archive. > If you think it is a duplicate, you should merge them not close it > summarily, especially since this one include a patch. That is true. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On 19-Oct-04, 03:06 (CDT), Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > > > > Description: Third Eye EPIC script > > Third Eye is a script for the EPIC IRC client, optimized for version > > 4pre2.004. > > - It's features include flood protection, nearly completely configurable > > ansi > > + Its features include flood protection, nearly completely configurable ansi > > Not only is this bug a duplicate, ...but it's also missing a fix: s/ansi/ANSI/ :-) The description also suffers from other random capitalization: why "Eterm" and "Bash" but not "Rxvt"? Why "Themes" in the middle of the sentence? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: dpkg -P backuppc fails
Ludovic Drolez <[EMAIL PROTECTED]> schrieb: > The postinst script seems to be stuck in db_purge, a line which was > added automatically: The postinst script is not executed upon purging a package. Probably you mean the postrm script? > > ... > # Automatically added by dh_installdebconf > if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then > . /usr/share/debconf/confmodule > db_purge > fi > # End automatically added section > ... > > So it may be a bug in dpkg ? Please try to debug by putting a "set -x" into /var/lib/dpkg/info/backuppc.postrm (or prerm, whatever it is). If it really hangs at db_purge, it may be a bug in debconf. You should know that. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On Tue, Oct 19, 2004 at 04:26:58PM +0300, Antti-Juhani Kaijanaho wrote: > On 20041019T134416+0200, Bill Allombert wrote: > > Please cool down, if you compare with #268503, this one includes a > > patch whereas the original did not, so it is not a duplicate but an > > improvement. > > In other words, it is a duplicate report with a patch. The proper thing > (with respect to this individual case) would have been to send the patch > to #268503 without opening a new bug. Meanwhile, Florian merged the bugs that were a duplicate. He followed-up on my initial mail by private mail, and explained why he did the filing the way he did. Let me state for the record he did a lot of things right (mailing to maintonly, including a package-specific part in the template (even being a patch), filing non-bogus bugs, and filing at the right severity), I was just annoyed at the two things that he happened to not do (check for existing reports about the issue, mailing his intentention to -devel). Those two also happened to be the ones that could have prevented the duplicates. He obviously gave thought to these issues, and didn't do the massfiling lightly. It was due to an unfortunately wrong assumption that he concluded an announcement to -devel would not be needed. > > It seems this bug submitter has made much more effort toward quality bug > > reports than the previous attempt at fixing typos so I see no point > > flaming him. > > He was not flamed; he was being corrected about an important piece of > Debian etiquette. It is never ever my intention to be part of a flame, I cc'd -devel only in the hope to prevent this (mass filing without prior discussion on -devel) from happening again, and I mailed Florian himself to tell him what he IMHO failed to do. > > If you think it is a duplicate, you should merge them not close it > > summarily, especially since this one include a patch. > > That is true. I'll do so for the particular bug this thread was linked to, you're right, particularly because of the extra info. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFC: common database policy/infrastracture
1. I would set the default of the "leave data after purge" to true and give it priority high. 2. I am not sure what you mean by "maintainer script". prerm and preinst should not ask questions. they are there to enact values stored in the debconf cache. config, on the other hand, should not make changes but only direct the user through the questions. Thanks for diving into this topic! We definitely need a policy here... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- 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: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Tue, Oct 19, 2004 at 02:45:24AM -0400, Glenn Maynard wrote: > On Mon, Oct 18, 2004 at 10:45:59PM -0700, Joshua Kwan wrote: > > Description: viewing, editing and writing ID3 tags of MP3 and Ogg files > > EasyTAG is an utility for viewing, editing and writing > > the ID3 tags of MP3 and Ogg files, using a GTK+ interface. > > Ogg files don't have ID3 tags; I trust this actually means that it uses > the standard metadata tagging system of Ogg, and not ID3? Yes, EasyTAG edits Ogg Vorbis tags properly. -- gram
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Mon, Oct 18, 2004 at 10:45:59PM -0700, Joshua Kwan wrote: > On Mon, 18 Oct 2004 21:46:02 -0500, Graham Wilson wrote: > > Audio Tag Tool is a program to manage the information fields in MP3 and > > Ogg Vorbis files (commonly called tags). Tag Tool can be used to edit > > tags one by one, but the most useful features are mass tag and mass > > rename. These are designed to tag or rename hundreds of files at once, > > in any desired format. > > How's this better than easytag? Feature for feature, I think EasyTAG is probably better than tagtool. tagtool, though, was easier to use for me, and had a less cluttered interface. -- gram
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Tue, Oct 19, 2004 at 12:01:44PM +0200, Michal Politowski wrote: > On Mon, 18 Oct 2004 21:46:02 -0500, Graham Wilson wrote: > > Audio Tag Tool is a program to manage the information fields in MP3 and > > Ogg Vorbis files (commonly called tags). Tag Tool can be used to edit > > tags one by one, but the most useful features are mass tag and mass > > rename. These are designed to tag or rename hundreds of files at once, > > in any desired format. > > Does it correctly handle Unicode encoded ID3v2 tags? > Checking... > No, it apparently doesn't. The TODO file says the following, which I haven't followed up on: Make ID3v2 text encoding a preference as soon as id3lib releases an unbroken version (hopefully 2.4.0) > So I question the value of introducing yet another broken tool to the > archive. tagtool does work in some cases, even if not in all of them. The program is valuable to me (hence my ITP), and I'm sure it will be valuable to at least a few others. I don't think a package has to be valuable to everyone before it is allowed in the archive. > It seems not to handle correctly even Vorbis comments, which are UTF8 > by definition. Seemed to work fine for me. How are you testing this? > Definitely not mature enough, unless I've made some serious mistakes. It seems to work fine for my music collection, and I'm sure it works fine for others as well, so I see no reason not to upload it to the archive. -- gram
Re: Reproducible, precompiled .o files: what say policy+gpl?
I am not subscribed to debian-legal Glenn Maynard wrote: > On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote: > > I'm saying that a package built with ecc (or icc or whatever) is not > the same package that you'll get if you build the same sources with > gcc; it's significantly functionally different. The only difference is in *performance*. If there are other differences, then there is a bug in one of the two compilers. If you are equating performance with functionality, then we are going to have a very hard time communicating. > Huh? You ignored what I said: you can't make a stable update using a > different compiler, because it can introduce both performance and (more > importantly) new bugs, which is completely unacceptable for a Debian > stable security update. Actually, later in my previous message I accepted your agrument on pragmatic grounds. > Are you claiming that changing from one compiler to another, or changing > optimization flags, can't introduce bugs? If so, please stay away from > any security-sensitive packages ... :) I'm saying that it should not introduce bugs. In a perfect world, of course. We don't live in one. > > gcc is written under the GPL. I can write a non-free program, keep the > > source entirely secret, and distribute my program in binary form only, > > with a very restrictive license. The gcc license does not contaminate > > the resultant binary (unless, of course, I put gcc code in my program). > > Similarly, the ecc license should not prevent compiling GPL'd code. If > > it did, ecc would be unsuitable for any purpose, period. > > This doesn't seem relevant. You are the one that brought up the bogus argument that if the icc packaged one were introduced into main, that any end-user would have to accept the icc license. This is almost akin to saying that if a package were built on a vmware virtual machine, the end-user would have to accept the vmware license, or that the package would have to go into contrib. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html
Re: forwarding bugs to other packages
On Tue, Oct 19, 2004 at 08:26:23AM +1000, Brian May wrote: > > "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > Bernd> On Mon, Oct 18, 2004 at 05:54:44PM +1000, Brian May wrote: > >> I could just close the bug against my package, but this means other > >> people will encounter the same problem and report the bug against my > >> package again (as it isn't always obvious that it isn't the fault of > >> my package). > > Bernd> So you do not want to reassign them to the correct package? > Bernd> I dont think thats a good idea (even when i can understand > Bernd> where are you coming from). > > Like I said in my previous post, there are times when having 2 > separate bug reports is a good idea. > > e.g. you might think a reported bug in your package is due to a bug in > a library, so you reassign the bug report to the library. > > The library maintainer decides it isn't a bug in the library, and > prematurely closes the bug report. Or maybe the library maintainer > finds a bug, and fixes it, but it was an unrelated bug. > > You never get the indication that the bug report has been closed, and > the bug submitter gets totally confused and either doesn't follow up > (perhaps assuming the problem was fixed), or follows up to the wrong > person (as the bug is still assigned to the library). As such you > don't get a chance to followup and make sure the bug, initially > reported against your package, really gets fixed. > > Alternatively, when you reassign the bug to the library, the library > maintainer gets fed up because he already has 10+ bug reports on the > same issue. It strikes me that this problem is actually similar to a couple of others, and all of them could be reasonably resolved by a new concept in the BTS - bug dependancies. All it really says is "Some part of this bug depends on some part of bug #XX" - maybe you think the segfault is actually from a library and so you have no intention of trying to fix it until the library bug is fixed (at which point, you might well change your Depends entry versioning for the library, etc). Or maybe there's a feature request you're happy to add, but need to have another package support first (say, maybe you're adding alternatives to a variety of things, and they all need to update to provide it at roughly the same time, with versioned conflicts, to be happy). It would also presumably allow you to add a filter such as "don't display any bug with a dependancy on any other still-open bug"; thus allowing maintainers to have things "automagically" show up again once the bug they're waiting on has been resolved. Of course, I make no claim that the BTS folks won't want to rip my spleen out for bringing this up, but it does seem like it could be used to resolve a couple of different types of problem. (It also allows yet another way to avoid BTS tennis matches; if the maintainer of the other package doesn't agree that it's the same thing, put in a depends and wait for them to resolve whatever the bona-fide bug in their package is, rather than arguing about it.) -- Joel Baker <[EMAIL PROTECTED]>,''`. : :' : `. `' `- signature.asc Description: Digital signature
gnome-2.8, evolution-2, and integrated vim
Now that I have gnome-2.8 and evolution-2, working on my unstable/experimental box, I should like to get vim working as the editor in evolution's composer. I have followed the instructions at http://wiki.debian.net/kwiki.cgi?GnomeTwoDotEightFAQ for installing gnome-2.8, and everything works well. I have been longing to use evolution-2, which is supposed to have out-of-the-box support for the integrated use of vim (in the composer). The gnome-vim site, http://www.opensky.ca/gnome-vim/ describes how to get vim working with the older evolution. In the past, I successfully followed the instructions there to patch and build the old evolution to support vim-bonobo from deb http://www.opensky.ca/~jdhildeb/debian/ unstable/ Is there any word on how to do this with evolution-2 and gnome-2.8? -- Thomas E. Vaughan (303) 939-6386 Ball Aerospace, Boulder
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 09:16:17AM -0700, John H. Robinson, IV wrote: > The only difference is in *performance*. If there are other differences, > then there is a bug in one of the two compilers. If you are equating > performance with functionality, then we are going to have a very hard > time communicating. I guess so. I'd consider a security update that significantly reduced the performance of the package due to a different compiler being used to be a severe error. I suspect the stable RM would agree. You apparently don't care, but I suspect you're in a tiny minority (and for the sake of the quality of Debian stable releases, I hope so). > > Huh? You ignored what I said: you can't make a stable update using a > > different compiler, because it can introduce both performance and (more > > importantly) new bugs, which is completely unacceptable for a Debian > > stable security update. > > Actually, later in my previous message I accepted your agrument on > pragmatic grounds. It's one real-life example of why depending on non-free components to build Debian is unacceptable. That's why Debian exists: to build an entirely free system--not "entirely free, except you'll need these non- free tools to actually build it". > You are the one that brought up the bogus argument that if the icc > packaged one were introduced into main, that any end-user would have to > accept the icc license. No, I didn't. I said that you'd have to do that if you wanted to produce the package, which is entirely true; if you don't do so, you can only build with a different compiler, which gives you a different thing. > This is almost akin to saying that if a package were built on a vmware > virtual machine, the end-user would have to accept the vmware license, > or that the package would have to go into contrib. This, on the other hand, is entirely bogus. Building in a VM doesn't change the output; building with a different compiler certainly does. -- Glenn Maynard
requirements regarding 'priorities'
Hi all, I am sponsoring a future maintainer whose package 'movixmaker-2' has its official priority set to "optional". This package depends on libconfig-inifiles-perl, of which the priority is "extra". OTOH, the policy states (section 2.5): "Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted." Pascal Giard (CC'd in this message) is trying to be compliant with this, but any upload of the package makes the ftp system send a message stating that there is an "override disparity" regarding the priorities. Also, he has tried to contact [EMAIL PROTECTED] many times for 6 months but failed to receive any answer so far. What can be done, regarding this package, and also every other packages which could be in this situation? Wolfgang -- "An eye for an eye only makes the world blind." (Ghandi) pgps4XbApB6nK.pgp Description: PGP signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
"John H. Robinson, IV" <[EMAIL PROTECTED]> writes: > The only difference is in *performance*. If there are other differences, > then there is a bug in one of the two compilers. If you are equating > performance with functionality, then we are going to have a very hard > time communicating. This is not true. The program may depend on the details of how a compiler in fact works (for example, how structure members are packed). Such a thing might be a bug, but it is there nonetheless, and is not a compiler bug. And if the binary in the archive was made by some other tool, then debugging resulting problems is a nightmare. Thomas
Re: RFC: common database policy/infrastracture
On Tue, Oct 19, 2004 at 05:19:47PM +0200, martin f krafft wrote: > 1. I would set the default of the "leave data after purge" to true >and give it priority high. i guess i had forgotten to update the page on this one (someone else had requested this too). it should be updated now. > 2. I am not sure what you mean by "maintainer script". prerm and >preinst should not ask questions. they are there to enact values >stored in the debconf cache. config, on the other hand, should >not make changes but only direct the user through the questions. i'm not quite sure what i meant either. i think it was a blurring of two different things (when debconf should prompt and when the info should be acted upon) and some late night typing to blame for it. i've removed it entirely, since the information is now better described in another part of the document, about which i'll be soon sending an update. sean -- signature.asc Description: Digital signature
Re: RFC: common database policy/infrastracture
another update for those interested: http://people.debian.org/~seanius/policy/dbapp-policy.html deb http://people.debian.org/~seanius/policy/examples/ ./ deb-src http://people.debian.org/~seanius/policy/examples/ ./ i've incorporated many of the changes discussed in the related d-d threads into the document, as well as into the database-common skeleton package. i've also added a section to the online document for a proposed installation/removal process, which outlines in much more detail the process of configuring/installing/upgrading/removing databases. input is very much appreciated for this, as it will be the foundation for the rest of the code. > what's lacking: > - the blocks of code for the .*config, .*inst and .*rm files, which > could be provided in a set of wrapper scripts to be sourced by the > individual packages. > - possibly a debhelper-like package to automatically add these blocks > of code still needs to be done, though i think it's better if we can settle on what exactly we want it to do before we go and do it. > - a demonstration package using this i'm about half way done with a proof of concept source package that will generate a generic, mysql, and postgresql version of an example database application to test this stuff out. > - further amendments to the "best practices" document based on developer > feedback. still accepting input! > - templates for pgsql and other database setups (currently only some > common templates and the mysql-centric ones) thanks to oliver for the postgre stuff. > - translations probably better to wait until the questions solidify themselves before we ask for help with this. sean -- signature.asc Description: Digital signature
Re: Maintenance of User-Mode Linux packages
Matt Zimmerman [u] wrote on 19/10/2004 03:51: Is anyone (other than martin f krafft) interested in co-maintaining some or all of the UML-oriented packages in Debian? This includes the following source packages which I currently maintain: - user-mode-linux - kernel-patch-uml - uml-utilities Things are a bit chaotic upstream at the moment, and due to real life concerns I have fallen behind on their maintenance. Manoj has recently added UML support to kernel-package, and user-mode-linux should be reworked to use that, rather than its current special-case code. I would be interested to help. Due to my own real-life restrictions (I don't have huge amounts of time to spend) I would probably try helping with uml-utilities though. IANADD yet though. regards, sven
Re: Maintenance of User-Mode Linux packages
On Tue, Oct 19, 2004 at 11:14:55PM +0200, Sven Mueller wrote: > I would be interested to help. Due to my own real-life restrictions (I > don't have huge amounts of time to spend) I would probably try helping > with uml-utilities though. IANADD yet though. These packages need someone with a lot of time to invest in them, both to rework some of the packaging and keep up with the changing directions of upstream. It would be preferable for one person (or team) to take the lot. -- - mdz
Re: Bug#277193: ITP: tagtool -- tool to tag and rename MP3 and Ogg Vorbis files
On Tue, 19 Oct 2004 10:36:59 -0500, Graham Wilson wrote: [...] > > It seems not to handle correctly even Vorbis comments, which are UTF8 > > by definition. > > Seemed to work fine for me. How are you testing this? ./configure; make; make install Then opened some correctly commented files, which resulted in errors: ** (tagtool:19653): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() and displayed comments cut at the first out-of-ASCII character. Then tried to change the comments, which subsequently appeared correctly only in tagtool. Now I see that actually it works correctly in a UTF-8 locale, but not in my pl_PL that uses ISO-8859-2, so I would guess there are some wrong/unnecessary conversions going on somewhere. -- Michał Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Re: Maintenance of User-Mode Linux packages
On Tue, Oct 19, 2004 at 02:31:12PM -0700, Matt Zimmerman wrote: > On Tue, Oct 19, 2004 at 11:14:55PM +0200, Sven Mueller wrote: > > > I would be interested to help. Due to my own real-life restrictions (I > > don't have huge amounts of time to spend) I would probably try helping > > with uml-utilities though. IANADD yet though. > > These packages need someone with a lot of time to invest in them, both to > rework some of the packaging and keep up with the changing directions of > upstream. It would be preferable for one person (or team) to take the lot. I'd help too in a team environment but again my time availability is quite intermittent (lot of spare time v/s very busy). Also, I'm still not a DD (I only miss final approval though). -- mattia :wq!
Bugzilla package in need of help
Hi list, It came to my attention that the 'bugzilla' Debian package is currently not in Sarge, due to several RC bugs. Its maintainer seems to be busy, and in order to get this package elegible for inclusion in Sarge, uploads fixing those bugs are urgently needed. Note that currently there is still a zero-day NMU policy regarding RC bugs, so every DD can help with this package. If you decide to NMU, please do correctly follow the NMU policy (see the Developers Reference for more information). If you consider this package worthy of inclusion in Sarge (note that is is in woody, so not shipping it in Sarge would be a regression, and leaving users of the Debian bugzilla package in the cold), please lend a hand. More than 1% of the popcon users actively use bugzilla at the moment. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#277426: ITP: flumotion -- Fluendo Streaming Server for audio and video
Package: wnpp Severity: wishlist * Package name: flumotion Version : 0.1.0 Upstream Author : Johan Dahlin <[EMAIL PROTECTED]> * URL : http://www.fluendo.com/ * License : GPL Description : Fluendo Streaming Server for audio and video Flumotion is a modern streaming media server built with a modular distributed design. This gives you unprecedented stability and scalability in offering your customers high-quality streaming media. Flumotion includes support for both emerging media format standards, such as Ogg/Theora, and traditional formats such as MPEG-4. This means that you can be assured your customers will be able to receive your media streams without having to download extra software to do so. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8
Re: New ClamAV version uploaded, testers wanted
This one time, at band camp, Christian Perrier said: > Quoting Stephen Gran ([EMAIL PROTECTED]): > > Hello all, > > > > I have uploaded 0.80 to experimental temporarily for testing purposes > > (it is also on p.d.o/~sgran). The two main concerns I have with > > releasing it into the wild at this point are false positives in the jpeg > > scanning code (appears to be largely the result of a bad signature, not > > the engine at this point) and the upgrade path. > > > Does this include translation changes? > > You usually pinged translators in such cases, so I think there are no > changes, but I just want to be sure..:-) 0.80-1 (in experimental) does not. -2 will incorporate your suggestions (trimming the iso list out of the translation fields altogether), so I may ask for new strings after I finalize that - I've already received a number of helpful comments, so it should be soon. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpwdIVfv78K9.pgp Description: PGP signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
Wesley W. Terpstra wrote: > Since there's one GPL question left, I am still posting to debian-legal. > The legal question is marked ** for those who want to skip the rest. > > On Mon, Oct 18, 2004 at 11:49:56AM -0700, Josh Triplett wrote: >>Whether your university owns a license or not does not really affect >>Debian. icc cannot be included in Debian main. > > No, but debian can distribute precompiled object files (legally). > The binaries I meant were the object files. I understood that. Debian can _legally_ distribute the files (which is based on whether the GPL allows it), just as Debian can legally distribute everything in contrib and non-free (or it would not be there). However, this does not mean Debian will ship it in main. >>Keep in mind that if your algorithm is as good as it sounds, it will be >>around for a long time. Even if a GCC-compiled version can't achieve >>line-speed right now, if all it needs is a 2x speedup, normal increases >>in computer technology will provide that soon enough. > > True enough, but as processors get faster, so does bandwidth. > I expect that ultimately, it will always need to be as fast as possible. Possibly; however, I think bandwidth grows far slower than CPU speed and overall system power. I do understand your concern, though. >>Consider this: any package with non-free Build-Depends that aren't >>strictly required at runtime could take this approach, by shipping >>precompiled files. For example, this has come up several times with >>Java packages that tried to just ship a (Sun/Blackdown-compiled) .jar >>file in the source package. The answer here is the same: you can't ship >>compiled files to avoid having a non-free build-depends (and shouldn't >>ship compiled files at all, even if they were compiled with a Free >>compiler); the package should always be built from source. > > That is a good argument; thank you. > >>* Upload a package to main which builds using GCC. (As a side note, you >>might check to see if GCC 3.4/3.5 produces significantly better code.) > > gcc-3.3 is not an issue; it ICEs. > gcc-3.4.2 is the version I was referring to. 1) Have you submitted a bug report on 3.3? 2) Have you tried 3.5? A great deal of work has gone into making 3.5 far better at generating optimized code, particularly with vectorization and advanced instruction sets; much of this came about due to the merging of the tree-ssa branch. I don't know that it would be 2x faster, but I wouldn't be surprised if it was quite measurably faster. >>* Supply icc-built packages either on your people.debian.org site or in >>contrib; if the latter, you need to use a different package name and >>conflict with the gcc-built package in main. > > Josselin Mouette <[EMAIL PROTECTED]> said: > >>If you really want to distribute a package built with icc, you should >>make a separate package in the contrib section, and have it conflict >>with the package in main. > > Yes, this sounds like a good plan. > > Put the normal gcc version rsgt in main where the i386 deb has: > Recommends: rsgt-icc You cannot put a Recommends from main to non-main; the strongest relationship you can declare is Suggests. > rsgt-icc sits in contrib, completely built by icc (not just some .o s) > > Conflicts: rsgt > Provides: rsgt > Replaces: rsgt Right. > If an i386 user (with contrib sourced) runs 'apt-get install rsgt' > will that make apt install rsgt-icc? That's what I hope to accomplish. No, I don't believe it will. That's why when packages change names, it is common to still produce a binary package with the old name, which does nothing except depend on the new package. That doesn't help you in this case, of course. I think all you can do is add the Suggests: rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other, and provide a brief explanation in the README.Debian of both packages. > (PS. rsgt is not the final name) Heh; naming is tricky but fun. What does "rsgt" stand for? > ** > For it to sit in contrib, would I have to include the source code in contrib > as well? Or would the fact that the source code was in main already satisfy > the GPL requirement of source availability? Packages in contrib must still be Free Software, which means they must have source available. I think this is a Policy problem, though I could be wrong. The only thing packages in contrib can do that packages in main can't is declare a Depends:, Build-Depends:, or Recommends: relationship with a non-main package; they must still follow Policy, and they must still be Free Software. I don't know that it is acceptable for the source to be in a separate source package. You should also talk with the Debian OpenOffice.org team about this; they were in discussion about how to provide the contrib openoffice.org-java package (built with a non-free JDK) without needing a separate (huge) source package in contrib. As for
an idea for next generation APT archive caching
Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this could be interesting, maybe it's just crap. Your call. Based on a normal mirror layout, the idea is to use apache's 404 hook for packages. When an existing package is requested, it is served regularly. If the file is not found, a 404 is triggered, which can be served by a CGI-like thingie that goes to retrieve the package, returns 200 instead of 404 and streams the package as the 404 error document contents while writing it to the filesystem (tee(1) style). For Release, Package, Sources, and Contents files, we need a RewriteRule. When one of these is is accessed, a call to a mirror should be made to check for updates. If there is one, download it and stream it. How do you send the newly retrieved file instead of the static file present on the filesystem? Essentially, this is the only need for a proxy, which could be implemented with a RewriteRule and a CGI. Or maybe apache can do this somehow? I think this would be an extremely simple implementation, using the proven apache for most of the work (and not the buggy twisted module that apt-proxy uses). Thus, the entire thing is reduced to a couple of httpd.conf entries and two extremely simple (?) CGIs. In addition, a cronjob runs daily to purge all files in the filesystem space, which are not referenced from any of the Packages/Sources files. This is a braindump. Please comment. Am I missing something? Would someone like to try this? I really don't have the time right now... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- 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: Reproducible, precompiled .o files: what say policy+gpl?
John H. Robinson, IV wrote: > Glenn Maynard wrote: >>On Mon, Oct 18, 2004 at 10:01:05PM -0700, John H. Robinson, IV wrote: >>I'm saying that a package built with ecc (or icc or whatever) is not >>the same package that you'll get if you build the same sources with >>gcc; it's significantly functionally different. > > The only difference is in *performance*. If there are other differences, > then there is a bug in one of the two compilers. If you are equating > performance with functionality, then we are going to have a very hard > time communicating. I'm going to ignore for the moment the fact that compilers are *not* always functionally identical, since Glenn Maynard seems to be covering that point quite effectively. Performance is certainly part of functionality, if the program is incapable of performing sufficiently in order to accomplish its task in many cases for which people will want to use it. Quoting from Wesley W. Terpestra's original message at the beginning of this thread: > Now, on to the dilemma: icc produces object files which run ~2* faster > than the object files produced by gcc when SSE2 is used. [...] > So, when it comes time to release this and include it in a .deb, I ask > myself: what would happen if I included (with the C source and ocaml > compiler) some precompiled object files for i386? As long as the build > target is i386, these object files could be linked in instead of using > gcc to produce (slower) object files. This would mean a 2* speedup for > users, which is vital in order to reach line-speed. ^^^ So when someone goes to modify the package, either the security team doing a security update or simply a user exercising their right to modify the package, and they discover that when they modify the package it suddenly gets much slower, to the point that it can no longer do the task that the original non-free-compiled binary did, they would be severely surprised and disappointed, and rightfully so. This would be a loss of functionality. The correct answer is that on a completely Free system, it never had that functionality in the first place. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Maintenance of User-Mode Linux packages
On Mon, Oct 18, 2004 at 06:51:52PM -0700, Matt Zimmerman wrote: > Is anyone (other than martin f krafft) interested in co-maintaining some or > all of the UML-oriented packages in Debian? This includes the following > source packages which I currently maintain: > > - user-mode-linux > - kernel-patch-uml > - uml-utilities > > Things are a bit chaotic upstream at the moment, and due to real life > concerns I have fallen behind on their maintenance. > > Manoj has recently added UML support to kernel-package, and user-mode-linux > should be reworked to use that, rather than its current special-case code. I'd potentially like to help, possibly along with a friend who is a UML user, but not a DD. I'll have a lot more spare time in about a month, so could potentially make a concerted effort to get things ship-shape. regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten!
