Re: Please remove RFCs from the documentation in Debian packages
On Thu, 2003-07-03 at 14:53, Cameron Patrick wrote: > On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: > > | The Debian Social Contract says "Debian Will Remain 100% Free Software"
Re: Please remove RFCs from the documentation in Debian packages
On 03 Jul 2003 23:45:56 -0500 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: > > Cameron Patrick wrote: > > > On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: > > > | Well, once you folks have come up with a definition of "software", you > > > | be sure and let us know. > > > How about "anything included in Debian"? That way we won't be in danger > > > of violating the Social Contract #1. > > > > Oh, cool. How about changing in DFSG to "Anything that can go in main or > > contrib." > > Because that's a circular definition. Saying everything in Debian is > software, is not. > > It's also the only reasonable way to define software. Or at least, the > only reasonable way I (or anyone else who has voiced their opinion on > this issue here) have come up with in 3 years, and it's not for a lack > of trying. The assumption in his suggestion was that it would no longer be the "Debian Free Software Guidelines", but the "Debian Free main/contrib Guidelines". ie: if it's going to go into main or contrib, it needs to meet the guidelines. Except for the title, the DFSG is very content-agnostic. It can be applied equally well to software, fiction, nonfiction, images, what have you. pgpsRUM6OreNP.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: > Cameron Patrick wrote: > > On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: > > | Well, once you folks have come up with a definition of "software", you > > | be sure and let us know. > > How about "anything included in Debian"? That way we won't be in danger > > of violating the Social Contract #1. > > Oh, cool. How about changing in DFSG to "Anything that can go in main or > contrib." Because that's a circular definition. Saying everything in Debian is software, is not. It's also the only reasonable way to define software. Or at least, the only reasonable way I (or anyone else who has voiced their opinion on this issue here) have come up with in 3 years, and it's not for a lack of trying. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: > On a separate but related topic, I think a much better approach would > be to handle configuration as a step entirely separate from the > install phase. Let the install be entirely quiet, and let packages > have intelligent defaults. If the package absolutely must be > configured before it can be used, then let it be non-functional until > someone actually calls dpkg-configure (which would be just like > dpkg-reconfigure except that's the only time the questions would be > asked). > > - Ted Hear, hear. There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script.
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote: > > If I ever add filtering to the notes debconf allows to be displayed, > notes that refer the user to README.Debian will be at the top of the > list to never be displayed. > > Of course, I am much more likely to bow to the pressure of notes like > the one you're apparently adding, and completly disable all notes at > some point, rather than adding filtering. I don't like arms races. > After seeing multiple attempts to use social pressure to encourage to stop the flood of debconf misusage, it's at times like this that I sometimes think Eric Troan really got this part of rpm's design right (some 7 or 8 years ago) when he completely forbade any I/O between the install scripts and the user at install time. As he put it, (paraphrased since I don't remember his exact wording) if even a small percentage of packagers indulge their desire to put up dialog boxes, the system will become extremely annoying. How prophetic he was --- or rather, how well he understood human nature. Everybody believes that *their* package has something ***so*** important to say that they have to tell the whole world about it. And perhaps I'm being too pessimistic, but trying to fix this by social pressure is like trying to shame American soccer mom's into not driving gasoline-gulping SUV's. It's never going to work. If you want to fix the problem, you have the right idea by thinking that you should perhaps simply disable all notes. That's the only solution that will stop the flood of warning messages and noices. (And perhaps by removing this crutch, packagers will be more encouraged not to grauitiously break things as the result of package upgrades, even if upstream does something stupid.) On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). - Ted
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 02:18:10AM +0200, Julien LEMOINE wrote: > On Friday 04 July 2003 01:52, Andrew Suffield wrote: > > > What do you propose ? > > > Do you think Debian must keep old version of stunnel (3.x) for > > > compatibility > > > > Given how it sounds like upstream are completely incompetent and have > > decided to gratuitously break compatibility, that sounds like a good idea. > > > > > and do not include new version ? > > > > Why wouldn't you include the new version as well? > > Yes, keep the two versions of stunnel is probably the right way to handle > this > problem. Now the problem is that stunnel is uploaded in version 4 on stunnel > package. What is the correct way to reintroduce stunnel for compatibility > reasons ? uploading a new stunnel3 package will not resolve the problem. Epoch it and upload stunnel4 as a new package. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpWoPzFgPr3C.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote: > It's more acceptable to me than the alternative: to move a good portion > of documentation to non-free where it will not be distributed by > vendors, will not be considered "part of Debian" and thus will be under > threat of removal, and will be considered a "lower class" package. So rather than call a non-free package "non-free", we should call it "free", since being free is better than being non-free? What kind of drugs have you been taking? > Fortunately, the situation you describe is unlikely to occur because few > people are perverse enough to make their software free but their > documentation very non-free. This is precisely the scenario we are currently discussing. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgp9OUk4ksYQ8.pgp Description: PGP signature
Debian mini-distribution for diskless routers
Hello all, I would like to announce a new project. The projects homepage is at http://gate-bunker.p6.msu.ru/~berk/router.html. My goal was to take Debian and make it boot from flash and work from filesystem in memory, but to do it very carefully to change as little as possible. What comes out is not a debian-based distribution but rather a boot wrapper for Debian proper. It is intended for diskless routers. Features: This is Debian stable with some packages from testing to add support for 2.5 kernels. It boots from flash and works from memory. It boots in two stages: first a script from initrd copies the root filesystem from flash to tmpfs and makes tmpfs new root, then init runs as usual. It comes with a custom packaged 2.4 kernel with extended networking capabilities. The custom kernel includes modules for many ethernet cards, which are autodetected during bootup. The system can be upgraded and additional packages can be installed from regular Debian mirrors. New precompiled kernels can be installed as debian packages from our distribution site. Feedback is welcome. Thanks, -- Vadim Berkgaut
469 packages still using dh_undocumented, check if one is yours
Hi, I came accross some sources still using dh_undocumented so I did a quick search through sids *.diff.gz files. Here is the result: find -name "*diff.gz" | xargs zgrep ':+[[:space:]]*dh_undocumented' \ | cut -f 1 -d"_" | sort -u | cut -f6- -d"/" ./dists/potato/main/source/devel/fda ./dists/potato/main/source/libs/libgd-gif ./dists/potato/main/source/otherosfs/lpkg ./dists/potato/main/source/web/cern-httpd 3dwm acfax acorn-fdisk adns adolc affiche alsaplayer am-utils amrita anthy antiword apcupsd-devel apcupsd aprsd aprsdigi argus-client ascdc asd4 aspseek at-spi atlas august ax25-apps ax25-tools bayonne bbmail bbpal bbsload bbtime bind binutils-avr bird bitcollider blackbook bnc bnlib bonobo-activation bonobo-conf bonobo-config bonobo bookview brahms bwbar cam camstream canna capi4hylafax catalog cdrtoaster cfengine cftp chasen checkmp3 chipmunk-log chrpath clanbomber clips codebreaker console-tools cooledit coriander corkscrew courier cpcieject crack ctn cutils cyrus-sasl dancer-services db2 db3 db4.0 dcgui dcl dctc dds2tar dia2sql directfb directory-administrator dotconf drscheme eb eblook elastic electric elvis epwutil erlang ethstats evolution ewipe ezpublish fcron fidelio firebird flink fluxbox fnord fort freewnn ftape-tools funny-manpages gaby gasql gato gbase gbiff gcc-2.95 gcc-2.96 gcc-3.0 gcc-3.2 gcc-3.3 gcc-avr gcc-snapshot gconf-editor gconf gconf2 gcrontab gdis gdkxft geda-doc geda-symbols gerris gimp1.2 gkrellm-newsticker gkrellm-reminder glade-2 glbiff glib2.0 gnet gnome-db gnome-db2 gnome-doc-tools gnome-gv gnome-libs gnome-think gnome-vfs gnome-vfs2 gnomesword gnu-smalltalk gnudip gnumail goo gpa gpgme gpgme0.4 gpm gpppkill gpsdrive gscanbus gstalker gtk+2.0 gtk-menu gtkglarea gtkmathview gtkwave guile-core gwave hamfax happy hesiod hmake hns2 htmlheadline hubcot hwtools i2e ibcs ic35link icebreaker iceconf icom inews intltool iog ipv6calc ipxripd ircp jabber jack-audio-connection-kit jags jailtool jenova jfbterm jigdo jless jlint jpilot junit-freenet kakasi kdrill kfocus kon2 krb4 krb5 ksocrat lablgtk lam lesstif1-1 lineakconfig linpqa lirc lm-batmon lm-sensors libapache-mod-dav libax25 libbit-vector-perl libcap libcommoncpp2 libctl libdate-calc-perl libdbi-perl libgda2 libglpng libgnomedb libgpio libjconv liblog-agent-logger-perl liblog-agent-perl liblog-agent-rotate-perl libmng libnet-daemon-perl libnet-rawip-perl libplrpc-perl libpod-pom-perl libprelude libproc-process-perl libprpc-perl libquicktime librep libsdl-erlang libsigc++-1.1 libsigc++-1.2 libsigc++ libsmi libstroke libtabe libunicode libusb libxbase mailscanner makedev manderlbot mbrowse mdk medusa meshio mew mgetty midentd mii-diag mingw32-binutils mingw32 mixer.app mmenu mnogosearch mobilemesh mondo mosix motion mova mozilla-snapshot mozilla mp3blaster mp3info mpatrol mped mpqc mtools mtrack multi-gnome-terminal multiticker murasaki muse mwavem namazu2 ncpfs net-snmp netcast netjuke nictools-nopci nmap notifyme nte nvi-m17n oaf obexftp ocaml octave2.1 oftc-hybrid oo2c openafs-krb5 openafs opendchub opengate openh323gk openmash openmosix opensp openssl overkill pam pango1.0 parted passivetex pccts pdnsd peacock phaseshift phototk pike pike7.2 pike7.4 pilot-link pimppa pinball pkf plum pong poppassd postilion powertweak ppxp-applet ppxp progsreiserfs pronto ptex-bin pybliographer pymol python-4suite python-stats python-xml-0.6 python2.1 python2.2 python2.3 qemacs qhull qm qstat quadra quota radiusclient radiusd-livingston rblcheck rdtool read-edid realtimebattle remem rfb rplay rubyunit rumba-manifold rumba-utils rumbagui rumbaview samhain sanitizer scandetd scanmail scite scrollkeeper scsitools search-ccsb sg-utils sg3-utils shadow shapetools sidplay-base skkfep smail sml-mode sms-pl sn snort soap-lite socks4-server sonicmail sortmail soup soup2 sourcenav spass speech-tools speedy-cgi-perl spidermonkey spong squidguard squidtaild stegdetect stopafter superd sympa syscalltrack tclex tclx8.2 tclx8.3 tcpquota tdb tetrinetx tex-guy texfam tik tintin++ titrax tix8.1 tkisem tkpaint tkvnc tolua torch-examples tptime tramp tsocks ucd-snmp ucspi-proxy umodpack unixodbc usbmgr uw-imap vdkxdb vdkxdb2 verilog vflib2 vflib3 vgagamespack vipec vtcl w3cam webalizer webbase wine wings3d wmcdplay wmmon wmtime wwl xbvl xclass xdb xdvik-ja xemacs21 xevil xfce xfree86 xfree86v3 xfreecd xfs-xtt xirssi xitalk xkbset xlife xmacro xmms xnc xotcl xpa xpdf xpm xracer xscorch xsmc-calc xstroke xsysinfo zebra zmailer
Re: [devel] logging for package installs
Christoph Berg wrote: > For most (some?) of these, the syslog could be used. I'd find it > convenient if the syslog (which I read through logcheck) contained > messages like "dpkg: foo 1.2.3 replaced by 1.2.4" etc. Each package > could also emit some more messages (in the style they use echo now, but > probably somewhat terser) and those people who would like to know, could > read it in the syslog. (The others probably don't even care about > debconf dialog boxes.) The problem with using the syslog is the same problem almost anything that wants to use it in a serious way faces: The syslog interface is old and very limited and not extensible. You're faced with ad-hoc data formats and parsing. This is particularly annoying if you want to do something automated with the data. Cf: logcheck. :-/ Also bug #957 and mergees. Anyway, I feel that the tool should offer at least the ability to display messages, filter messages, and log messages; what exactly is used in logging is pretty much up to the implementor. -- see shy jo pgpt27RGgg75i.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote: > > You have some free software, and it comes with a manual. You modify > > the software in a manner which suits you... but you're not allowed to > > modify the manual to reflect this change; the license of the manual > > requires that it only document the unmodified version, so any modified > > versions are at an immediate disadvantage. > > And you think this is acceptable? Why? > It's more acceptable to me than the alternative: to move a good portion > of documentation to non-free where it will not be distributed by > vendors, will not be considered "part of Debian" and thus will be under > threat of removal, and will be considered a "lower class" package. So in order to avoid damaging the self-esteem of non-free documentation packages, we should insist that they not be stigmatized with the "non-free" label and accept them into the "main"stream without discussing their freedom disabilities, lest they be treated as second class packages? Well, how can I argue with such impeccable logic? It is dishonest to bend the guidelines to conform to your personal definition of what Debian should be. We have a Social Contract and a fixed set of Guidelines that define what Debian is. If you don't like what they say, get them amended; but until that happens, every DD (or at least, everyone who's gone through the NM process) is bound by an obligation to uphold the Social Contract *as written*. > Fortunately, the situation you describe is unlikely to occur because few > people are perverse enough to make their software free but their > documentation very non-free. Right, just the few elite like the FSF. :) -- Steve Langasek postmodern programmer pgpbamen93iL6.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:10:32AM +0200, Julien LEMOINE wrote: > On Thursday 03 July 2003 19:37, Thomas Viehmann wrote: > > Julien LEMOINE wrote: > > > Secondly, to reply to every person who thinks I should have created a > > > more "user friendly" migration who did not break backwards compatibility. > > > My answer is that I have no time to implement command line support for > > > stunnel 4.x. > > Yes. But you still have the options of: > > - Publically asking if someone else has time and skill to do it. > > - Putting off the update and/or packaging the interface incompatible > > stunnel under a new name. > Yes, this is a good solution. It is a little too late now but I will use this > method for the next problem of this kind. This issue would not attract so much attention if it was really too late. It's *not* too late -- sarge hasn't released yet, and every reasonable effort should be made to get this right for sarge. You still have several options for moving this forward in a way that serves users' interests: - petition upstream to re-introduce support for commandline options - issue a call for help to the development community asking for someone to implement this - roll back to the 3.x version of stunnel by using an epoch, and commit to supporting this version even if upstream won't - roll back to the 3.x version of stunnel by using an epoch, and upload stunnel 4 under a new package name, supporting stunnel only for RC fixes Warning a user that their system has been broken should be a last resort, after all other options have been exhausted. Regards, -- Steve Langasek postmodern programmer pgpXDT2F9ThWv.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Friday 04 July 2003 01:52, Andrew Suffield wrote: > > What do you propose ? > > Do you think Debian must keep old version of stunnel (3.x) for > > compatibility > > Given how it sounds like upstream are completely incompetent and have > decided to gratuitously break compatibility, that sounds like a good idea. > > > and do not include new version ? > > Why wouldn't you include the new version as well? Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote: >> Andrew Suffield <[EMAIL PROTECTED]> writes: >> >> > On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: >> >> > That would be clause #1 of the Debian Social Contract. >> >> >> >> Where do you draw the line between software, data and documentation? I >> >> get the impression that you are reading "Debian Will Remain 100% Free >> >> Software" to mean "everything in Debian will be Free Software" instead >> >> of "all the software in Debian will be Free Software". >> > >> > Well, of *course* we do. It would be idiotic and hypocritical to >> > interpret it as "The software in Debian will be free, but the >> > documentation doesn't have to be". >> > >> > We have historically allowed some free non-software things into the >> > archive, since it doesn't matter very much. Why does anybody think >> > that allowing non-free non-software things into the archive is >> > acceptable? >> >> It all depends on how you define "free". I think that documentation, as >> long as it's freely distributable and usable, is free enough. I don't >> see any need to require documentation to be freely modifiable. > > You have some free software, and it comes with a manual. You modify > the software in a manner which suits you... but you're not allowed to > modify the manual to reflect this change; the license of the manual > requires that it only document the unmodified version, so any modified > versions are at an immediate disadvantage. > > And you think this is acceptable? Why? It's more acceptable to me than the alternative: to move a good portion of documentation to non-free where it will not be distributed by vendors, will not be considered "part of Debian" and thus will be under threat of removal, and will be considered a "lower class" package. Fortunately, the situation you describe is unlikely to occur because few people are perverse enough to make their software free but their documentation very non-free. -- Poems... always a sign of pretentious inner turmoil. pgpIs2NqxWFOe.pgp Description: PGP signature
Re: [devel] logging for package installs
Re: [devel] logging for package installs [Joey Hess <[EMAIL PROTECTED]>, Thu, Jul 03, 2003 at 05:38:46PM -0400, <[EMAIL PROTECTED]>] > - Display various fairly unimportant warnings, which are often not > useful until after the package is installed and you're using it. > - Display error messages, some fatal, and some not. > - Show progress displays (in contravention of policy of course). > - Various other indications of important and not so important things > that the maintainer script is doing. > - Remind users to read the README.Debian file. For most (some?) of these, the syslog could be used. I'd find it convenient if the syslog (which I read through logcheck) contained messages like "dpkg: foo 1.2.3 replaced by 1.2.4" etc. Each package could also emit some more messages (in the style they use echo now, but probably somewhat terser) and those people who would like to know, could read it in the syslog. (The others probably don't even care about debconf dialog boxes.) Christoph -- Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 pgp0sYGWD7hb9.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote: > On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote: > > On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: > >> Uhm, that is somehow nonsense. How can an update of a package make > >>itself uninstallable? What's the reasoning behind it? > > > > Easily. Example: > > > > Package: foo > > Version: 1.0.6-4 > > Depends: libc6 >= 2.2.0 > > > > vs. > > > > Package: foo > > Version: 1.0.7-1 > > Depends: libc6 >= 2.4.0 > > > > Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable > > (becasue there is no glibc-2.4.0 in testing) > > Please check the update_excuses, it would make package foo _not_ a > valid candidate, if that happens. That doesn't happen for circular dependencies (i.e. cycles of packages that each depend on newer versions of each other than are in testing), the reason being that if they weren't considered valid candidates then such cycles could never get into testing at all. (Invalid candidates are completely ignored - they aren't eligible for hinting, even.) Please stop saying rude things like "Please check " to the people who are trying to explain the state of play to you, because they are right: it has been like this for a long time. Example: testing: foo source package => binary foo (1.0) Depends: libfoo0 (>= 1.0) libfoo source package => binary libfoo0 (1.0) unstable: foo source package => foo (1.1) Depends: libfoo1 (>= 1.1) libfoo source package => libfoo1 (1.1) Upgrading either the foo source package alone or the libfoo source package alone renders foo uninstallable. Upgrading both simultaneously works. The latter requires manual action (or the occasional bit of guesswork by the testing scripts). It has always been this way. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 12:46:36AM +0100, Neil McGovern wrote: > How about linuxgazette? Junk, which is only barely excused because it's free. > Or any of the /usr/local/doc/ non-software based packages? No packages in Debian have files in /usr/local/doc. Doing so would be an RC bug. > Prehaps a section apart from main/non-free/non-US could be useful, as a > document such as those above don't really fit into those categories, if > you take them to mean "free software"/"restrictive licence > software"/"not for US software", which thought of by quite a few users. It's called your local library. I still haven't seen anybody come up with an actual reason why stuff like this should be shipped as part of Debian, other than "it exists". Intrinsic value is not a reason; there are many valuable things that are not packaged. Including a wide range of commercial software. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpQv0gYmUKqP.pgp Description: PGP signature
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
This one time, at band camp, Christian Marillat said: > Bill Allombert <[EMAIL PROTECTED]> writes: > > > On Thu, Jul 03, 2003 at 10:53:28PM +0200, Christian Marillat wrote: > >> Bill Allombert <[EMAIL PROTECTED]> writes: > >> > >> > The cause of the bug is essentially the lack of gnome-terminal in > >> > testing: > >> > >> No, a menu can call gnome-terminal directly, if this happen then this is > >> a bug in bsdgames. > > > > As the menu maintainer, I can assure you no menu entry or menu-method > > shipped in debian stable, testing and unstable has hard-coded reference > > to gnome-terminal. > > Yes, I know, but this user said that x-terminal-emulator is configured > to xterm and when he call a bsdgames menu enties a dialog box said that > gnome-terminal is missing. Of course files in menu-method are original > files. Then if somebody can understand this bug... It's the gnome-session terminal-emulator thing, I'm pretty sure. gnome-session can override the alternatives sytem, so that users can use their favorite apps for web borwser, terminal, etc., and I'm assuming this user has the call to terminal pointing to gnome-terminal, which isn't there. This is why they are getting an error message in gnome, rather than a silent failure, which is what I experience when it's something outside of the gnome desktop. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgplkTZvx0VkF.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 04:16:15PM -0700, David Schleef wrote: >On Fri, Jul 04, 2003 at 03:53:55AM +0800, Cameron Patrick wrote: >> On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: >> >> | The Debian Social Contract says "Debian Will Remain 100% Free Software". >> | If there are things "in Debian" that are "not free" or "not software", >> | then we may be violation of our guiding principles. >> >> The anarchism package is an excellent example of a package in Debian >> main that, although DFSG-free, is neither software nor software >> documentation. > > It's also a package that should be removed instead of being a > justification for non-social-contract-conforming packages. > How about linuxgazette? Or any of the /usr/local/doc/ non-software based packages? I think it would be a mistake to remove such items from main stream distribution. Prehaps a section apart from main/non-free/non-US could be useful, as a document such as those above don't really fit into those categories, if you take them to mean "free software"/"restrictive licence software"/"not for US software", which thought of by quite a few users. Just my 0.02UKP. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:06:26AM +0200, Julien LEMOINE wrote: > On Thursday 03 July 2003 21:36, Steve Langasek wrote: > > On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: > > > First of all, I present my excuses for having started a new debate > > > about debconf in debian-devel. > > > > > > Secondly, to reply to every person who thinks I should have created a > > > more "user friendly" migration who did not break backwards compatibility. > > > My answer is that I have no time to implement command line support for > > > stunnel 4.x. > > > > It is not your responsibility to fix all of upstream's bugs, but it *is* > > your responsibility to protect Debian users from upstream breakage as > > much as possible. This upstream change makes no sense from a usability > > standpoint; this new stunnel package would be pretty useless to me, and > > I wouldn't want to have it automatically installed on my systems if I > > were using the previous, working version. By the time a debconf note is > > sent, it's too late. > > What do you propose ? > Do you think Debian must keep old version of stunnel (3.x) for compatibility Given how it sounds like upstream are completely incompetent and have decided to gratuitously break compatibility, that sounds like a good idea. > and do not include new version ? Why wouldn't you include the new version as well? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpYYSMU3uH11.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Hi On Thursday 03 July 2003 19:37, Thomas Viehmann wrote: > Julien LEMOINE wrote: > > Secondly, to reply to every person who thinks I should have created a > > more "user friendly" migration who did not break backwards compatibility. > > My answer is that I have no time to implement command line support for > > stunnel 4.x. > > Yes. But you still have the options of: > - Publically asking if someone else has time and skill to do it. > - Putting off the update and/or packaging the interface incompatible > stunnel under a new name. Yes, this is a good solution. It is a little too late now but I will use this method for the next problem of this kind. > > Finally, since there is not really a policy about when to use debconf, > > I will respect the DFSG [1] and add a debconf warning [2] in the > > stunnel package. > > There is a difference between the social contract and the DFSG. > > As a user of stunnel: Your warning will not help me as it does not keep > stunnel from breaking. *Not* installing a totally incompatible program > where the stunnel I wanted when I said "apt-get install stunnel" would. I did not upload it. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
On Thursday 03 July 2003 21:36, Steve Langasek wrote: > On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: > > First of all, I present my excuses for having started a new debate > > about debconf in debian-devel. > > > > Secondly, to reply to every person who thinks I should have created a > > more "user friendly" migration who did not break backwards compatibility. > > My answer is that I have no time to implement command line support for > > stunnel 4.x. > > It is not your responsibility to fix all of upstream's bugs, but it *is* > your responsibility to protect Debian users from upstream breakage as > much as possible. This upstream change makes no sense from a usability > standpoint; this new stunnel package would be pretty useless to me, and > I wouldn't want to have it automatically installed on my systems if I > were using the previous, working version. By the time a debconf note is > sent, it's too late. What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility and do not include new version ? Best Regards -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
On Thursday 03 July 2003 22:49, Joey Hess wrote: > Julien LEMOINE wrote: > > Finally, since there is not really a policy about when to use debconf > > It's a pity you ignore the express wishes of the author, and the consensus > on this list as to their use. I ignore nothing and nobody, I read all reply of this thread. But I have to take a decision for this problem. It is simple to say "don't break anything", but in this case this seem very difficult to make a consensus. > > * To set up stunnel for server use, read the > >/usr/share/doc/stunnel/README.Debian file. > > If I ever add filtering to the notes debconf allows to be displayed, > notes that refer the user to README.Debian will be at the top of the > list to never be displayed. > > Of course, I am much more likely to bow to the pressure of notes like > the one you're apparently adding, and completly disable all notes at > some point, rather than adding filtering. I don't like arms races. Stunnel version with debconf warning is ready but I did not uploaded it, I don't want to disappoint users or create a new debate on debconf use. -- Julien LEMOINE / SpeedBlue
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 03:53:55AM +0800, Cameron Patrick wrote: > On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: > > | The Debian Social Contract says "Debian Will Remain 100% Free Software". > | If there are things "in Debian" that are "not free" or "not software", > | then we may be violation of our guiding principles. > > The anarchism package is an excellent example of a package in Debian > main that, although DFSG-free, is neither software nor software > documentation. It's also a package that should be removed instead of being a justification for non-social-contract-conforming packages. dave...
logging for package installs
Maybe this is a good time to present this idea I've been kicking around, but never really got anywhere with, for as long as I've been working on debconf. My idea is to add an abstraction layer for package install-related logging in debian. It seems that many maintainers like to do some or all of the following in their maintainer scripts: - Display various fairly unimportant warnings, which are often not useful until after the package is installed and you're using it. - Display error messages, some fatal, and some not. - Show progress displays (in contravention of policy of course). - Various other indications of important and not so important things that the maintainer script is doing. - Remind users to read the README.Debian file. Almost all of this is done with echo, and almost all of this is completly ignored by our users, believe it or not. I suppose that those users who see it would prefer to be able to go back and look at it later, when they're actually using the package they installed earlier. Some of them would certianly like for it to be localised. Many users would like not to see this stuff at all at install time, unless it's a real immediate error. So the basic idea is that instead of using echo for these messages, we provide some interface for them. Call it dpkg-log. I have not gotten as far as to what the interface of dpkg-log would be, or how users would configure how it displays, filters, and/or logs messages. Nor have I given much thought to what kind of data should be included in the log, though it would probably include the date, package name, log message, log type, and message importance. Nor have I thought about l10n at all. This could be bolted on the side of debconf. The abuse of debconf by maintainers who feel the need to do the kinds of things listed above certianly points at the need for this mechanism. And at least debconf has a kind of l10n framework, and some ideas about question priority. But this logging and message display is really conceptually different than debconf. Debconf is just there to ask questions. It would likely be better to design it as a separate program. Here's one way a dpkg-log program might be used, just to give the feel for the idea: #!/bin/sh if [ "$1" = configure ] && grep -q evil /etc/myconfig; then dpkg-log --priority=critical \ --warning=$"/etc/myconfig has evil in it! See README.Debian!" elsif [ "$phase_of_moon" = full ]; then dpkg-log --priority=critical \ --error=$"This package only upgrades during new moons." exit 1 fi The user would see either this: # dpkg -i mypkg.deb dpkg: Installing mypkg (1.2.3) ... dpkg: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new mypkg: /etc/myconfig has evil in it! See README.Debian! Or if they prefer, this: # dpkg --log=warning -i mypkg.deb dpkg: Installing mypkg (1.2.3) ... dpkg: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new mypkg: 1 warning logged to /var/log/dpkg.log # cat /var/log/dpkg.log Date: Thu Jul 3 17:10:33 EDT 2003 From: mypkg Package: mypkg Version: 1.2.3 Operation: upgrade Priority: critical Type: warning Message: /etc/myconfig has evil in it! See README.Debian! Notice that I assume that dpkg-log would be somewhat integrated with dpkg, such that dpkg would pass it somehow information like the package being installed, and the version being upgraded to. That's not completly necessary, as the maintainer script already has most of that information available for passing to the program, but it would be nice. One other thing this could be used for, if we find a good enough log format or write tools to process it, is for logging by dpkg of what it's doing too (there's a wishlist item that dpkg get logging support that explains some of the benefits). So /var/log/dpkg.log might really look more like this: Date: Thu Jul 3 17:10:33 EDT 2003 From: dpkg Operation: upgrade Package: mypkg Version: 1.2.3 Old-Version: 1.2.2 Priority: low Type: status Message: Installing mypkg (1.2.3) Date: Thu Jul 3 17:10:33 EDT 2003 From: dpkg Operation: upgrade Package: mypkg Version: 1.2.3 Old-Version: 1.2.2 Priority: medium Type: status Message: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new Date: Thu Jul 3 17:10:34 EDT 2003 From: mypkg Operation: upgrade Package: mypkg Version: 1.2.3 Priority: critical Type: warning Message: /etc/myconfig has evil in it! See README.Debian! Date: Thu Jul 3 17:10:33 EDT 2003 From: dpkg Package: mypkg Version: 1.2.3 Operation: upgrade Priority: info Type: status Message: Successfully upgraded mypkg (1.2.3) That's as far as I've ever gotten on how this thing could work. I see the need, it's a separate need than those that led to debconf, and are leading to the NEWS.Debian files. The need to communicate with the user as your program does something is rather engrained in us. Until that need is met with something designed just for it, we'll
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote: > Andrew Suffield <[EMAIL PROTECTED]> writes: > > > On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: > >> > That would be clause #1 of the Debian Social Contract. > >> > >> Where do you draw the line between software, data and documentation? I > >> get the impression that you are reading "Debian Will Remain 100% Free > >> Software" to mean "everything in Debian will be Free Software" instead > >> of "all the software in Debian will be Free Software". > > > > Well, of *course* we do. It would be idiotic and hypocritical to > > interpret it as "The software in Debian will be free, but the > > documentation doesn't have to be". > > > > We have historically allowed some free non-software things into the > > archive, since it doesn't matter very much. Why does anybody think > > that allowing non-free non-software things into the archive is > > acceptable? > > It all depends on how you define "free". I think that documentation, as > long as it's freely distributable and usable, is free enough. I don't > see any need to require documentation to be freely modifiable. You have some free software, and it comes with a manual. You modify the software in a manner which suits you... but you're not allowed to modify the manual to reflect this change; the license of the manual requires that it only document the unmodified version, so any modified versions are at an immediate disadvantage. And you think this is acceptable? Why? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpyRwld6JWSd.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: >> > That would be clause #1 of the Debian Social Contract. >> >> Where do you draw the line between software, data and documentation? I >> get the impression that you are reading "Debian Will Remain 100% Free >> Software" to mean "everything in Debian will be Free Software" instead >> of "all the software in Debian will be Free Software". > > Well, of *course* we do. It would be idiotic and hypocritical to > interpret it as "The software in Debian will be free, but the > documentation doesn't have to be". > > We have historically allowed some free non-software things into the > archive, since it doesn't matter very much. Why does anybody think > that allowing non-free non-software things into the archive is > acceptable? It all depends on how you define "free". I think that documentation, as long as it's freely distributable and usable, is free enough. I don't see any need to require documentation to be freely modifiable. -- Poems... always a sign of pretentious inner turmoil. pgpglFehO2Szu.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 03:54:20PM -0500, Joshua Haberman wrote: > > Without foundation, your remark serves as sloganeering, perhaps > > calculated to intimidate or silence those who are simply viewing the > > RFCs' licenses in an objective light. > > Do you always read the most malicious and manipulative motivations in > other people's words? What experiences have jaded you to the point that > you cannot presume goodwill on the part of others, even within an > organization of volunteers? People trying to pass off including non-free non-software as something which is in compliance with Debian's principles, perhaps. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpv9xNnOeo1L.pgp Description: PGP signature
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
Bill Allombert <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 10:53:28PM +0200, Christian Marillat wrote: >> Bill Allombert <[EMAIL PROTECTED]> writes: >> >> > The cause of the bug is essentially the lack of gnome-terminal in >> > testing: >> >> No, a menu can call gnome-terminal directly, if this happen then this is >> a bug in bsdgames. > > As the menu maintainer, I can assure you no menu entry or menu-method > shipped in debian stable, testing and unstable has hard-coded reference > to gnome-terminal. Yes, I know, but this user said that x-terminal-emulator is configured to xterm and when he call a bsdgames menu enties a dialog box said that gnome-terminal is missing. Of course files in menu-method are original files. Then if somebody can understand this bug... Christian
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
On Thu, Jul 03, 2003 at 10:53:28PM +0200, Christian Marillat wrote: > Bill Allombert <[EMAIL PROTECTED]> writes: > > > The cause of the bug is essentially the lack of gnome-terminal in > > testing: > > No, a menu can call gnome-terminal directly, if this happen then this is > a bug in bsdgames. As the menu maintainer, I can assure you no menu entry or menu-method shipped in debian stable, testing and unstable has hard-coded reference to gnome-terminal. Cheers -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:03:47AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > (For those who are not aware of this issue, please read #92810) > > Since the doc-rfc packages have been moved to non-free, I have just cloned > the doc-rfc RC bug (#92810) and assigned it to some other packages which > provide RFCs (for a full list see the the bug report, but more might be > affected). I advise maintainers which include RFCs in their packages to > remove the RFC documentation from them. Note that ISOC is not granted an exclusive copyright license. Therefore, one option that is open to a maintainer is to try to contact the original author of the RFC, and ask for permission to redistribute under a DFSG-compliant license. This obviously won't work for the entire RFC series, but if it is extremely important to include a particular RFC in a package for documentation purposes, this is one way to accomplish it. Also, as already has been pointed out, some of the early RFC's do not have the objectionable ISOC copyright terms in them. - Ted
Re: Debootstrap, Sid, and console-tools-libs
Hello all, Thanks to everyone who responded, I was able to set up the chroot. Indeed debootstrap was the problem. I apologise for not realizing it was fixed in the BTS. I also ran into the weird upgrade problem with libpam0g. To avoid this I had to setup the chroot using woody, then upgrade to sarge with apt, and finally upgrade to sid with apt as well. This is the long way to do it, but it works fine. I hope this helps others out there. Thanks again, -- Matthew P. McGuire 1024D/E21C0E88 CB82 7859 26B2 95E3 1328 5198 D57A D072 E21C 0E88 When choice matters, choose Debian.
Re: Please remove RFCs from the documentation in Debian packages
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Thu, Jul 03, 2003 at 03:02:59PM -0500, Joshua Haberman wrote: > > > If the separation between main and non-free is intended primarily as a > > guarantee that everything in main is DFSG-free, and that no part of the > > core distribution depends on non-free software, I completely agree with > > you. To the supporters of non-free removal, I get the impression that is > > more of a delineation between what the project morally endorses and what > > it only grudgingly supports as a service to users. > > > If you assume the former view, there is no reason to remove non-free as a > > whole, because the main/non-free split already guarantees that Debian > > proper is 100% DFSG-free. > > That does not follow. I have never heard anyone argue that guaranteeing > the freedom of Debian proper is the reason for removing non-free. There > are resources involved in maintaining the archive for non-free; its > presence on Debian servers lends credibility to the software there, > which, whether or not you believe there is a moral issue, may not be > desirable because the licensing is not consistent with Debian's primary > goals. The dropping-non-free issue is a complex one. You're right, I'm sure I oversimplified the issue. I'm not really interested in debating non-free removal at this point, and that wasn't the intent of my original post. > In contrast, the question of including non-DFSG-free documentation in > main is fairly clear-cut: one interpretation unambiguously agrees with > the Social Contract as written, and one does not. The honest solution > is to eliminate the ambiguity, not to try to argue that the ambiguity is > unimportant. > > > If you assume the latter view, there is no reason to shun the > > non-modifiability of RFCs, because they are free enough for their > > purpose, just as license texts are. > > This is also a non-sequitur. If it's a question of moral endorsement, > how can you assume that people who are concerned about this issue agree > with your definition of what is or isn't moral? I haven't presumed to define what is or isn't moral. I was stating my impression that advocates of non-free removal see main (and therefore DFSG software) as being equivalent to "what the project endorses" and non-free as "what the project does not endorse." And I am arguing that there is no reason not to endorse RFCs just as we endorse license texts. That last sentence is a personal judgement that I would guess many Debian developers would find agreement with. -- Josh Haberman Debian GNU/Linux developer
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
Bill Allombert <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 07:32:28AM +0200, Christian Marillat wrote: >> reassign 199197 bsdgames >> >> This bug isn't a gnome-terminal bug. > > By the same token, how can you pretend it is a bsdgames related bug ? This bug has been filed against this package. > The cause of the bug is essentially the lack of gnome-terminal in > testing: No, a menu can call gnome-terminal directly, if this happen then this is a bug in bsdgames. Christian
Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge)
On Thu, Jul 03, 2003 at 07:32:28AM +0200, Christian Marillat wrote: > reassign 199197 bsdgames > > This bug isn't a gnome-terminal bug. By the same token, how can you pretend it is a bsdgames related bug ? The cause of the bug is essentially the lack of gnome-terminal in testing: auric% madison gnome-terminal gnome-terminal | 1.0.55-2 | oldstable | alpha, arm, i386, m68k, powerpc gnome-terminal | 1.0.55-2.0.2 | oldstable | sparc gnome-terminal | 1.4.0.6-5 |stable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc gnome-terminal |2.2.1-1 | unstable | hurd-i386, m68k gnome-terminal |2.2.2-1 | unstable | source, alpha, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc While I understand that you cannot do much about it currently, this is still a gnome-terminal problem that need to be addressed. (and I will see what I can do about it, since it is linked to #199013). Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Please remove RFCs from the documentation in Debian packages
* Branden Robinson ([EMAIL PROTECTED]) wrote: > On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: > > I think non-free removal will seem more radical if it means that > > Debian will no longer distribute RFCs on the basis that their > > licensing is not permissive enough. > > After years of watching and waiting, I have concluded that resolving to > stop shipping non-free software in our archives will be regarded as > "radical" no matter how great or small the practical consequences. For > some people, Debian is about "apt-get install w4r3z", not about any sort > of principle. Do you resent everyone for whom Debian is a tool, not a principled political statement? > > RFCs are the end product of a community process that represents > > everything Debian stands for. > > Really? What exactly does Debian stand for, then? And what does the > IETF's process represent? 1. Transparency. Debian carries out discourse in private only under compelling circumstances. Likewise IETF working groups work over public mailing lists and publish drafts of all their work for the public to review. 2. Community involvement. It doesn't take a company or a membership fee to participate in the RFC process, which is not the case for many standards organizations. Likewise, very few of Debian's processes are closed off from public participation. 2. Open and freely-availble standards. Free software naturally favors interoperability, and the IETF has historically provided many of the standards that make this interoperability a reality. The fact that these standards are freely available makes them more accessible to free software developers working without a budget, in contrast to standards from ANSI and ISO that cost money to obtain. Is it such a stretch to recognize that the IETF is an organization whose goals and procedures are reasonably aligned with Debian's? Since you seem to favor absolute precision in language, I will concede that the IETF process may not literally represent "everything" Debian stands for, since parts of Debian's principles lay outside the scope of standardization processes. > Without foundation, your remark serves as sloganeering, perhaps > calculated to intimidate or silence those who are simply viewing the > RFCs' licenses in an objective light. Do you always read the most malicious and manipulative motivations in other people's words? What experiences have jaded you to the point that you cannot presume goodwill on the part of others, even within an organization of volunteers? -- Josh Haberman Debian GNU/Linux developer
Re: Debconf or not debconf : Conclusion
Julien LEMOINE wrote: > Finally, since there is not really a policy about when to use debconf It's a pity you ignore the express wishes of the author, and the consensus on this list as to their use. > * To set up stunnel for server use, read the >/usr/share/doc/stunnel/README.Debian file. If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. -- see shy jo pgpHKWbC3pyy8.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Cameron Patrick wrote: > On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: > | Well, once you folks have come up with a definition of "software", you > | be sure and let us know. > How about "anything included in Debian"? That way we won't be in danger > of violating the Social Contract #1. Oh, cool. How about changing in DFSG to "Anything that can go in main or contrib." Cheers T. pgpK5FoJovULU.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 03:02:59PM -0500, Joshua Haberman wrote: > If the separation between main and non-free is intended primarily as a > guarantee that everything in main is DFSG-free, and that no part of the > core distribution depends on non-free software, I completely agree with > you. To the supporters of non-free removal, I get the impression that is > more of a delineation between what the project morally endorses and what > it only grudgingly supports as a service to users. > If you assume the former view, there is no reason to remove non-free as a > whole, because the main/non-free split already guarantees that Debian > proper is 100% DFSG-free. That does not follow. I have never heard anyone argue that guaranteeing the freedom of Debian proper is the reason for removing non-free. There are resources involved in maintaining the archive for non-free; its presence on Debian servers lends credibility to the software there, which, whether or not you believe there is a moral issue, may not be desirable because the licensing is not consistent with Debian's primary goals. The dropping-non-free issue is a complex one. In contrast, the question of including non-DFSG-free documentation in main is fairly clear-cut: one interpretation unambiguously agrees with the Social Contract as written, and one does not. The honest solution is to eliminate the ambiguity, not to try to argue that the ambiguity is unimportant. > If you assume the latter view, there is no reason to shun the > non-modifiability of RFCs, because they are free enough for their > purpose, just as license texts are. This is also a non-sequitur. If it's a question of moral endorsement, how can you assume that people who are concerned about this issue agree with your definition of what is or isn't moral? -- Steve Langasek postmodern programmer pgpr5s7NAvA9N.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: > > * Branden Robinson ([EMAIL PROTECTED]) wrote: > > > On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: > > > > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > > I fully agree. Banning RFCs from debian is just silly. > > > > So, what other non-DFSG-free stuff is it "silly" to ban? Netscape > > > Navigator? Adobe Acrobat Reader? > > > Keep in mind that this hard-line stance of applying the DFSG to > > everything in the archive will probably make it more difficult to gain > > support for the non-free removal resolution. > > I think our commitment to providing a distribution consisting > exclusively of material whose license complies with the freedoms > outlined in the DFSG is far more important than the question of whether > we continue to distribute non-free alongside. If we are going to allow > documentation into main that follows a different set of rules than the > ones we use for software, the Social Contract must be amended to > unambiguously reflect this point of view. Otherwise, how are > redistributors and users supposed to know where the line is between > stuff-that's-really-free and stuff-that's-not-free-but-included-anyway? If the separation between main and non-free is intended primarily as a guarantee that everything in main is DFSG-free, and that no part of the core distribution depends on non-free software, I completely agree with you. To the supporters of non-free removal, I get the impression that is more of a delineation between what the project morally endorses and what it only grudgingly supports as a service to users. If you assume the former view, there is no reason to remove non-free as a whole, because the main/non-free split already guarantees that Debian proper is 100% DFSG-free. If you assume the latter view, there is no reason to shun the non-modifiability of RFCs, because they are free enough for their purpose, just as license texts are. -- Josh Haberman Debian GNU/Linux developer
Bug#199197: reassign general
This one time, at band camp, Joey Hess said: > reassign 199197 general > thanks > > I do not know what package this bug belongs to. I know only that it's > not bsdgames, which does not contain the string "gnome-terminal" in it. > I suspect that it's a screwup in gnome-terminal, the user's window > manager (sawfish?) or some other part of gnome, but I do not use gnome. > > If someone who does would like to track down why a menu for a text > program is being run in gnome-terminal, when gnome-terminal is not > installed, instead of using x-terminal-emulator in accordance with > policy, I'm sure the submitter of this bug report would appreciate > it. It looks to me like a gnome-session thing - the user either set, or left the default set to gnome-terminal, and on upgrade gnome-terminal was removed. The user probably needs to open the preferred applications dialog, and choose x-terminal-emulator, rather than gnome-terminal. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp2BvfKHzTkY.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Hi, On Thu, Jul 03, 2003 at 02:17:29PM -0500, Steve Langasek wrote: > On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: > > * Branden Robinson ([EMAIL PROTECTED]) wrote: > > > On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: > > > > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > > > > > > >I believe this whole case of RFC standards are not confirming to The > > > > >Debian Free Software Guidelines display a complete lack of > > > > >understanding of the value of standards, and should be rejected. > > > > >Standards are not software, nor software manuals, and should not be > > > > >treated as such. > > > > I fully agree. Banning RFCs from debian is just silly. > > > > So, what other non-DFSG-free stuff is it "silly" to ban? Netscape > > > Navigator? Adobe Acrobat Reader? > > > Keep in mind that this hard-line stance of applying the DFSG to > > everything in the archive will probably make it more difficult to gain > > support for the non-free removal resolution. > > I think our commitment to providing a distribution consisting > exclusively of material whose license complies with the freedoms > outlined in the DFSG is far more important than the question of whether > we continue to distribute non-free alongside. If we are going to allow > documentation into main that follows a different set of rules than the > ones we use for software, the Social Contract must be amended to > unambiguously reflect this point of view. Otherwise, how are > redistributors and users supposed to know where the line is between > stuff-that's-really-free and stuff-that's-not-free-but-included-anyway? Why not indeed traft a DFDG spec that includes licenses such as the GFDL and IETF's and W3C's licenses, as someone suggested, and add a separate 'Documentation' section? Things that are DFDG-free but not DFSG-free thus remain outside main, and because these things have licenses that conform to a set of defined requirements, it should conflict even less with the Social Contract than the non-free section does. So, no need for amendmends. Really, DFSG has done a lot of good. I can see a similar benefit in harmonizing the various documentation licenses, that serves Free Software and Our Users. Free Software is definitely served by standards and documentation, and convenient off line access to them. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: | Well, once you folks have come up with a definition of "software", you | be sure and let us know. How about "anything included in Debian"? That way we won't be in danger of violating the Social Contract #1. Cameron.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: | The Debian Social Contract says "Debian Will Remain 100% Free Software". | If there are things "in Debian" that are "not free" or "not software", | then we may be violation of our guiding principles. The anarchism package is an excellent example of a package in Debian main that, although DFSG-free, is neither software nor software documentation. Cameron.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 08:07:59PM +0200, Marcelo E. Magallon wrote: > Yet we let them in because they are called licenses. And no, I'm not > asking to be able to change the _contract_ between the copyright owner > and the licensee. I'm talking about the file. I'm talking about this: > > Everyone is permitted to copy and distribute verbatim copies of > this license document, but changing it is not allowed. > > It doesn't get any more non-free than that, does it? Well, actually, yes it can. It could say "all rights reserved". And, incidentally, the specific issue you address has -- I'm sure you'll be quite startled -- discussed at length on debian-legal. Maybe you ought to check out those archives? -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch pgpDPyvaJp20O.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 07:21:34PM +0100, Andrew Suffield wrote: > Well, of *course* we do. It would be idiotic and hypocritical to > interpret it as "The software in Debian will be free, but the > documentation doesn't have to be". > > We have historically allowed some free non-software things into the > archive, since it doesn't matter very much. Why does anybody think > that allowing non-free non-software things into the archive is > acceptable? Because they are emotional about it, and perceive a proclamation of "not DFSG-free" as some sort of taint. How *dare* we *condemn* the *great work* of the IETF so! Except we're not condemning it at all. The DFSG provides us with a series of tests that help us determine whether something is Free as in Freedom. RFCs under the "new license" clearly are not. Big deal. Plenty of enjoyable things in life aren't Free as in Freedom. -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. pgpYkEj3acmc7.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 02:39:21AM +0800, Cameron Patrick wrote: > On Thu, Jul 03, 2003 at 06:20:02PM +0100, Neil McGovern wrote: > | > | When the program is run, it gets put in read/write memory. > | > > So embedded firmware running from an EPROM doesn't count as a program > then? Well, once you folks have come up with a definition of "software", you be sure and let us know. -- G. Branden Robinson| Debian GNU/Linux | If existence exists, [EMAIL PROTECTED] | why create a creator? http://people.debian.org/~branden/ | pgpe9WWa2so5O.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: > First of all, I present my excuses for having started a new debate > about debconf in debian-devel. > Secondly, to reply to every person who thinks I should have created a > more "user friendly" migration who did not break backwards compatibility. > My answer is that I have no time to implement command line support for > stunnel 4.x. It is not your responsibility to fix all of upstream's bugs, but it *is* your responsibility to protect Debian users from upstream breakage as much as possible. This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. -- Steve Langasek postmodern programmer pgpv8WlinHRRc.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: > On Thu, Jul 03, 2003 at 10:51:15AM -0500, Branden Robinson wrote: > > > That would be clause #1 of the Debian Social Contract. > > Where do you draw the line between software, data and documentation? Easy. I don't. I've written about this extensively on debian-legal, and the subject has been covered several times in Debian Weekly News. Perhaps you'd care to catch up? -- G. Branden Robinson| You don't just decide to break Debian GNU/Linux | Kubrick's code of silence and then [EMAIL PROTECTED] | get drawn away from it to a http://people.debian.org/~branden/ | discussion about cough medicine. pgpHlwEbDBwh2.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:12:02PM -0400, Matt Zimmerman wrote: > On Thu, Jul 03, 2003 at 10:54:00AM -0400, Anthony DeRobertis wrote: > > > If they are not software, then under clause one of the Social Contract, > > they don't belong in debian. > > > > This has been debated several thousand times on -legal... > > I don't recall a consensus that software documentation does not belong in > Debian. That's because there wasn't one. But if one wishes to partition the stuff in Debian main into "software" and "non-software", one will need to amend the Social Contract to discuss how we handle, and what standards we apply to, non-software. The Debian Social Contract says "Debian Will Remain 100% Free Software". If there are things "in Debian" that are "not free" or "not software", then we may be violation of our guiding principles. -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch pgpAXnxhqvkfz.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: > Keep in mind that this hard-line stance of applying the DFSG to > everything in the archive will probably make it more difficult to gain > support for the non-free removal resolution. So be it. The Social Contract and the traditions of our project compel us to make principled decisions, not politically expedient ones. > I think most people perceive RFCs as being free enough for their > purpose, even though they are not DFSG-free. That's fine. Failing to satisfy the Debian Free Software Guidelines is not an indicator of moral turpitude. It just means that a work so licensed is not a good fit for the Debian Project's stated goals. > Of course you can come up with scenerios where someone could have a > completely legitimate desire to use an RFC in a derivative work, but > in comparison to situations where one wants to modify software this is > extremely infrequent. Sadly, this is probably true -- even if the RFCs *were* all DFSG-free (only the early ones are), it's difficult to persuade programmers to comment their code and document their constraints. > I think non-free removal will seem more radical if it means that > Debian will no longer distribute RFCs on the basis that their > licensing is not permissive enough. After years of watching and waiting, I have concluded that resolving to stop shipping non-free software in our archives will be regarded as "radical" no matter how great or small the practical consequences. For some people, Debian is about "apt-get install w4r3z", not about any sort of principle. > RFCs are the end product of a community process that represents > everything Debian stands for. Really? What exactly does Debian stand for, then? And what does the IETF's process represent? Without foundation, your remark serves as sloganeering, perhaps calculated to intimidate or silence those who are simply viewing the RFCs' licenses in an objective light. > (Yes, I know that non-free is not part of Debian. All I claim above is > that in the status quo Debian distributes non-free.) A distinction without a difference in the eyes of most users, hence the extremely vocal opposition. If they didn't think of non-free as "part of Debian", they wouldn't protest so loudly. -- G. Branden Robinson|I've made up my mind. Don't try to Debian GNU/Linux |confuse me with the facts. [EMAIL PROTECTED] |-- Indiana Senator Earl Landgrebe http://people.debian.org/~branden/ | pgptANy56VaAj.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Sebastian Rittau wrote: >There's no need to. But I want to have the right to change a standard >slightly, and hand it around, telling people that this is how I would >have liked the standard. I also want to have the right to enhance or >even change a standard, and use it e.g. for some internal project. I >want to quote parts of the standard in other documents or my software >(maybe even outside the "fair use" constraints). I might not be allowed >to do that. There might be other restrictions as well. Also note that "fair use" isn't a universal concept - UK law doesn't include it (the "fair dealing" provisions that deal with the same sort of thing are significantly more limited), and so any argument that something is "free enough" based on the existence of fair use provisions isn't a terribly strong one. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:10:43PM -0400, Matt Zimmerman wrote: > On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: > > > RFCs aren't software, and so applying the Debian Free /Software/ > > Guidelines to them seems a little odd. > > But...but...what if you want to make your own "RFC 2661" by embracing and > extending the existing one, and redistribute it to all your friends calling > it "RFC 2661"? It's taking away your freedom! Requiring a rename of a copyrighted work doesn't violate the DFSG. The "new" RFC license, however, does more than that. http://bugs.debian.org/92810 contains more information. -- G. Branden Robinson|A committee is a life form with six Debian GNU/Linux |or more legs and no brain. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | pgpNKdNC8URaU.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: > On Thu, Jul 03, 2003 at 12:35:06PM -0500, Branden Robinson wrote: > > | So, what other non-DFSG-free stuff is it "silly" to ban? Netscape > | Navigator? Adobe Acrobat Reader? > > Of course not. They're software. > > RFCs aren't software, and so applying the Debian Free /Software/ > Guidelines to them seems a little odd. According to the Social Contract, we promise to do so, or not to mess with such things at all. "Social Contract" with the Free Software Community 1. Debian Will Remain 100% Free Software We promise to keep the Debian GNU/Linux Distribution entirely free software. As there are many definitions of free software, we include the guidelines we use to determine if software is "free" below. We will support our users who develop and run non-free software on Debian, but we will never make the system depend on an item of non-free software. http://www.debian.org/social_contract Perhaps what we mean is that Debian will Remain 100% Free Software, except where it isn't. That's a committment certain to reassure the Free Software Community to whom we have made this pledge. -- G. Branden Robinson| Debian GNU/Linux | kernel panic -- causal failure [EMAIL PROTECTED] | universe will now reboot http://people.debian.org/~branden/ | pgp2sdDU6uzkc.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:15:19AM -0700, Philippe Troin wrote: > I like this DFDG idea (Debian Free Documentation Guidelines) :-)... Feel free to propose a General Resolution to amend the Debian Social Contract. The Project Secretary will probably tell you to wait for the GRs to disambiguate Constitution 4.1.5 first, however. -- G. Branden Robinson| When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://people.debian.org/~branden/ | pgpSQPgKN6MAc.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 01:42:01PM -0500, Joshua Haberman wrote: > * Branden Robinson ([EMAIL PROTECTED]) wrote: > > On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: > > > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > > > > >I believe this whole case of RFC standards are not confirming to The > > > >Debian Free Software Guidelines display a complete lack of > > > >understanding of the value of standards, and should be rejected. > > > >Standards are not software, nor software manuals, and should not be > > > >treated as such. > > > I fully agree. Banning RFCs from debian is just silly. > > So, what other non-DFSG-free stuff is it "silly" to ban? Netscape > > Navigator? Adobe Acrobat Reader? > Keep in mind that this hard-line stance of applying the DFSG to > everything in the archive will probably make it more difficult to gain > support for the non-free removal resolution. I think our commitment to providing a distribution consisting exclusively of material whose license complies with the freedoms outlined in the DFSG is far more important than the question of whether we continue to distribute non-free alongside. If we are going to allow documentation into main that follows a different set of rules than the ones we use for software, the Social Contract must be amended to unambiguously reflect this point of view. Otherwise, how are redistributors and users supposed to know where the line is between stuff-that's-really-free and stuff-that's-not-free-but-included-anyway? -- Steve Langasek postmodern programmer pgpnzJoJJI363.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 07:47:07PM +0200, Gerfried Fuchs wrote: > On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote: > > Gerfried Fuchs wrote: > >> Uhm, that is somehow nonsense. How can an update of a package make > >> itself uninstallable? What's the reasoning behind it? > > Because it breaks testing rule #5: "The operation of installing the > > package into "testing" must not break any packages currently in > > "testing". > Please read the output again. It claims that the install of > sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is > what I call nonsense for the broken rendered sidplay-base would be > replaced, that's what it's all about. A package should never be able to > render _itself_ broken. This is precisely what would happen if this package was installed *into testing*. Trying to move sidplay-base into testing means that its dependencies would not be satisfied, and would therefore be broken. There are packages here that need to be moved together into testing, and that requires manual hinting. > > Updating sidplay-base alone breaks the current versions of xmms-sid > > and xsidplay. This is not allowed, and thus sidplay-base is > > uninstallable. > Please read the documentation for the testing script again -- that > should already be triggered by the script. Read the part in the FAQ > about the "real, non-trivial example". This is exactly that the example > describes and what it claims to be able to do already. Well, if we trust the documentation... :) The fact is, testing is currently in such sorry shape that the daily job *cannot* test all combinations of packages that are waiting, without either OOM'ing the machine or wrapping past the 24-hour mark. This functionality is administratively disabled until such time as testing no longer looks like a holy mess. -- Steve Langasek postmodern programmer pgpPrHCSZyO1T.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
On Thursday, Jul 3, 2003, at 13:58 US/Eastern, Gerfried Fuchs wrote: Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. Hmmm, you have a good point there. I think you can still pull the stunt off with some Conflicts: lines, though...
Re: Movie
Mail received and welcome to my e-mail adventure. You need to have the Subject: aaa (3 a's) and then I can read it. Too many spammers.
Re: Debconf or not debconf
Jim Penny dijo [Wed, Jul 02, 2003 at 06:34:53PM -0400]: > > My original argument stands: we should not be telling our users that > > we broke their system, because we shouldn't be breaking it in the > > first place. In this instance, it sounds to me like a bout of > > upstream bogosity has resulted in a rather grave regression in the > > quality of the software. Why would it ever be a good idea to *not* > > give users the ability to control the program using commandline > > options? > > Because of security considerations. The configuration file is read on > startup, and then stunnel chroots away, so that it is no longer visible. > The command line interface leaked information, internal IP > structure, internal ports, etc. that a really paranoid person might > prefer not be visible. > > While it is indeed preferable to not break things, there are times when > avoiding breakage is quite difficult. This appears, to me, to be > one of those times. Many times this cases are handled by creating a transitional package: Keep stunnel as a stub package depending on either stunnel3 or stunnel4, change the description of stunnel3 explaining the situation and urging users to upgrade if possible. Even more, stunnel3 and stunnel4 can coexist - and some users will find it very valuable to have both the newest stunnel features and the ease of keeping their old configurations, or not having to be root to start a temporary or permanent new tunnel. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Please remove RFCs from the documentation in Debian packages
* Branden Robinson ([EMAIL PROTECTED]) wrote: > On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: > > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > > >I believe this whole case of RFC standards are not confirming to The > > >Debian Free Software Guidelines display a complete lack of > > >understanding of the value of standards, and should be rejected. > > >Standards are not software, nor software manuals, and should not be > > >treated as such. > > I fully agree. Banning RFCs from debian is just silly. > > So, what other non-DFSG-free stuff is it "silly" to ban? Netscape > Navigator? Adobe Acrobat Reader? Keep in mind that this hard-line stance of applying the DFSG to everything in the archive will probably make it more difficult to gain support for the non-free removal resolution. I think most people perceive RFCs as being free enough for their purpose, even though they are not DFSG-free. Of course you can come up with scenerios where someone could have a completely legitimate desire to use an RFC in a derivative work, but in comparison to situations where one wants to modify software this is extremely infrequent. I think non-free removal will seem more radical if it means that Debian will no longer distribute RFCs on the basis that their licensing is not permissive enough. RFCs are the end product of a community process that represents everything Debian stands for. (Yes, I know that non-free is not part of Debian. All I claim above is that in the status quo Debian distributes non-free.) -- Josh Haberman Debian GNU/Linux developer
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote: > On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: >> Uhm, that is somehow nonsense. How can an update of a package make >>itself uninstallable? What's the reasoning behind it? > > Easily. Example: > > Package: foo > Version: 1.0.6-4 > Depends: libc6 >= 2.2.0 > > vs. > > Package: foo > Version: 1.0.7-1 > Depends: libc6 >= 2.4.0 > > Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable > (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. >> Thanks, that explains a lot. But it still doesn't explain why the >>package holds back itself... Is this a bug in the testing script? > > No. What makes you so sure? If it is just a circular dependency problem like Björn said it should be caught already, like documented (and worked before). I never noticed before that a package seems to hold back itself though. So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:20:02PM +0100, Neil McGovern wrote: | | When the program is run, it gets put in read/write memory. | So embedded firmware running from an EPROM doesn't count as a program then? CP.
Re: Why doesn't libsidplay enter testing?
On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 >= 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 >= 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) What nudge by a maintainer are you talking about? Especially, which maintainer (testing-maintainer?) "ftp master" would be a better term. Probably Anthony Towns. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? No. From what I understand the testing script should be able to see such circular dependencies -- but a dependency that breaks itself seems to be weird. Circular dependencies are not handled well. I suppose the "feel free to submit patches" thing applies here.
Processed: reassign general
Processing commands for [EMAIL PROTECTED]: > reassign 199197 general Bug#199197: bsdgames debian X menu entries depend on gnome-terminal, not in testing (Sarge) Bug reassigned from package `bsdgames' to `general'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote: > Gerfried Fuchs wrote: >> Uhm, that is somehow nonsense. How can an update of a package make >> itself uninstallable? What's the reasoning behind it? > > Because it breaks testing rule #5: "The operation of installing the > package into "testing" must not break any packages currently in > "testing". Please read the output again. It claims that the install of sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is what I call nonsense for the broken rendered sidplay-base would be replaced, that's what it's all about. A package should never be able to render _itself_ broken. > Updating sidplay-base alone breaks the current versions of xmms-sid > and xsidplay. This is not allowed, and thus sidplay-base is > uninstallable. Please read the documentation for the testing script again -- that should already be triggered by the script. Read the part in the FAQ about the "real, non-trivial example". This is exactly that the example describes and what it claims to be able to do already. > The solution is to update all of the packages at once, which requires > manual intervention. I don't see why it would need manual intervention. Either the documentation is ahead of the script or it is wrong. It is claimed in the documentation for quite some time that this is handled automagically already and this is the whole purpose for why the packages are repeatedly mentioned in the update_output. So simply put: You don't know neither why they don't move to testing automatically like they should (and I'm quite sure that it already worked that way...). I still think that there must be a different problem here, or rather someone b0rked the script. I don't want to accuse anyone to have done it, I don't need anyone responsible for the brokeness, but I'm not sure if it's really b0rked or if there is something that I misunderstood So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Debconf or not debconf : Conclusion
Hi Sebastian! You wrote: > On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: > > Finally, since there is not really a policy about when to use debconf, > > I will respect the DFSG [1] and add a debconf warning [2] in the > > stunnel package. > > [...] > > > [1] "4. Our Priorities are Our Users and Free Software " > > As a user: You are doing me a disservice. That's one more useless > debconf warning, especially, since an automatic update is easy to > implement. Indeed. Please don't display those annoying messages. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: Debconf or not debconf : Conclusion
Hi. Julien LEMOINE wrote: > First of all, I present my excuses for having started a new debate > about debconf in debian-devel. But then, the last one didn't favor your opinion. > Secondly, to reply to every person who thinks I should have created a > more "user friendly" migration who did not break backwards compatibility. > My answer is that I have no time to implement command line support for > stunnel 4.x. Yes. But you still have the options of: - Publically asking if someone else has time and skill to do it. - Putting off the update and/or packaging the interface incompatible stunnel under a new name. > Finally, since there is not really a policy about when to use debconf, > I will respect the DFSG [1] and add a debconf warning [2] in the > stunnel package. There is a difference between the social contract and the DFSG. As a user of stunnel: Your warning will not help me as it does not keep stunnel from breaking. *Not* installing a totally incompatible program where the stunnel I wanted when I said "apt-get install stunnel" would. Cheers T. pgpSSwZtIe7kk.pgp Description: PGP signature
Re: Application
Herzlichen Dank für Ihr eMail. Meine eMailadresse hat geändert und ich bitte Sie deshalb, eMails künftig an folgende Adresse zu senden: [EMAIL PROTECTED] Herzlichen Dank! Denis Nordmann
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: > > That would be clause #1 of the Debian Social Contract. > > Where do you draw the line between software, data and documentation? I > get the impression that you are reading "Debian Will Remain 100% Free > Software" to mean "everything in Debian will be Free Software" instead > of "all the software in Debian will be Free Software". Well, of *course* we do. It would be idiotic and hypocritical to interpret it as "The software in Debian will be free, but the documentation doesn't have to be". We have historically allowed some free non-software things into the archive, since it doesn't matter very much. Why does anybody think that allowing non-free non-software things into the archive is acceptable? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgpmTN1p4YKMp.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 12:14:49PM -0500, Adam Heath wrote: > On Thu, 3 Jul 2003, Marcelo E. Magallon wrote: > > software > >n : (computer science) written programs or procedures or > >rules and associated documentation pertaining to the > >operation of a computer system and that are stored in > >read/write memory [...] > > So if you print out a program, it is no longer considered software? I'd say not, it's a written document of a program. You can't very well run a piece of paper, can you? :P > Or if you burn it to cd or dvd? When the program is run, it gets put in read/write memory. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Re: Debconf or not debconf
Herbert Xu wrote: > And getting hundreds of emails after a mass upgrade? No thanks. Admin-Email The email address Debconf should send mail to if it needs to make sure that the admin has seen an important note. Defaults to "root", but can be set to any valid email address to send the mail there. If you prefer to never have debconf send you mail, specify a blank address. This can be overridden on the fly with the DEB- CONF_ADMIN_EMAIL environment variable. -- see shy jo pgphlp3EjL0gH.pgp Description: PGP signature
Re: Kernel build dependencies for prepackaged modules
Herbert Xu <[EMAIL PROTECTED]> writes: > How many Debian users are there that will use lm-sensors and i2c > modules for a prepackaged kernel on a non-i386 architecture? I've had at least one user ask me about support for powerpc, which is the big thing that's driving me to ask. If it makes you happier, pretend I'm asking about something hardware-independent like openafs. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:54:00AM -0400, Anthony DeRobertis wrote: > If they are not software, then under clause one of the Social Contract, > they don't belong in debian. > > This has been debated several thousand times on -legal... I don't recall a consensus that software documentation does not belong in Debian. -- - mdz
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: > RFCs aren't software, and so applying the Debian Free /Software/ > Guidelines to them seems a little odd. But...but...what if you want to make your own "RFC 2661" by embracing and extending the existing one, and redistribute it to all your friends calling it "RFC 2661"? It's taking away your freedom! -- - mdz
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:01:08PM +0200, Josselin Mouette wrote: > Or else, if the standards are not free, let them in non-free. We're not > going to let non-free documents enter main just because they are called > RFC's or W3C recommendations. Yet we let them in because they are called licenses. And no, I'm not asking to be able to change the _contract_ between the copyright owner and the licensee. I'm talking about the file. I'm talking about this: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. It doesn't get any more non-free than that, does it? Marcelo
Bug#199899: ITP: gpe-taskmanager -- lists windows and kills errant programs
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: gpe-taskmanager Version : 0.13 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.handhelds.org/ * License : GPL (version 2 or later) Description : lists windows and kills errant programs gpe-taskmanager is part of the GPE Palmtop Environment. It displays a list of windows on the current display, and allows the user to kill the task which owns a particular window. This can be helpful if a program has hung and is no longer responding to direct user actions. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Please remove RFCs from the documentation in Debian packages
Le jeu 03/07/2003 à 13:00, Petter Reinholdtsen a écrit : > There seem to be someone believing that standard documents should be > treated as software. Standards are not software. Standards do not > improve if everyone is allowed to modify them and publish the modified > version as an updated version of the standard. Standards get their > value from having a rigid procedure for updates and modifications. > Software do not. There are specific licenses for dealing with this kind of stuff. You can e.g. require modified versions to be clearly marked as such. Or else, if the standards are not free, let them in non-free. We're not going to let non-free documents enter main just because they are called RFC's or W3C recommendations. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Bug#199897: ITP: gpe-filemanager -- file manager for GPE
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: gpe-filemanager Version : 0.09 Upstream Author : Damien Tanner <[EMAIL PROTECTED]> * URL : http://gpe.handhelds.org/ * License : GPL (version 2 or later) Description : file manager for GPE The GPE Filemanager provides a simple graphical interface for accessing and manipulating files. This package is part of the GPE Palmtop Environment, a free environment intended to be used on palmtop computers. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 12:35:06PM -0500, Branden Robinson wrote: | So, what other non-DFSG-free stuff is it "silly" to ban? Netscape | Navigator? Adobe Acrobat Reader? Of course not. They're software. RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. Cameron.
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:21:53PM +0200, Gerfried Fuchs wrote: > On Thu, Jul 03, 2003 at 12:50:50PM +0200, Bj?rn Stenberg wrote: > > Gerfried Fuchs wrote: > >> Yes, I've read the testing page with the FAQ and both the > >> testing_excuses and testing_output, but I can't see the reason why > >> libsidplay doesn't enter testing. > > > > I've written a little script that tries to answer precisely this type of > > question. You can run it here: http://bjorn.haxx.se/debian/ > > Thanks for the great script. It shows me that the testing script seems > to be buggy, because: Not really. See my earlier mail. > > - Updating sidplay-base makes 1 packages uninstallable on alpha: > > sidplay-base > > Uhm, that is somehow nonsense. How can an update of a package make > itself uninstallable? What's the reasoning behind it? That should be obvious: if sidplay-base is upgraded *by itself* in testing, then it will itself be uninstallable in testing. (libsidplay needs to go in at the same time, and doing such simultaneous source package upgrades generally requires action by the RM or somebody else who can mess with update_out.py directly. This sort of thing happens when library package names change.) Cheers, -- Colin Watson [EMAIL PROTECTED]
NEW packages policy.
Hi. (My apologies if -devel is the wrong place to put this - hints for better locations are appreciated.) While I understand that new packages need to be checked, I wondered whether this rule could be relaxed somewhat for soversion-changing of libraries (i.e. the advance from lib(.*)\d+ to lib\1\d+. Is the current policy of treating advances of the soversion as new package a question of principle or implementation? TIA for your answers. Cheers T. pgpkHaJFJn2LG.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 03:38:18PM +0200, Marco d'Itri wrote: > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > >I believe this whole case of RFC standards are not confirming to The > >Debian Free Software Guidelines display a complete lack of > >understanding of the value of standards, and should be rejected. > >Standards are not software, nor software manuals, and should not be > >treated as such. > I fully agree. Banning RFCs from debian is just silly. So, what other non-DFSG-free stuff is it "silly" to ban? Netscape Navigator? Adobe Acrobat Reader? -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpQ6gvnRN1y2.pgp Description: PGP signature
Debian XML Catalogs (was Re: OASIS Membership: was ...)
Quoting Jochen Voss <[EMAIL PROTECTED]>: > On Wed, Jul 02, 2003 at 05:13:18PM -0400, [EMAIL PROTECTED] wrote: > > Also, the Debian implementation of XML > > catalogs will very likely be included as one example in the OASIS > > implementation guide for XML Catalogs. So we _are_ making a difference. > > This is interesting. But is there actually such a thing like a > "Debian implementation of XML catalogs". I was under the impression > that packages like docbook-xml[1] and scrollkeeper[2] prefer to not > register their xml files at the moment and that there are currently > no working xml catalogs on Debian systems. You're quite right. Ardo & I (with helpful input from Adam DiCarlo) have been working on the policy and the infrastructure packages for the last few months. I have the first policy draft complete, but due to the fact that I'm in the process of relocating and job-hunting (and am using someone else's floppy-free Mac to do webmail) I don't presently have the time or the means to check-in or upload any files. Early next week Ardo & I should have both of our relative stuff ready and uploaded. At that time I'll post an announcement to debian-devel. Cheers, Mark
Bug#199896: ITP: libdm -- display migration support for GTK
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: libdm Version : 0.25 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.handhelds.org/ * License : GPL Description : display migration support for GTK libdm provides support for moving running GTK applications between different X displays. X properties are used to advertise that windows are capable of migration, and to request windows to migrate to a specified display. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
On Thu, Jul 03, 2003 at 04:51:49PM +0200, Marc Haber wrote: > In the past years, I have found it annoying that the eicar anti-virus > testfile is not available as aptable Debian package. Why is this annoying? The virus cannot be detected without it? > I find it disturbingly impolite to say "sorry, we don't want your > volunteer work" _after_ the work has been done. Especially if it is done > in Mr. Troup's usual "why did you bother me in the first place, mere > mortal" style. Frankly, with this particular one, I entirely fail to see why you ignore several perfectly valid reasons laid out in the reasonably polite (if a bit dazzled) rejection notice and go off ranting instead. (I don't want to quote them without permission.) -- 2. That which causes joy or happiness.
Sorry.
Sorry, I will try to learn to reply to the correct list. (Incidentally, on my first attempt, I claimed that I will learn but wrote only to myself...) Cheers T. pgpqgdnAkSlw7.pgp Description: PGP signature
Re: Debconf or not debconf
Marc Haber wrote: > On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu > <[EMAIL PROTECTED]> wrote: >>I for one am sick and tired of useless Debconf messages popping up >>during installation or being sent to me via email when I'm upgrading >>hundreds of machines automatically. > Just go ahead and pre-seed your debconf database appropriately before > upgrading. Funnily, Russel Coker explained something about this while explaining why he turned away from Micro$oft in the Interview mentioned on debian-planet today... Excessive usage of debconf notices is a bug which should be avoided/fixed, not worked around. Cheers T. pgpvFTqoLkhJL.pgp Description: PGP signature
Bug#199894: ITP: libtododb -- library that provides access to a to-do list database
Package: wnpp Version: unavailable; reported 2003-07-03 Severity: wishlist * Package name: libtododb Version : 0.02 Upstream Authors: Philip Blundell <[EMAIL PROTECTED]> Luis Oliveira <[EMAIL PROTECTED]> * URL : http://gpe.handhelds.org/ * License : LGPL Description : library that provides access to a to-do list database libtododb provides an interface for programs to access and modify a list of tasks which the user needs to carry out. Notes: libtododb is a dependency of more recent versions of gpe-todo. It is also used by other GPE applications not yet in Debian, such as the 'Today' display, to access the to-do database. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux ascendit 2.4.21 #4 Sun Jun 22 18:42:14 BST 2003 i686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Please remove RFCs from the documentation in Debian packages
On Thursday, Jul 3, 2003, at 07:00 US/Eastern, Petter Reinholdtsen wrote: [Javier Fernández-Sanguino Peña] (For those who are not aware of this issue, please read #92810) There seem to be someone believing that standard documents should be treated as software. Standards are not software. If they are not software, then under clause one of the Social Contract, they don't belong in debian. This has been debated several thousand times on -legal...
Re: Please remove RFCs from the documentation in Debian packages
"Marco d'Itri" <[EMAIL PROTECTED]> writes: > On Jul 03, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > >I believe this whole case of RFC standards are not confirming to The > >Debian Free Software Guidelines display a complete lack of > >understanding of the value of standards, and should be rejected. > >Standards are not software, nor software manuals, and should not be > >treated as such. > I fully agree. Banning RFCs from debian is just silly. Wait, we're thinking about banning most of the GNU documentation too, since it's GFDL'ed (the libc, emacs, and gdb manuals for example), or putting it under non-free. I like this DFDG idea (Debian Free Documentation Guidelines) :-)... Phil.
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: > Finally, since there is not really a policy about when to use debconf, > I will respect the DFSG [1] and add a debconf warning [2] in the > stunnel package. [...] > [1] "4. Our Priorities are Our Users and Free Software " As a user: You are doing me a disservice. That's one more useless debconf warning, especially, since an automatic update is easy to implement. - Sebastian
Re: Please remove RFCs from the documentation in Debian packages
On Thu, 3 Jul 2003, Marcelo E. Magallon wrote: > software >n : (computer science) written programs or procedures or >rules and associated documentation pertaining to the >operation of a computer system and that are stored in >read/write memory [...] So if you print out a program, it is no longer considered software? Or if you burn it to cd or dvd?
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 01:00:47PM +0200, Petter Reinholdtsen wrote: > There seem to be someone believing that standard documents should be > treated as software. Standards are not software. Standards do not > improve if everyone is allowed to modify them and publish the modified > version as an updated version of the standard. There's no need to. But I want to have the right to change a standard slightly, and hand it around, telling people that this is how I would have liked the standard. I also want to have the right to enhance or even change a standard, and use it e.g. for some internal project. I want to quote parts of the standard in other documents or my software (maybe even outside the "fair use" constraints). I might not be allowed to do that. There might be other restrictions as well. I don't want to have the right to call these modified documents "RFCs" or "standards", though. Please don't confuse these two issues. This is something that we already allow - see some software licenses that we consider free that require derived versions of the software to change the name of the software. - Sebastian
Re: No crc32 package in Debian?
#include * Xavier Roche [Thu, Jul 03 2003, 04:15:22PM]: > I was looking for the very simple "crc32" binary to compute checksums for > files, and couldn't find it. There is a crc32 perl lib, but no crc32 package. > I know that md5 (or even sha-160) hash fingerprints are better, but in many > cases (like tar archives on tapes, or ftp files) you have only CRC-32. apt-cache search crc check apt-cache show cfv cksfv MfG, Eduard. -- Lieber Kinder zuhause, bitte nicht poppen, da ist am ende alles kleiner als am Anfang :)
Debconf or not debconf : Conclusion
Hello, First of all, I present my excuses for having started a new debate about debconf in debian-devel. Secondly, to reply to every person who thinks I should have created a more "user friendly" migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. Thanks for all your comments. Best Regards. [1] "4. Our Priorities are Our Users and Free Software " [2] Description: general notes about stunnel * stunnel 4.x does not support any more command line arguments, so you need to edit /etc/stunnel.conf by hand if you are upgrading from stunnel 3.x * For stunnel versions >= 4.04-4, the file /etc/default/stunnel is provided and you need to set ENABLED=1 to allow stunnel to be started from init.d * To set up stunnel for server use, read the /usr/share/doc/stunnel/README.Debian file. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf
#include * Herbert Xu [Thu, Jul 03 2003, 12:27:24PM]: > >> I'd prefer no interaction at all during installation. I'm perfectly > >> able to read documenation thank you very much. > > > > Happily, the noninteractive debconf frontend exists. > > And getting hundreds of emails after a mass upgrade? No thanks. We need a mail collector in debconf to send them all in one digest mail. MfG, Eduard. -- morgen! was ist morgen? aehm, mittwoch!
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 10:51:15AM -0500, Branden Robinson wrote:
> That would be clause #1 of the Debian Social Contract.
Where do you draw the line between software, data and documentation? I
get the impression that you are reading "Debian Will Remain 100% Free
Software" to mean "everything in Debian will be Free Software" instead
of "all the software in Debian will be Free Software". There's a good
deal of packages in Debian that can't be classified as "software" no
matter how you twist the definition. WordNet provides a lax
definition:
From WordNet (r) 1.7 [wn]:
software
n : (computer science) written programs or procedures or
rules and associated documentation pertaining to the
operation of a computer system and that are stored in
read/write memory [...]
foldoc has this comment on the subject:
Some claim that {documentation} (both paper and electronic) is
also software. Others go further and define software to be
programs plus documentation though this does not correspond
with common usage.
To be fair, I'm not going to mention "anarchism". But what do you do
with all the LG packages? And several kinds of "theme" packages? And
the fortune packages? And the dictionaries? Think about your answer,
we can't package random data just because it can be consumed by some
program in the distribution.
Marcelo
Re: Bug#199874: ITP: molmol -- Display and analyze structures of biological macromolecules
On Thu, 3 Jul 2003, Frank Küster wrote: > * License : non-free (academic type "use me, but cite men in > publications") The license has a statement: This package may only be bundled in other software packages with the explicit permission of the copyright holders. Please make sure that the copyright holders allow inclusion into Debian and add this statement to the debian/copyright file. Kind regards Andreas.
Re: Why doesn't libsidplay enter testing?
Gerfried Fuchs wrote: > Thanks for the great script. It shows me that the testing script seems > to be buggy, because: > > > - Updating sidplay-base makes 1 packages uninstallable on alpha: > > sidplay-base > > Uhm, that is somehow nonsense. How can an update of a package make > itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: "The operation of installing the package into "testing" must not break any packages currently in "testing". Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. The solution is to update all of the packages at once, which requires manual intervention. As Colin Watson said, this has already been mentioned to the maintainer so the packages should be going in soon. -- Björn
