Work-needing packages report for Aug 22, 2003
Report about packages that need work for Aug 22, 2003 Total number of packages offered up for adoption: 58 Number of packages offered up for adoption this week: 0 Total number of orphaned packages: 193 Number of packages orphaned this week: 19 The number in parenthesis after each package name is the corresponding bug report number. Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages are orphaned: [NEW] amiwm (#206021), orphaned 3 days ago (non-free) Description: The Amiga look-alike window manager [NEW] bblaunch (#206256), orphaned 2 days ago [NEW] bibview (#206137), orphaned 3 days ago Description: X11 Bibliography database tool [NEW] bnc (#206490), orphaned yesterday [NEW] boust (#206023), orphaned 3 days ago Description: A tcl/tk text-reader that formats the file in boustrophedon [NEW] bulkmail (#206102), orphaned 3 days ago (non-free) Description: Speed up delivery of e-mail to large numbers of recipients [NEW] crm114 (#206105), orphaned 3 days ago Description: Controllable Regex Mutilator and Spam Filter [NEW] freedict (#206113), orphaned 3 days ago Description: Freedict Reverse Depends: dict-freedict [NEW] pftp (#206119), orphaned 3 days ago Description: Fast file transfer program [NEW] phototk (#206121), orphaned 3 days ago Description: GUI interface for digital cameras [NEW] python-simpy (#206274), orphaned 2 days ago Reverse Depends: python-simpy [NEW] rsxs (#205725), orphaned 5 days ago Description: Really Slick X Screensavers [NEW] scotty (#206279), orphaned 2 days ago Description: The Scotty and Tkined Network Management Tools [NEW] sn (#206025), orphaned 3 days ago Description: Small NNTP server for leaf sites [NEW] squishdot (#206101), orphaned 3 days ago Description: Web-based News/Discussion System [NEW] w3mir (#206103), orphaned 3 days ago Description: All purpose HTTP copying and mirroring tool [NEW] whirlgif (#206112), orphaned 3 days ago (non-free) Description: Create animated GIFs [NEW] zircon (#206116), orphaned 3 days ago Description: Powerful X Internet Relay Chat client [NEW] zope-tinytable (#206114), orphaned 3 days ago Description: Present tabular data in Zope Reverse Depends: squishdot Pente (#195686), orphaned 81 days ago Description: Five in a row game for X and the console addressbook (#174699), orphaned 234 days ago Description: Tk personal address manager animals (#202174), orphaned 32 days ago Description: Traditional AI animal guessing engine using a binary tree DB Reverse Depends: junior-games-text arpd (#191870), orphaned 109 days ago Description: User-space ARP daemon aseqview (#201357), orphaned 37 days ago Description: ALSA Sequencer Event Viewer asis (#154095), orphaned 393 days ago Description: Ada Semantic Interface Specification Reverse Depends: gch asis-programs libasis-3.14p-1-dev awesfx (#199241), orphaned 53 days ago Description: various utility programs for controlling AWE32/64 driver axyftp (#192677), orphaned 104 days ago Description: A graphical ftp program with Lesstif interface bbdate (#190190), orphaned 121 days ago Description: Date tool for the blackbox window manager bbppp (#190188), orphaned 121 days ago Description: PPP tool for the blackbox window manager bbtime (#190191), orphaned 121 days ago Description: Time tool for the blackbox window manager bg5cc (#189818), orphaned 123 days ago Description: Big-5 wide-characters rectifier bg5ps (#189816), orphaned 123 days ago Description: A utility to print Chinese Big5/GB documents using TrueType fonts blackened (#175101), orphaned 231 days ago Description: A feature rich ircII based IRC client blatte (#188179), orphaned 135 days ago Description: a powerful text markup and transformation language bock (#201409), orphaned 37 days ago Description: Bootstrap-only compiler kit for a subset of Java(tm) catalog (#187128), orphaned 142 days ago Description: Tool to create,maintain and display Yahoo! like directories cbb (#166249), orphaned 301 days ago Description: The Check-Book Balancer, a Quicken clone cce (#189523), orphaned 125 days ago Description: Console Chinese Environment - display Chinese (GB) on console ccf (#189529), orphaned 125 days ago (non-free) Description: Chinese encodings (GB/Big5/HZ) conversion filter chameleon (#200974), orphaned 40 days ago Description: Application for putting pictures or color in the root window cost (#169556), orphaned 277 days ago Description: General-purpose SGML/XML post-processing tool. cxhextris (#150862), orphaned 423 days ago (non-free) Description: Color version of hextris
Release-critical Bugreport for August 22, 2003
Bug stamp-out list for Aug 22 06:00 (CST) Total number of release-critical bugs: 807 Number that will disappear after removing packages marked [REMOVE]: 17 Number that have a patch: 142 Number that have a fix prepared and waiting to upload: 26 Number that are being ignored: 20 Explanation for bug tags: P pending + patch H help M moreinfo R unreproducible S security U upstream Some bugs have an additional set of tags indicating they only apply to a particular release: O for oldstable (potato), S for stable (woody), T for testing (sarge) or U for unstable (sid). -- Package: a2ps (debian/main) Maintainer: Masayuki Hatta [EMAIL PROTECTED] 191372 [ + ] a2ps: Package built from source has .el files in root directory Package: aboot (debian/main) Maintainer: Gregory W. Johnson [EMAIL PROTECTED] 205864 [] aboot: FTBFS Package: adbbs (debian/main) Maintainer: Kai Henningsen [EMAIL PROTECTED] 190117 [ + ] adbbs: Default Configuration Uses pine pico Package: aime (debian/main) Maintainer: Ed Boraas [EMAIL PROTECTED] 172566 [] aime: fills up /var diskspace until it is overflowing Package: airsnort (debian/main) Maintainer: Noel Koethe [EMAIL PROTECTED] 206426 [] airsnort: (m68k/unstable) FTBFS: ../../mkinstalldirs: ../../mkinstalldirs: No such file or directory Package: alcovebook-sgml (debian/main) Maintainer: Yann Dirson [EMAIL PROTECTED] 205630 [ + ] alcovebook-sgml: Fails to install Package: alsa-base (debian/main) Maintainer: Debian-Alsa Psychos [EMAIL PROTECTED] 200686 [] alsa-base must conflict with older versions of alsa-utils Package: alsa-driver (debian/main) Maintainer: Debian-Alsa Psychos [EMAIL PROTECTED] 199940 [] alsa-driver: debhelper builddepends version too low Package: alsaplayer (debian/main) Maintainer: Ivo Timmermans [EMAIL PROTECTED] 200956 [ H R ] alsaplayer doesn't build on s390 Package: amavis-ng (debian/main) Maintainer: Hilko Bengen [EMAIL PROTECTED] 206223 [ + ] amavis-ng: cannot be installed 206625 [ + ] amavis-ng: the FSAV.pm module improperly handles the result code of the virus scanner Package: amavisd-new-milter (debian/main) Maintainer: Brian May [EMAIL PROTECTED] 203545 [] amavisd-new-milter: /usr/sbin/amavis-milter always fails Package: animals (debian/main) Maintainer: Jim Lynch [EMAIL PROTECTED] 195404 [] animals: FTBFS with g++-3.3: strstream.h is gone Package: anon-proxy (debian/main) Maintainer: David Spreen [EMAIL PROTECTED] 206304 [] anon-proxy: doesn't state shared library dependencies properly Package: apache2-mpm-prefork (debian/main) Maintainer: Thom May [EMAIL PROTECTED] 203093 [P ] Should be able to still uninstall if can't stop apache Package: apcupsd-devel (debian/main) Maintainer: Samuele Giovanni Tonon [EMAIL PROTECTED] 203937 [] Source does not build correctly Package: apmd (debian/main) Maintainer: Chris Hanson [EMAIL PROTECTED] 205343 [] apmd_3.2.0-5(unstable/ia64): FTBFS: `platform_inb' undeclared Package: apt-build (debian/main) Maintainer: Julien Danjou [EMAIL PROTECTED] 206635 [ + ] apt-build: Global symbol $new requires explicit package name Package: aptitude (debian/main) Maintainer: Daniel Burrows [EMAIL PROTECTED] 201259 [] aptitude on PPC/testing can not be installed via apt Package: arla (non-US/main) Maintainer: Mikael Andersson [EMAIL PROTECTED] 198294 [] arla: FTBFS with gcc-3.3: Invalid preprocessor pasting Package: arla-modules-source (non-US/main) Maintainer: Mikael Andersson [EMAIL PROTECTED] 203908 [ U ] arla-modules-source: unresolved symbols with upstream and debian sources Package: armagetron (debian/main) Maintainer: Andreas Bombe [EMAIL PROTECTED] 201638 [] armagetron_0.2.2-1(alpha/unstable): not 64-bit clean Package: arson (debian/main) Maintainer: Mike Markley [EMAIL PROTECTED] 195214 [ U ] arson: conflicts with a file from k3b Package: atari800 (debian/contrib) Maintainer: Dale Scheetz (Dwarf #1) [EMAIL PROTECTED] 193397 [] atari800_1.3.0-2(mipsel/unstable): out of date config.sub/config.guess 203707 [ + SU ] atari800 allows local root compromise. Package: atlas (debian/main) Maintainer: Camm Maguire [EMAIL PROTECTED] 192990 [] atlas_3.2.1ln-7(unstable/arm): FTBFS Package: atmelwlandriver (debian/main) Maintainer: Paul Hedderly [EMAIL PROTECTED] 201053 [] atmelwlandriver_2.1.1-3.1(hppa/unstable): FTBFS: bad build-depends Package: autoconf (debian/main) Maintainer: Ben Pfaff [EMAIL PROTECTED] 156259 [] [S] db4.0: does not build from source Package: autoinstall (debian/main) Maintainer: Jeff Licquia [EMAIL PROTECTED] 206652 [] autoinstall: rules files is broken, package undermaintained Package: autoinstall-i386 (debian/main) Maintainer: Jeff
Nuova manifestazione di OpenLabs il 30 agosto a Milano
Ciao a tutti, OpenLabs sta organizzando un giorno ludico per festeggiare i 10 anni di Debian. (Ogni scusa è buona per giocare ... :-) Molto probabilmente ci sarà anche una sezione di hacking per chi voglia dedicarsi, magari in gruppo, a sistemare qualche RC bug in vista della release di fine anno. Questa seconda sezione si protrarrà per tutta la notte. Vi chiederei di organizzarci qui per vedere chi è interessato ad andarci e per selezionare i bug da sistemare. Si seguito, il messaggio originale. Ciao, Giuseppe Basta con corsi, seminari, dottorati, saldatori e masterizzatori! Quale occasione migliore per un sabato ludico? Alla faccia di chi dice che con Linux non ci si giuoca e approfittando della calma piatta di questo mese sei invito a partecipare al primo OpenLanParty dedicato a Debian per il suo primo 10 compleanno. Non e' una limitazione per chi partecipare ma una scusa vale l'altra per giocare, quindi sono ben accetti cappelli rossi, diavoletti con sparp' da tenis, cani gialli, samaleonti, ecc. Insomma non c'e' limite di bestialita' ma attenzione che i giochi siano di versioni coerenti. Sabato 30 agosto 2003 dalle 10:00 alle 22:00 (12 ore) di colpi bassi a suon di giochi a licenza aperta nelle due aule di OpenLabs via Ornato 7 Milano (citofonare tensioniCrative) Non e' da escludersi una successiva birra per chiudere le ostilita'. Come funziona? Ci saranno gadget Debian in vendita un cui ricavato andra' a finanziare il progetto: adesivi, CD di Woody e Knoppyx 3.2 (donati da OpenLabs) e le magliette della Debian (Debian Italia). Semplice, si porta il proprio computer (portatile e non) noi mettiamo una presa di rete e una di alimentazione. Gratite patatine, beveraggio (c'e' il frigo), dolcumi di varia forma e colore. Si gioca solo con giochi (Free) presenti su Debian GNU/Linux. Altre proposte ben accette anche perche' c'e' a disposizione connettivita' (fastweb) per scaricare cio' che puo' servire. Per ogni partita registreremo i risultati del torneo. NB: per i giochi in OpenGL sono necessari computer con accellerazione 3D (possibilemente gia' configurata se non c'e' troppo casino vi si da una mano a farlo). A cosa si gioca? -- Le proposte iniziali sono le seguenti graditissime aggiunte. Sezione Console netris Tetris in rete multiplayer ( http://www.netris.org/ ) moon buggy Vintage gaming a caratteri ( http://hangout.de/moon-buggy/ ) Sezione X Gtetrinet Tetris in rete multiplayer ( http://gtetrinet.sourceforge.net/screenshots/screenshot1.gif ) Tag Simil Risiko via rete multiplayer ( http://teg.sourceforge.net/#screenshots ) xblast bomberman in rete max in 6 a lanciarsi bombe ( http://www.xblast-center.com/ ) Sezione 3D TuxRacer Una bella discesa col pinguino! OpenGL ( http://www.tuxracer.com/index.php?page=screenshots.php ) Quake II Dopo doom venne Quake! OpenGL ( http://www.idsoftware.com/games/quake/quake2/ ) Doom Legacy versione OpenGL del mitico Doom ( http://legacy.newdoom.com/ ) BzFlag Arena multiplayer OpenGL ( http://www.bzflag.org/screenshots/ ) Armagetron gioco in OpenGL ispirato a Tron ( http://armagetron.sourceforge.net/screenshots.html ) Crack Attack tetris in OpenGL ( http://www.aluminumangel.org/attack ) CannonSmash ping pong da tavolo in OpenGL ( http://cannonsmash.sourceforge.net/ )
Re: someone interested in adopting grub-client?
Hi! grub-client is a distributed webcrawler client written in c++. The biggest problem with it is that it simply doesn't work, and I don't grok why. I'm not that familar with c++ and multithreading and don't know where to look for the bug. Furthermore it seems that on the search engine front (for which the client crawls) there is no real progress so I can't say where this project leads to. I am not sure if there are really people interested, so if noone likes to pick it up I'll request the removal of the package from testing and unstable. I don't see any sense in having the package in the pool when there is no real interest in it, especially if it has a release critical bugreport on it that I can't track down. Mail Cc'ed to the RC bugreporter, maybe he is interested to work on the issue and adopt the package. Jim, if you like to do it I am willing to sponsor you. The part about sponsoring this package holds for everyone else too, btw. So long, Alfie -- * *sigh* I finally upload a fixed get-foo-flags and the next day a new upstream comes out. * oh, new upstream, btw. -- Marcelo E. Magallon, changelog.Debian for wmaker (0.64.0-1) /me raises hand I'd be willing to give it a shot :P I'm no official debian maintainer/developer , but I do want to become one . D. Stibbe
Reply from Linux usage counter
The subject line of your message was Re: Wicked screensaver. This did NOT contain the word Linux. The counter has unfortunately been the recipient of many sorts of messages, some of which were not intended as registrations. Therefore, the subject line MUST include Linux to perform a simple registration. Please include the word Linux in the subject line, perform a registration using the form below, or register using the Web forms at http://counter.li.org/ in order to register. If you have any unusual problems - contact [EMAIL PROTECTED] HELP FOR THE LINUX USAGE COUNTER This message is intended for you to edit, and send right back to the [EMAIL PROTECTED] address. DO NOT USE REPLY!!! (Practice has shown that putting the counter in the Reply-To: or From: fields of a message is a GREAT way of causing mail loops, and defending against them is a *lot* of effort. Therefore, this counter does not do it) There are two ways of registering: Simple and complex. For the SIMPLE method, simply send a message with the subject line being one of: I use Linux at home I use Linux at work I use Linux at school I do not use Linux You can also do combinations, like I use Linux at home and at work. The counter will attempt to guess your country of origin, and count you accordingly. Information about you will not be made public. Complex registration The complex features of the counter are accessed by using commands. A command looks like (for instance) //MACHINE, and starts in the left column. You can register MACHINES, FRIENDS and data about YOURSELF (PERSON). Below is listed an example of each of the sections, with comments that aid you in filling them out correctly. Remember to put the value on the same line as the field name! Only use the FRIENDS section if it is unlikely that the people will register themselves! When the templates are accepted by the daemon, they will be added to the database. Data will be added even if it is not parsed properly. They may be thrown out in later duplicate elimination, or you may receive a query from me regarding the validity of the data, but otherwise, they will be counted. You can also register using the WWW forms at http://domen.uninett.no/~hta/linux/counter.html You can get a report from the counter by specifying the command //REPORT reportname The following reports are available: short- The standard listing of Linux usage, including per-country data machines - Statistics on registered Linux machines persons - Persons who use Linux, sorted by country, and some statistics All these reports are also available by anonymous FTP to aun.uninett.no, directory pub/misc/linux-counter, or through the World Wide Web at http://domen.uninett.no/~hta/linux/counter.html The counter also understands //HELP. When you use a command, the subject line of the message is *not* recorded in the counter. Good luck! Harald Tveit Alvestrand Sorry, the record help is out of order //END The END command is only required if you have a mailer that adds stuff below the last line of the message. This is the Linux Counter summary as of Fri Aug 22 01:35:45 2003 There are 137075 persons registerd. 1407 users have been registered by friends. There are 121886 machines registered. I guesstimate that between 0.2% and 5% of all Linux users have registered with the Linux Counter. So the total number of Linux users is probably between 2,741,500 and 68,537,500 people. WHERE LINUX USERS LIVE The table is sorted by number of Linux users divided by population NoCountry Pers Fri Mach P/Mpop Mpop == 1 FO Faroe Islands 500 20 1140.10.0 2 AQ Antarctica 303 729.00.0 3 TK Tokelau 100 674.80.0 4 IS Iceland1761 148 651.10.3 5 FI Finland 3114 21 3126 610.05.1 6 NO Norway2168 24 2480 494.54.4 7 DK Denmark 25616 2268 487.85.2 8 EE Estonia707 12 562 484.41.5 9 FK Falkland Islands (Islas Malv 103 421.20.0 10 SJ Svalbard and Jan Mayen 100 368.30.0 11 SE Sweden3235 30 3926 363.48.9 12 SH Saint Helena 200 294.90.0 13 LU Luxembourg 1140 151 274.10.4 14 GI Gibraltar702 243.40.0 15 SI Slovenia 4681 342 239.82.0 16 NL Netherlands 3559 17 3954 228.6 15.6 17 NZ New Zealand7670 814 216.23.5 18 HU Hungary 2082 17 1845 208.1 10.0 19 SM San Marino 503 203.90.0
Re: Latest gcc-3.3 and kernel compilation
On Fri, 22 Aug 2003 02:37, Marc Singer wrote: Are we expecting the latest unstalble gcc compiler to correctly compiler the kernel? Yes, as others have mentioned the code in question is buggy. If the code is in a Debian kernel-source or kernel-patch package then please file a bug report. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Returned Mail
On Fri, 22 Aug 2003 11:51, [EMAIL PROTECTED] wrote: I am receiving notices of returned mail from people that I never wrote to or do not know. Why am I getting these. Today I've gotten at least 10. I hope I'm reporting this to the correct person. Please help if possible. It's a virus. Email viruses generally fake the From: field of the messages that they send out. Therefore some virus messages will have your address in the From: field, and you will receive virus warnings and responses from all sorts of auto-responder programs. The anti-virus messages are generally spam advertising anti-virus software, report it to your favourite spam prevention service. For the auto-responders you can write to them directly and ask them to make their machines stop sending email to you. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: GR: Disambiguation of Section 4.1.5 of the constitution
Hi folks, Since I am no longer merely an interested observer in the GR process, this is going to be hard. When we talked about this the last time around, in the summer on 2000, there were two camp, with two wildly different interpretations of the constitution. Given the different interpretations, I think that is time to revisit the section 4.1.5, and fix the ambiguity. Even though the intent may have been to have that section apply to the non technical documents like the social contract, I don't think we properly appreciated the importance of the social contract and the DFSG even a few years ago. The social contract is the soul of the project, the one common cause that we all rally around, and have agreed to. Also, in a sense, large segments of the free software community have defined free software around the DFSG (and its derivative, the open source definition). While clarifying the language in the constitution about _changing_ nontechnical documents I like us to also address special case core documents of the project, and require that a near consensus be achieved before these documents are changed. I think that the social contract and the DFSG are no less important than the constitution to the well being of the project, and they deserve at least equal protection from being changed unless we all (well, more or less) agree to such change. The social contract, defining as it does what Debian is, is important to the people who have committed to Debian, and converted their companies to use Debian servers, against using the common distributions. I think the social contract, seeing that it is with the fee software community, should indeed involve people from our user community when we are trying to change it. One of the fears voiced the last time around was that the constitution was impossibly hard to change, given the super majority requirements. I would like to offer the voting method GR as an example demonstrating that that fear is groundless. It was not as if the voting methods GR was unopposed, certain luminaries in the project voiced opposition, on the grounds that the GR was not explained well enough, and there was an attempt to amend the proposal radically. And yet the constitution was amended in a 9:1 landslide; obviously, it is possible to amend the constitution if one manages to convince the rank and file that the amendment is a good one. In my opinion it would be a good idea to require that changes to the documents that form the core of the project, and one which we signed on to uphold, be vetted by most of the membership (as opposed to 50% + 1). I would like to re-propose what I had proposed on -project more than three years ago: == 4. The Developers by way of General Resolution or election 4.1. Powers Together, the Developers may: 1. Appoint or recall the Project Leader. 2. Amend this constitution, provided they agree with a 3:1 majority. 3. Override any decision by the Project Leader or a Delegate. 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority. -5. Issue nontechnical policy documents and statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. +5. Issue, modify and withdraw nontechnical policy documents and statements. + These include documents describing the goals of the project, its + relationship with other free software entities, and nontechnical + policies such as the free software licence terms that Debian + software must meet. + They may also include position statements about issues of the day. + 5.1 A special clause applies to the documents labelled as + Foundation Documents. These documents are those + that are deemed to be critical to the core of the project, + they tend to define what the project is, and lay the + foundations of its structure. The developers may + modify a foundation document provided they agree with a 3:1 + majority. + 5.2 Initially, the list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers provided they agree with a 3:1 majority. 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See s.9.1.)
Re: stack protection
On Thu, 21 Aug 2003 22:38, rintek wrote: As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. Please have a look at your email Yes, I lived in the Netherlands for 2 years of the time I spent working on SE Linux and Debian. During that time I also did some preliminary work on RSBAC support for Debian (which I dropped because it seemed that no-one was interested). Now finally they get in contact to me after I've moved back to Australia (it seems that most Adamantix work is based around the Netherlands). PS Someone please tell rintek that their MUA is broken. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Binaryless uploads
On Thu, Aug 21, 2003 at 11:39:52PM -0400, Jaldhar H. Vyas wrote: Well for now I'm going to solve the immediate policy violation by reducing webmin.orig.tar.gz. I'll implement your scheme when the new release comes GREAT! out in the next couple of weeks. (Perhps you'd like to file a wishlist bug so I don't forget?) Ok, I have done so. Thanks for your work (past present future) in maintaining this package. -- Brian May [EMAIL PROTECTED]
Re: Returned Mail
On Fri, Aug 22, 2003 at 02:24:04PM +1000, Russell Coker wrote: For the auto-responders you can write to them directly and ask them to make their machines stop sending email to you. This won't work if the auto-response is a bounce message, eg. user doesn't exist... -- Brian May [EMAIL PROTECTED]
Re: Reply from Linux usage counter
Linux Counter wrote: The subject line of your message was Re: Wicked screensaver. the linux counter got spammed! now, that's just f..kin' rude. ben
Re: GR: Disambiguation of Section 4.1.5 of the constitution
On Thu, Aug 21, 2003 at 11:24:11PM -0500, Manoj Srivastava wrote: [snip] == 4. The Developers by way of General Resolution or election 4.1. Powers Together, the Developers may: 1. Appoint or recall the Project Leader. 2. Amend this constitution, provided they agree with a 3:1 majority. 3. Override any decision by the Project Leader or a Delegate. 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority. -5. Issue nontechnical policy documents and statements. - These include documents describing the goals of the project, its - relationship with other free software entities, and nontechnical - policies such as the free software licence terms that Debian - software must meet. - They may also include position statements about issues of the day. +5. Issue, modify and withdraw nontechnical policy documents and statements. + These include documents describing the goals of the project, its + relationship with other free software entities, and nontechnical + policies such as the free software licence terms that Debian + software must meet. + They may also include position statements about issues of the day. + 5.1 A special clause applies to the documents labelled as + Foundation Documents. These documents are those + that are deemed to be critical to the core of the project, + they tend to define what the project is, and lay the + foundations of its structure. The developers may + modify a foundation document provided they agree with a 3:1 + majority. + 5.2 Initially, the list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers provided they agree with a 3:1 majority. 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See s.9.1.) == Rationale: The clause being modified has been seen to be quite ambiguous. Since the original wording appeared to be amenable to two wildly different interpretations, this change adds clarifying the language in the constitution about _changing_ non technical documents. Additionally, this also provides for the core documents of the project the same protection against hasty changes that the constitution itself enjoys. == [snip] I am now formally looking for seconds for this proposal. Seconded. Simon pgpe1pAJgq2oA.pgp Description: PGP signature
Re: Returned Mail
On Fri, 22 Aug 2003 14:51, Brian May wrote: On Fri, Aug 22, 2003 at 02:24:04PM +1000, Russell Coker wrote: For the auto-responders you can write to them directly and ask them to make their machines stop sending email to you. This won't work if the auto-response is a bounce message, eg. user doesn't exist... It does if you set the From: field to be the same as the address that you send the message to... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bits from the RM
* Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Patents, gimp-nonfree and LAME
Josip Rodin wrote: BTW gimp(1.2)-nonfree was recently obsoleted. Because it is making way for 1.3 presumably?
Re: FTBFS: architecture all packages
* Goswin von Brederlow | The bandwith for buildds is a fixed price and already paid/sponsored. | Whats variable is the traffic. How can you say that? It might be on an ADSL line or something. | What I ment was its muchs faster to upload way less data. I doubt the buildds have a much faster connection to the internet than my box, for instance. It has a Gbit link, so it's limited by the puny 100Mbit card I have in the box and scp not being able to saturate that link. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: No, it is based on the assumption that a buildd will only install things listed in the Build-Depends, which means it will catch stuff that only builds on the maintainers workstation because they aren't building inside a chroot and are being sloppy - one of the main things they catch for binary-arch targets, today. This is (or was) not the case, buildds often have other things installed on them other than build-essential. I have been bitten by this in the past. Also, I have a build failure from the arm buildd on Aug 21 (kdebase) that smells like it, it couldn't install libcupsys2-dev which I bet is caused by gnome related packages being installed on the buildd (#203059). Also, I have been told before buildds in general have various other packages installed to save on install time, however I don't know if this is actually true. Chris Cheney pgp5prSRABZOD.pgp Description: PGP signature
Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Quoting Stephen Frost ([EMAIL PROTECTED]): Eh. Personally I tend to doubt it's lack of trust that's causing translations to rot in the BTS. As far as I know this is more maintainer laziness, for sure.. :-) I guess that in the future many translation will stop to rot in the BTS.. :-) We'll start with french translations. Not a lot of them are sleeping, because we already pissed off some maintainers, or even did some NMU's (yes, for wishlist bugs...). But some are getting quite old. Expect some NMU activity in the next weeks We will respect packages where this is obvious that new, complicated, releases are on their way, which are complicated (sympa, tetex-bin, ifhp...) but many other simple packages do not deserve this bad excuse A *lot* of brazilian portuguese, spanish, russian, german translations are sleeping in the BTS. Probably because these translation teams lack some manpower for doing both translations are *following* what happens to them. When asking for po-debconf switch, I personnally try to grab all old translation-related bugs in a single patch...but that complicates the work and days still have 24 hours.. :-) Of course, all this would be more easy if a translation tags exist in the BTS (see JFS proposals at Debconf3) PLEASE, maintainers, use translations we send to you. This is by far the easiest patches to use... :-)
Fw: Debian-devel! EX0TlC Iatina girIs in C!R/\-Z-Y ACTl0N! 0 j GxOK Xzo
Hey dTJITdGYHjD Debian-devel zteTc 8305 076
Re: What doing with an uncooperative maintainer ?
On 22 Aug 2003 03:58:03 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Marcelo E. Magallon [EMAIL PROTECTED] writes: On Thu, Aug 21, 2003 at 03:05:00PM +0200, Thomas Hood wrote: But sometimes there are fundamental disagreements about how something should be packaged and then it must be possible for two competing packages to exist in Debian Says who? Basically the social contract. The users are ill served by a haodge-podge of ill integrated software. We already have complaints of there being way too many packages, with confusing and hard-to-distinguish selection process. Added forked variants results in a _worse_ OS, not a better one. You may improve the situation for people who want fresh CVS commits, at the expense of the quality of the distribution. manoj -- You can't play your friends like marks, kid. Henry Gondorf, The Sting Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: GR: Disambiguation of Section 4.1.5 of the constitution
Hi, ooops. This should have gone to debian-vote. Could prospective seconds, and Simon, please send the email to debian-vote, rather than here? I apologize for the inconvenience. manoj -- He knew the tavernes well in every toun. Geoffrey Chaucer Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: non-DD contributors and the debian keyring
Martin Quinson wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. No. The contents Debian keyserver keyring.debian.org reflect the list of registered Debian developers who also have an account on about all Debian machines. It is also used to verify uploads against and ensure that only packages that are properly signed by a Debian developer are accepted into the archive. Adding non-developers to this keyring would weaken our security model. This would help people like translators which can hardly become DD (since they do not have the required packaging skills). One of the most fundamental point is that currently, DD is very very strict about who can upload to the source and the packages, but when I submit a translation to someone who do not speak french, he have to trust me. Adding a faulty or offending translation is much less harmful than uploading a malicious package. This trust relationship would be eased if I could sign my mails and contribution with an easily available key. I mean, I do have a key signed by some DD, but since my key is not easily available, that's not easy for the DD I collaborate with. As already mentioned there are public keyservers that should contain all keys from Debian developers anyway. Fetching keys from there should be as easy as from the Debian keyserver. The main issue is that I guess we would need a new keyring for that (along with the ones listed in /usr/share/doc/debian-keyring/README.gz). I guess it could be named contributor-keyring. If you really want to go that path, check the mentors.debian.net sub-project. I guess they have to maintain a second keyring anyway for the uploads. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book Please always Cc to me when replying to me on the lists.
Re: Transition: new PAM config file handling in unstable
Steve Langasek [EMAIL PROTECTED] writes: - Essential packages which currently pre-depend on libpam0g (read: login) will also need a versioned Pre-Depends on libpam-runtime before adopting this scheme, so that they are usable in an unconfigured state. Please consider this an introduction to the debian-devel discussion as mandated by Policy section 3.5. Sounds like a lovely idea. (How long do I have to wait before I decide that there's been a consensus before uploading a version of login that includes this? Is 24 hours little enough time? :-) kcr
Re: Debian Weekly News - August 19th, 2003
Quoting Scott James Remnant [EMAIL PROTECTED]: On Thu, 2003-08-21 at 11:18, Jérôme Marant wrote: No, no, no! You don't get it. There may be a majority among the debian-legal zealots, but we need a consensus among Debian as a whole (which means voting of course). mailto:[EMAIL PROTECTED] We musn't let the bigots decide for us! ;-) http://lists.debian.org/debian-newmaint-discuss/2000/debian-newmaint-discuss-29/msg00086.html Jerome demonstrated a clear understanding of the Social Contract and the Debian Free Software Guidelines. Perhaps you would care to re-read the Social Contract and DFSG? Your understanding seems to have wavered. Dear Scott, Thanks for feeding the troll ! I have a clear understanding of the DFSG but it hasn't been written anywere that documentation is software. Nobody managed to convince me after many discussions on debian-legal. I tend to agree with John Goerzen, see Inconsistencies in our approach thread. Branden's survey is misleading and assumes that documentation is software. It is unfair and doesn't count. -- Jérôme Marant
Re: Bits from the RM
On Wednesday 20 August 2003 09:49, Adrian von Bidder wrote: ... what KDE, gcc, X, gnome versions will be in sarge? And what about postfix? 2.0 is in unstable quite a while and works ok. I guess it will make it to sarge. cheers -- vbi -- Jack Nicklaus hit a golf shot that only gravity kept on this Earth. -- ESPN (the sports channel) pgpPETWcla0kK.pgp Description: signature
Re: Debian Weekly News - August 19th, 2003
Quoting Branden Robinson [EMAIL PROTECTED]: On Thu, Aug 21, 2003 at 12:18:10PM +0200, Jérôme Marant wrote: We musn't let the bigots decide for us! ;-) Thanks for excusing yourself from the discussion thus. Where has you sense of humour gone? More seriously, I do not consider that documentation is software and this is the reason why I don't know how to reply to you survey: is this another way to exclude people from discussions? I cannot imagine it wasn't deliberate. -- Jérôme Marant
Re: Debian Weekly News - August 19th, 2003
Quoting Andreas Metzler [EMAIL PROTECTED]: ROTFL. Am I the only one who interpreted this as a joke? Humpf, as even Branden sent a sincere follow-up I think I am missing something important. Perhaps the word cabal was missing? Throwing in some darn might have helped, too. Jérôme, please use darn cabal of debian-legal zealots next time. cu and- triple reading the original mail, stil smiling -reas Ah! There is at least someone in this project with some sense of humour. -- Jérôme Marant
Re: GR: Disambiguation of Section 4.1.5 of the constitution
I would suggest a small modification: * Manoj Srivastava ([EMAIL PROTECTED]) [030822 07:05]: + 5.2 Initially, the list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers provided they agree with a 3:1 majority. + 5.2 The list of foundation Documents consists + of this document, The Debian Constitution, as well as the + documents known as the Debian Social Contract and the + Debian Free Software Guidelines. The list of the documents + that are deemed to be Foundation Documents may be changed + by the developers only by changing this clause, which needs + according to 5.1 a 3:1 majority. Advantage: This makes the list in 5.2 the authoritative list, which makes it easier later to see which documents are in fact foundation Documents. (Or to speak in computer slang: normalization of data.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: stack protection
Russell Coker [EMAIL PROTECTED] writes:
On Fri, 22 Aug 2003 11:35, Goswin von Brederlow wrote:
A paper on udev was presented at OLS this year, at the URL below
you can find a copy in PDF format. Basically it is a way of
providing some of the features of devfs but based around using
hotplug to create device nodes using mknod under a regular
directory. So there is no mountable /dev.
Which means you need certain userspace tools for it to work at all
and if they fail you are screwed. Also how do you boot without a
/dev? You need a dummy dev containing any possible root device.
Now that you mention the mounting /dev going away this realy
sucks.
MOUNTING /dev is going away. So you will have /dev be a regular
directory on a regular file system with device nodes in it. For
booting things will work the same way that they worked when Linux
was first released.
Which means you need about 100 device nodes so you can boot of any
of the 65536 disks you could have connected?
Or can you get around till udev starts with a very few nodes with
fixed major/minor?
Doesn't sysfs basically do most of what devfs. Doesn't it know about
all devices?
I believe that udev uses sysfs among other things.
I just ment that instead of devfs knowing about all devices now sysfs
knows about all devices. So theoretically nothing is gained.
Practically sysfs might be better implemented.
Also could sysfs be made to provide a minimal /dev with at least nodes
for the root device and consoles?
On Fri, 22 Aug 2003 11:48, Brian May wrote:
One of the concepts behind devfs is that we could move away from
the current mapping of /dev/device -- {major,minor} -- kernel
driver system, and instead have the /dev/device map straight to
the driver (or something like that, I am just reciting this from
memory).
Yes, that would have been the eventual aim. devfs=only was a step
in that direction.
Have they abandoned this approach?
It seems so.
http://archive.linuxsymposium.org/ols2003/Proceedings/
As for why it's better than udev. There have been bugs in
devfs in the past related to race conditions. Also devfs
requires that the kernel knows about all the device nodes,
whether this is a bug or an excellent feature is a matter of
opinion.
Instead of the kernel knowing about device nodes, it needs to know
about the {major,minor} mappings.
Correct. Therefore we need 32bit device numbers instead.
I wonder if it wouldn't be possible to have the devfs
register/unregister calls for device nodes happen in the parts f the
kernel handling major/minor registration instead of in each individual
driver. How do major/minor pairs get registered with sysfs?
MfG
Goswin
Re: FTBFS: architecture all packages
Tollef Fog Heen [EMAIL PROTECTED] writes: * Goswin von Brederlow | The bandwith for buildds is a fixed price and already paid/sponsored. | Whats variable is the traffic. How can you say that? It might be on an ADSL line or something. Have fun building kde i18n. Its 200MB sources alone plus probably the same for the debs. The buildd would probably spend more time up/downloading than building. I hope no arch has just one buildd on adsl. | What I ment was its muchs faster to upload way less data. I doubt the buildds have a much faster connection to the internet than my box, for instance. It has a Gbit link, so it's limited by the puny 100Mbit card I have in the box and scp not being able to saturate that link. I wish I had that at home. MfG Goswin
Re: Returned Mail
Brian May [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 02:24:04PM +1000, Russell Coker wrote: For the auto-responders you can write to them directly and ask them to make their machines stop sending email to you. This won't work if the auto-response is a bounce message, eg. user doesn't exist... That usually contains the original message as attachment so your virus filter should catch and destroy those. :) MfG Goswin
Re: Binaryless uploads
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Fri, 22 Aug 2003, Brian May wrote: You obviously did not understand my scheme then. webmin-postfix and webmin-sendmail would still get built as seperate *.deb packages. They just share the one source package. Oh yeah alright. Now I get it. A user who installs webmin-postfix.deb will not get webmin-sendmail.deb, unless they deliberately install that too (don't ask me why...) Perhaps building both in the one source with the same build depends might be a problem, but you said build depends wasn't a problem. No they shouldn't be too much of a problem. Well for now I'm going to solve the immediate policy violation by reducing webmin.orig.tar.gz. I'll implement your scheme when the new release comes out in the next couple of weeks. (Perhps you'd like to file a wishlist bug so I don't forget?) But then again a bug in webim-sendmail would keep webmin-postfix out of testing. But that shouldn't be a problem if you fix RC bugs quickly. MfG Goswin
Re: ITP: ncurses-ruby - ruby extension for the ncurses C library
On Thu, Aug 21, 2003 at 01:44:02PM -0400, Brian Almeida wrote: BA I intend to package ncurses-ruby, which is a ruby extension for the BA ncurses C library. It is placed under the LGPL 2.1. It's required BA by raggle. BA BA http://ncurses-ruby.berlios.de Isn't libcurses-ruby what you are looking for? Did you try apt-search? -- Dmitry Borodaenko
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 09:58:30AM +0200, J?r?me Marant wrote: JrmM Branden's survey is misleading and assumes that documentation is JrmM software. It is unfair and doesn't count. Hey, Branden, how about another survey, about whether documentation is software or not, and whether documentation is subject to DFSG, or not? Just to kill all those darn trolls once and for all? ;-) For me, this was clear even before Bruce Perens replied to debian-legal about his understanding of this matter. -- Dmitry Borodaenko
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Chris Cheney [EMAIL PROTECTED] writes: On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: No, it is based on the assumption that a buildd will only install things listed in the Build-Depends, which means it will catch stuff that only builds on the maintainers workstation because they aren't building inside a chroot and are being sloppy - one of the main things they catch for binary-arch targets, today. This is (or was) not the case, buildds often have other things installed on them other than build-essential. I have been bitten by this in the past. Also, I have a build failure from the arm buildd on Aug 21 (kdebase) that smells like it, it couldn't install libcupsys2-dev which I bet is caused by gnome related packages being Then the -dev has to conflict with those. It also might be just a timeing poblem resulting in a momentary uninstability or just plain old apts stupidity not having a smart problem resolver. installed on the buildd (#203059). Also, I have been told before buildds in general have various other packages installed to save on install time, however I don't know if this is actually true. From my experience the buildd will start with a clean chroot and compile a bunch of packages in there. For each it adds the Build-depends before building and removes them after building (mostly?). After a certain number of runs the chroot is killed and setup again to prevent dirt from collecting. Mfg Goswin
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Christian Perrier [EMAIL PROTECTED] writes: Quoting Stephen Frost ([EMAIL PROTECTED]): Eh. Personally I tend to doubt it's lack of trust that's causing translations to rot in the BTS. As far as I know this is more maintainer laziness, for sure.. :-) I guess that in the future many translation will stop to rot in the BTS.. :-) We'll start with french translations. Not a lot of them are sleeping, because we already pissed off some maintainers, or even did some NMU's (yes, for wishlist bugs...). My _personal_ (which doesn't mean I will ignore policy and common curtesy once I become DD) optionon about this is that NMU should be done by comparing severity against the changes. Adding a translation or fixing a typo certainly is simple enough and not realy rejectable by the maintainer so even a severity whishlist should stop the NMU. Also with translations the maintainer might have no clue about the quality of the translation anyway, better letsomeone understanding the language decide. But some are getting quite old. Expect some NMU activity in the next weeks We will respect packages where this is obvious that new, complicated, releases are on their way, which are complicated (sympa, tetex-bin, ifhp...) but many other simple packages do not deserve this bad excuse A *lot* of brazilian portuguese, spanish, russian, german translations are sleeping in the BTS. Probably because these translation teams lack some manpower for doing both translations are *following* what happens to them. When asking for po-debconf switch, I personnally try to grab all old translation-related bugs in a single patch...but that complicates the work and days still have 24 hours.. :-) Then stay up late and also use the night :-) Of course, all this would be more easy if a translation tags exist in the BTS (see JFS proposals at Debconf3) PLEASE, maintainers, use translations we send to you. This is by far the easiest patches to use... :-) Hear hear. MfG Goswin
Re: FTBFS: architecture all packages
On Fri, Aug 22, 2003 at 11:46:42AM +0200, Goswin von Brederlow wrote: Tollef Fog Heen [EMAIL PROTECTED] writes: * Goswin von Brederlow | The bandwith for buildds is a fixed price and already paid/sponsored. | Whats variable is the traffic. How can you say that? It might be on an ADSL line or something. Have fun building kde i18n. Its 200MB sources alone plus probably the same for the debs. The buildd would probably spend more time up/downloading than building. Have you ever built kde-i18n? When I last NMUed it it took something like nine hours for my laptop to build it, and my laptop isn't all *that* wimpy. -- Colin Watson [EMAIL PROTECTED]
Re: udev [Was: Re: stack protection]
On Aug 22, Goswin von Brederlow [EMAIL PROTECTED] wrote: I'm basically just intrested in whats needed in /dev/ to get udev started and what userspace tools udev needs on a initrd. Whatever is already needed to make your system boot. So far udev will only create nodes for plug and play devices. For automatic discovery d-i will have to use sysfs, I also ITP'ed the library needed to access it. -- ciao, | Marco | [1403 maRDRgM9usPiQ]
Re: ITP: ncurses-ruby - ruby extension for the ncurses C library
On Fri, Aug 22, 2003 at 12:58:25PM +0300, Dmitry Borodaenko wrote: On Thu, Aug 21, 2003 at 01:44:02PM -0400, Brian Almeida wrote: BA I intend to package ncurses-ruby, which is a ruby extension for the BA ncurses C library. It is placed under the LGPL 2.1. It's required BA by raggle. BA BA http://ncurses-ruby.berlios.de Isn't libcurses-ruby what you are looking for? Did you try apt-search? No, they are completely different. Raggle requires ncurses-ruby, and won't work with curses-ruby. From http://www.rubygarden.org/ruby?TextMode standard curses Ruby has a curses library interface too (distributed with ruby). It lacks color support, however. ncurses-ruby This is a ruby module that wraps almost everything present in the ncurses library, including color support. Brian
ITH: icu
Hi, We (Daniel Glassey and Ivo Timmermans) are going to take over the package icu from Yves Arrouye [EMAIL PROTECTED]. Yves has failed to respond (his hotmail address, that he last used in communication, is over quotum, and other email went unanswered) to bugs and other email. We will upload a new upstream version (2.6) to experimental soon. Daniel Ivo -- Kurz bevor das Space-Shuttle in die Erdumlaufbahn eintritt, wird es von einer Horde Grizzlybren angegriffen. - Nichtlustig
Re: stack protection
On Fri, Aug 22, 2003 at 11:39:21AM +0200, Goswin von Brederlow wrote: Which means you need about 100 device nodes so you can boot of any of the 65536 disks you could have connected? Why? The kernel currently has hardcoded logic to convert the root=... string into a major,minor number, it doesn't use /dev for this. Once user space has started, it can populate /dev as required. Or did I miss something here? -- Brian May [EMAIL PROTECTED]
Re: Binaryless uploads
On Fri, Aug 22, 2003 at 11:54:52AM +0200, Goswin von Brederlow wrote: But then again a bug in webim-sendmail would keep webmin-postfix out of testing. But that shouldn't be a problem if you fix RC bugs quickly. True. Especially since sendmail has a history of security problems... The exact way the source packages are split isn't set in concrete (especially for webmin-optional and webmin-extra), feel free to add to bug #206682 if you can think of a better system. -- Brian May [EMAIL PROTECTED]
exec-shield (Was: stack protection)
What about exec-shield by Ingo Molnar? http://people.redhat.com/mingo/exec-shield/ it seems it is less intrusive then other kernel patches and can be enabled/disabled at run-time Stripped from annoucement: The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary. [...] There is a new boot-time kernel command line option called exec-shield=, which has 4 values. Each value represents a different level of security: exec-shield=0- always-disabled exec-shield=1- default disabled, except binaries that enable it exec-shield=2- default enabled, except binaries that disable it exec-shield=3- always-enabled the current patch defaults to 'exec-shield=2'. The security level can also be changed runtime, by writing the level into /proc: echo 0 /proc/sys/kernel/exec-shield end; Maybe Debian could default to exec-shield=1 ? O. On Thu, 2003-08-21 at 04:57, Russell Coker wrote: Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. Also is there any interest in uploading a kernel-image package with the grsec PaX support built in? -- Ondej Sur [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Returned Mail
On Fri, Aug 22, 2003 at 11:51:29AM +0200, Goswin von Brederlow wrote: That usually contains the original message as attachment so your virus filter should catch and destroy those. :) Actually I got one such message where amavisd-new/clamav didn't detect anything wrong. LATER: I see why, the MTA doing the bounce quoted the entire message as ASCII text, so amavisd didn't realize that it contained a encoded binary attachment. Oh well, I guess the virus wouldn't exactly be able to do much damage in this form anyway (even if I did use Outlook)... Let me see what MTA doesn't support bouncing MIME attachments properly... Should have guessed: qmail. -- Brian May [EMAIL PROTECTED]
Re: Returned Mail
Hi, On Fri, Aug 22, 2003 at 09:33:37PM +1000, Brian May wrote: On Fri, Aug 22, 2003 at 11:51:29AM +0200, Goswin von Brederlow wrote: That usually contains the original message as attachment so your virus filter should catch and destroy those. :) Actually I got one such message where amavisd-new/clamav didn't detect anything wrong. LATER: I see why, the MTA doing the bounce quoted the entire message as ASCII text, so amavisd didn't realize that it contained a encoded binary attachment. Oh well, I guess the virus wouldn't exactly be able to do much damage in this form anyway (even if I did use Outlook)... Let me see what MTA doesn't support bouncing MIME attachments properly... Should have guessed: qmail. That's not a bug, that's a feature! I think it's excellent that these bounces don't have the full message, but show only the first few kB, in a way that breaks the message's MIME structure well and thoroughly. After bouncing, at least a virus can't take advantage of the abysmal Outlook (Express) HTML and MIME handling anymore -- the source of at least 95% of the world's virus problems. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Please help spreading the online protest against SWPats
Dear Debian Developers, as some of you might have read on DWN the FFII is organizing some last minute protest against Software Patent legalization in the EU (the European Parliament plans to vote on this topic in the week beginning with September 1st). To find more information about the protest read the press release on http://swpat.ffii.org/news/03/demo0819. In addition to the demonstration and conference in Brussels the FFII is encouraging free software projects and others to participate in an online demonstration (http://swpat.ffii.org/group/demo). As a member of the FFII I'm trying to spread the news about this online demonstration and try to motivate free software projects to participate in it. However, contacting all possible candidates individually is a tedious task. Therefore, a fellow FFII member recently had the idea to ask maintainers of Debian packages to help us out: A systematic way to do it might be sending a mail to debian-devel (I guess that's the list) and ask each debian developer to please send a message to upstream maintainers or file a bug (a political system bug which can kill the project) against the project they maintain to ask them to join the online demo. So that's what I'm doing: Could some of you please help us? I appended a sample text below that maintainers/developers can use when contacting the projects that they are affiliated with. To make a message more convincing it might be a good idea to find a patent a project is infringing upon. Just take a look at the software patent horror gallery (http://swpat.ffii.org/patents), the patent database of the European Patent Office at http://ep.espacenet.com (includes US and other patents), or, if you understand german, http://patinfo.ffii.org/patente.html. Another question: Could we get this call for help (or a similar version) into the debian-devel-announce mailing list? Felix Sample message: Subject: Could ... help protest against SWPats? Hi, as you might have heard the FFII (http://www.ffii.org) is organizing a demonstration and conference on August 27th (see the latest press release at http://swpat.ffii.org/neues/03/demo0819/index.en.html). The goal is to make people and MEPs (members of the European parliament) aware of the dangers surrounding the legalization of software patents that may be up for vote in the European Parliament as early as September 1st. The main part of the event will take place in Brussels. In addition there will be an online demonstration whose idea is to simulate the effects of Software Patents by shutting down web sites on August 27th (http://swpat.ffii.org/gruppe/demo/index.de.html). Is there any chance that the .. project participates in this event? Note that the ... web site doesn't need to be closed down completely. On http://swpat.ffii.org/gruppe/demo/index.de.html there are several examples on how it's possible to show ones concerns without taking such drastic measures, but there's no need to stick to the examples. Just as a quick reminder: Many trivial patents (http://swpat.ffii.org/patente) are already granted in the US and, in spite of the current legislation, in the EU (see Art. 52 of the European Patent Convention). I for one don't want to have software (and consequently algorithms) to be legally patentable in Europe and fear that it will ultimately kill the competitiveness of Free Software. Regards, .. -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de
Re: Bug#206576: ITP: livejournal -- The code that runs livejournal
Il gio, 2003-08-21 alle 17:35, Jay Bonci ha scritto: * Package name: livejournal Version : 2003042200 Upstream Author : Brad Fitzpatrick [EMAIL PROTECTED] * URL : http://www.livejournal.com/code * License : LGPL (possibly others, clarifying) Description : The code that runs livejournal Livejournal is the collection of scripts and templating technologies used to set up your own livejournal-like site. Note: The license isn't exactly specified everywhere, and I'm getting confirmation from brad on the rest of the individual items Wow, anyway a very good news! :)
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
* Christian Perrier ([EMAIL PROTECTED]) wrote: We'll start with french translations. Not a lot of them are sleeping, because we already pissed off some maintainers, or even did some NMU's (yes, for wishlist bugs...). I feel this is utter bullshit, personally. One shouldn't be NMU'ing for wishlist bugs. If the package isn't maintained then hijack it instead. If you don't have time to do that then there's no way in hell you should be NMU'ing it anyway. If no one is willing to maintain it then it should be removed, or maybe changed to be maintained by the QA team. Stephen pgpCnpjRHre5w.pgp Description: PGP signature
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Quoting Stephen Frost ([EMAIL PROTECTED]): I feel this is utter bullshit, personally. One shouldn't be NMU'ing for wishlist bugs. If the package isn't maintained then hijack it instead. If you don't have time to do that then there's no way in hell you should be NMU'ing it anyway. If no one is willing to maintain it then it I don't understand why the alternative should be hijack or leave. I, for sure, cannot hijack any package for which nothing has been done for translation related bugs. I would quickly end up with dozens of packages I'm responsible for, the majority of which I'm perfectly unable to maintain. But I cannot leave also. Nothing in these packages tells me that they are unused, or useless or whatever. As they're kept in the archive, I suppose they are either used, or to be used, by someone. This may of course be wrong for some of them, but I'm perfectly unable to determine this. I also hate to see valuable work such as the one made by translation teams (or some motivated individuals) dying slowly in the BTS like some russian translations I find regularly, which are so old that they're most often outdatedjust because the damn maintainer was too lazy to try to figure out how to use them The key point, as usual, is the wishlist status of translation bug reports. I, as a non native english speaker, do not consider translation to be only a wish, but a requirement. I respect the usage in Debian and file my translation-related bugs as wishlistbut am not really satisfied with this. As Javier pointed at Debconf, it's maybe time for a i18n tag in the BTS.. :-)
Re: Does anyone use barrendero, or know of an equivalent?
On Thu, Aug 21, 2003, Steve Langasek wrote: http://zoy.org/~sam/debian/barrendero_1.0-1.1.diff.gz I haven't contacted the maintainer yet because I was working on other bugs, but if he is MIA as you seem to be suggesting, I'll probably upload that NMU to DELAYED quite soon. Ok, thanks for the info. Can you estimate when you think you'll NMU? Given the package state (only one upload more than 3 years ago, trivial RC bugs, dormant upstream/maintainer) I think I'll NMU tonight (CEST) with a few additional fixes. If anyone objects, please speak up. Cheers, -- Sam.
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 02:28:52AM +0200, Andreas Metzler wrote: Jérôme, please use darn cabal of debian-legal zealots next time. cu and- triple reading the original mail, stil smiling -reas And don't forget to call them licensing geeks! Richard Braakman
Re: Debian Weekly News - August 19th, 2003
On Fri, 22 Aug 2003 10:17:04 +0200, Jérôme Marant [EMAIL PROTECTED] said: Quoting Branden Robinson [EMAIL PROTECTED]: On Thu, Aug 21, 2003 at 12:18:10PM +0200, Jérôme Marant wrote: We musn't let the bigots decide for us! ;-) Thanks for excusing yourself from the discussion thus. Where has you sense of humour gone? Since when has insulting tour opponent in debate and appending the insult with a smiley orjust kidding been a hallmark of humour, or even acceptable in civilized discourse? At the risk of invoking godwins law, if I accused you, surrounded by smilies, of being a member of a certain German political party from the early-to-mid part of the last century, or of being a pedophile, you'll be rolling in aisle with laughter? More seriously, I do not consider that documentation is software and this is the reason why I don't know how to reply to you survey: is this another way to exclude people from discussions? I cannot imagine it wasn't deliberate. So I take it you can't understand English? The 4 rth option (none of the statements above express what I think) somehow passed you by? And if you do not consider documentation to be distinct from software, you should be able to adress the issues I raised in http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00983.html and the other issue also: http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00452.html http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00767.html http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00850.html http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00983.html manoj -- Most non-Catholics know that the Catholic schools are rendering a greater service to our nation than the public schools in which subversive textbooks have been used, in which Communist-minded teachers have taught, and from whose classrooms Christ and even God Himself are barred. from Our Sunday Visitor, an American-Catholic newspaper, 1949 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: GR: Disambiguation of Section 4.1.5 of the constitution
* Andreas Barth ([EMAIL PROTECTED]) wrote: Advantage: This makes the list in 5.2 the authoritative list, which makes it easier later to see which documents are in fact foundation Documents. (Or to speak in computer slang: normalization of data.) I agree with this change, other comments? Stephen pgpR1CPKcnrQn.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
Quoting Richard Braakman [EMAIL PROTECTED]: On Fri, Aug 22, 2003 at 02:28:52AM +0200, Andreas Metzler wrote: Jérôme, please use darn cabal of debian-legal zealots next time. cu and- triple reading the original mail, stil smiling -reas And don't forget to call them licensing geeks! Do you think such an expression would provoke the same emotional response? ;-) -- Jérôme Marant
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
On Fri, Aug 22, 2003 at 09:55:51AM -0400, Stephen Frost wrote: * Christian Perrier ([EMAIL PROTECTED]) wrote: We'll start with french translations. Not a lot of them are sleeping, because we already pissed off some maintainers, or even did some NMU's (yes, for wishlist bugs...). I feel this is utter bullshit, personally. One shouldn't be NMU'ing for wishlist bugs. If the package isn't maintained then hijack it instead. If you don't have time to do that then there's no way in hell you should be NMU'ing it anyway. If no one is willing to maintain it then it should be removed, or maybe changed to be maintained by the QA team. The decision to NMU should be based on a combination of the severity and age of the bug and the *non-intrusiveness* of the fix, not just on the first two factors. When you weigh the benefits of translation NMUs against the risks, it's clear that such NMUs are a safer bet than many NMUs for severity: important bugs that require code changes. -- Steve Langasek postmodern programmer pgpaehTTZ2i9g.pgp Description: PGP signature
AntiVirus scan results
--- This e-mail is generated by the WEBMAILLOGIN.COM mail server to warn you that the e-mail sent by debian-devel@lists.debian.org to [EMAIL PROTECTED] is infected with virus: Win32/[EMAIL PROTECTED] Please contact your system administrator for further information. If you are the sender: --- The scanned e-mail has your address in the From header field. Either your computer is infected or someone's computer having your e-mail address in the address book has been infected. (Please note that some viruses are sending e-mails directly from your computer. Our advise is to check your computer using an up-to-date antivirus product). If you are the receiver: - Please contact the sender: very probably he/she doesn't know he/she has a computer virus. Actions taken for the infected files: - The infected file was saved to quarantine with name: 1061564437-5169283.msg. The file (part0003:document_9446.pif) attached to mail (with subject:Re: Details) sent by debian-devel@lists.debian.org to [EMAIL PROTECTED] is infected with virus: Win32/[EMAIL PROTECTED] Cannot clean this file. The file was successfully deleted by AntiVirus. this is a copy of the e-mail header: Received: from [24.87.61.248] (HELO NEUTRABO-YFQTGZ) by fr1.webmaillogin.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 5169283 for [EMAIL PROTECTED]; Fri, 22 Aug 2003 11:00:34 -0400
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
* Christian Perrier ([EMAIL PROTECTED]) wrote: Quoting Stephen Frost ([EMAIL PROTECTED]): I feel this is utter bullshit, personally. One shouldn't be NMU'ing for wishlist bugs. If the package isn't maintained then hijack it instead. If you don't have time to do that then there's no way in hell you should be NMU'ing it anyway. If no one is willing to maintain it then it I don't understand why the alternative should be hijack or leave. It's not hijack or leave. It's hijack or actually try to work with the maintainer. An NMU probably wouldn't help the situation unless you have some reason to believe the maintainer would incorporate the changes in the NMU as opposted to just ignoring them on his/her next upload. Obviously continually doing NMU's isn't exactly useful either. I, for sure, cannot hijack any package for which nothing has been done for translation related bugs. I would quickly end up with dozens of packages I'm responsible for, the majority of which I'm perfectly unable to maintain. If you can't maintain the package then you shouldn't be NMU'ing it. It's real simple, learn that. But I cannot leave also. Nothing in these packages tells me that they are unused, or useless or whatever. As they're kept in the archive, I suppose they are either used, or to be used, by someone. This may of course be wrong for some of them, but I'm perfectly unable to determine this. Don't leave it alone, bitch to the maintainer, bring it up on d-d, etc. I didn't say just leave it alone, I said don't NMU or hijack it unless you can actually maintain it. I also hate to see valuable work such as the one made by translation teams (or some motivated individuals) dying slowly in the BTS like some russian translations I find regularly, which are so old that they're most often outdatedjust because the damn maintainer was too lazy to try to figure out how to use them If they're more complex than a patch then obviously you could make it simpler/easier by making it into a patch. Every DD should know how to use a patch. The key point, as usual, is the wishlist status of translation bug reports. I, as a non native english speaker, do not consider translation to be only a wish, but a requirement. Sorry, but you're wrong. It sucks, I'm sure, but just because you feel differently doesn't change things. I respect the usage in Debian and file my translation-related bugs as wishlistbut am not really satisfied with this. So work to actually get it changed. As Javier pointed at Debconf, it's maybe time for a i18n tag in the BTS.. :-) That's not a bad idea. Stephen pgp4HVcEp2Q48.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 04:53:30PM +0200, J?r?me Marant wrote: Quoting Richard Braakman [EMAIL PROTECTED]: On Fri, Aug 22, 2003 at 02:28:52AM +0200, Andreas Metzler wrote: J?r?me, please use darn cabal of debian-legal zealots next time. cu and- triple reading the original mail, stil smiling -reas And don't forget to call them licensing geeks! Do you think such an expression would provoke the same emotional response? ;-) What is this lunatic blabbering about? ? Yes, I think it would. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpQzJ6u1Cq5r.pgp Description: PGP signature
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Quoting Stephen Frost ([EMAIL PROTECTED]): I, for sure, cannot hijack any package for which nothing has been done for translation related bugs. I would quickly end up with dozens of packages I'm responsible for, the majority of which I'm perfectly unable to maintain. If you can't maintain the package then you shouldn't be NMU'ing it. It's real simple, learn that. WowThere's a strong difference between maintaining a package, which means following it along its entire life and making one single fix for a very specific thing. I'm perfectly able to do the changes required by the NMU i send, mostly po-debconf switches or translation incormoration. But, if a bug related to something completely different in the package occurs, then I cannot fix it be cause I'm not invloved in the given software. For what I read, it is not required to be able to maintain everything for a given package for being able to NMU it. It is just required to be able to fix possible introduced bugs But I cannot leave also. Nothing in these packages tells me that they are unused, or useless or whatever. As they're kept in the archive, I suppose they are either used, or to be used, by someone. This may of course be wrong for some of them, but I'm perfectly unable to determine this. Don't leave it alone, bitch to the maintainer, bring it up on d-d, etc. I didn't say just leave it alone, I said don't NMU or hijack it unless you can actually maintain it. I *CAN* maintain.what I change. So my reading of our policy tells me that it's OK to NMU. I also hate to see valuable work such as the one made by translation teams (or some motivated individuals) dying slowly in the BTS like some russian translations I find regularly, which are so old that they're most often outdatedjust because the damn maintainer was too lazy to try to figure out how to use them If they're more complex than a patch then obviously you could make it simpler/easier by making it into a patch. Every DD should know how to use a patch. They're not complex at all. Most of the time (for russian translations), it is just required to know how to uudecode file and how should a debconf translation be named... :-) I respect the usage in Debian and file my translation-related bugs as wishlistbut am not really satisfied with this. So work to actually get it changed. This is precisely what's currently happening.. :-)
Automatic response to your mail
Thank you for your interest in our suite of GPS tracking products called Modus(TM). Catch4 Technologies, Inc. is a Colorado-based, privately owned company that develops and distributes technology products and services specifically for transportation and other fleet-based industries. We appreciate your inquiry and will follow-up with you within 24 hours to answer any questions you may have about using our products to help increase efficiencies in your company. At Catch4 Technologies, we are committed to providing the best quality products at affordable prices. Sincerely, Brian Tsuchiya Sales Catch4 Technologies, Inc. 303-940-2547
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
* Christian Perrier ([EMAIL PROTECTED]) wrote: Quoting Stephen Frost ([EMAIL PROTECTED]): I, for sure, cannot hijack any package for which nothing has been done for translation related bugs. I would quickly end up with dozens of packages I'm responsible for, the majority of which I'm perfectly unable to maintain. If you can't maintain the package then you shouldn't be NMU'ing it. It's real simple, learn that. WowThere's a strong difference between maintaining a package, which means following it along its entire life and making one single fix for a very specific thing. Except what you don't realize is that one should never, ever, ever just NMU and then forget about the package. If you do an NMU then you need to make sure it worked, follow the package and make sure there aren't problems with it and follow up with the maintainer on the bugs. I don't care what you change in the package, if you NMU then you need to do that at a *minimum*, just as if you were the maintainer. It's not until the official maintainer incorporates the NMU changes and closes the bugs that the NMU'er can forget about it. I'm perfectly able to do the changes required by the NMU i send, mostly po-debconf switches or translation incormoration. But, if a bug related to something completely different in the package occurs, then I cannot fix it be cause I'm not invloved in the given software. Then you shouldn't be doing an NMU on it. When you NMU something you take responsibility for it temporairly until the maintainer gets back. For what I read, it is not required to be able to maintain everything for a given package for being able to NMU it. It is just required to be able to fix possible introduced bugs Then what you read is wrong. I *CAN* maintain.what I change. So my reading of our policy tells me that it's OK to NMU. Then it's wrong or your interpretation is. You shouldn't be doing NMU's unless you can actually handle problems in the package. This would be one reason why you shouldn't be NMU'ing for wishlist bugs and instead should be NMU'ing for RC bugs. They're not complex at all. Most of the time (for russian translations), it is just required to know how to uudecode file and how should a debconf translation be named... :-) A patch would probably still be easier, but whatever. This is precisely what's currently happening.. :-) Glad to hear it, perhaps some day you will, though personally I hope to hell you never manage to get it considered an RC bug, and I'll work to make sure that doesn't happen. Stephen pgpqrkpuN5lwz.pgp Description: PGP signature
Re: Patents, gimp-nonfree and LAME
On Thu, Aug 21, 2003 at 10:50:54PM -0700, Paul C. Bryan wrote: BTW gimp(1.2)-nonfree was recently obsoleted. Because it is making way for 1.3 presumably? No, I believe it's gone because libtiff linkage has been declared non-free by mistake since libtiff was never made to include actual patented algorithms by default (I think I had filed a bug about that ages ago) and the libgif linkage was replaced with libungif, or the GIF patent expired, or something like that. -- 2. That which causes joy or happiness.
Re: Debian Weekly News - August 19th, 2003
[Followups set.] On Fri, Aug 22, 2003 at 09:58:30AM +0200, Jérôme Marant wrote: Branden's survey is misleading and assumes that documentation is software. It is unfair and doesn't count. No, my survey is narrowly scoped. It is not the job of the debian-legal mailing list, as I understand it, to distinguish between documentation and software for the rest of the Project, nor -- more to the point -- to manufacture and apply Debian Free Documentation Guidelines when none have been proposed or ratified by the Project. The role of the debian-legal mailing list is to formulate, as best it can, recommendations on the legal issues to the rest of the Project, and have discussions of legal issues relevant to Debian that are more germane on that list than any other. The Social Contract[1] says that Debian will remain 100% Free Software, and that the Debian Free Software Guidelines shall be a tool that we use to for determining whether something in the Debian distribution is Free Software or not. Debian Developers have pledged to act to uphold the Social Contract and DFSG. If you want to change them, you know the process. But do not attempt to subvert them by attempting to persuade people that clause 1 of the Social Contract says things it obviously does not. Whether documentation is software, whether we need fewer freedoms for documentation than we do for software, and whether and how we shall amend the Debian Social Contract are questions for debian-project or debian-vote, not debian-legal. [1] http://www.debian.org/social_contract -- G. Branden Robinson|It is the responsibility of Debian GNU/Linux |intellectuals to tell the truth and [EMAIL PROTECTED] |expose lies. http://people.debian.org/~branden/ |-- Noam Chomsky pgpHTNdfoMgKu.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 01:14:40PM +0300, Dmitry Borodaenko wrote: Hey, Branden, how about another survey, about whether documentation is software or not, I'm not interested in circulating such a survey. Someone else may wish to, but debian-legal is not an appropriate list for it -- I recommend debian-project instead. and whether documentation is subject to DFSG, or not? According to clause 1 of the Debian Social Contract[1], everything (100%) in the Debian GNU/Linux distribution is and must remain Free Software, and we are compelled to use the Debian Free Software Guidelines to evaluate whether the things in the Debian GNU/Linux distribution are Free Software or not. Just to kill all those darn trolls once and for all? ;-) That will never happen. There will always be people willing to compromise the freedoms of their fellow developers and our users so that they can enjoy having a particular set of bits in our distribution. [1] http://www.debian.org/social_contract -- G. Branden Robinson|Of two competing theories or Debian GNU/Linux |explanations, all other things [EMAIL PROTECTED] |being equal, the simpler one is to http://people.debian.org/~branden/ |be preferred. -- Occam's Razor pgpUc7E9T59BX.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 10:17:04AM +0200, Jérôme Marant wrote: Quoting Branden Robinson [EMAIL PROTECTED]: On Thu, Aug 21, 2003 at 12:18:10PM +0200, Jérôme Marant wrote: We musn't let the bigots decide for us! ;-) Thanks for excusing yourself from the discussion thus. Where has you sense of humour gone? Not to a land where accusations of bigotry are recognized as humor. More seriously, I do not consider that documentation is software and this is the reason why I don't know how to reply to you survey: I guess you can select the 4th option in Part 1. If none of the first 3 options reasonably approximate your opinion, then you should have no trouble marking option 4. is this another way to exclude people from discussions? No. It's a way to assess whether the silent majority arguments raised by a few loud people on debian-legal, claiming that most people don't really believe that the GNU FDL needs to satisfy the DFSG, are the real consensus view. Judging by the survey results so far, that claim would appear to be signfificantly mistaken. I cannot imagine it wasn't deliberate. The message was written and sent deliberately; I cannot help you with regard to what you're reading between the lines. -- G. Branden Robinson|I must confess to being surprised Debian GNU/Linux |by the magnitude of incompatibility [EMAIL PROTECTED] |with such a minor version bump. http://people.debian.org/~branden/ |-- Manoj Srivastava pgpzszHoKhQ7F.pgp Description: PGP signature
Re: GR: Disambiguation of Section 4.1.5 of the constitution
On Thu, Aug 21, 2003 at 11:24:11PM -0500, Manoj Srivastava wrote: I am now formally looking for seconds for this proposal. Seconded. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpSp5kuhETPm.pgp Description: PGP signature
Re: Bits from the RM
On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: * Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) What are the criteria for the apache package to become Apache 2?
Re: Re: Patents, gimp-nonfree and LAME
Josip Rodin dijo: On Thu, Aug 21, 2003 at 10:50:54PM -0700, Paul C. Bryan wrote: BTW gimp(1.2)-nonfree was recently obsoleted. Because it is making way for 1.3 presumably? No, I believe it's gone because libtiff linkage has been declared non-free by mistake since libtiff was never made to include actual patented algorithms by default (I think I had filed a bug about that ages ago) and the libgif linkage was replaced with libungif, or the GIF patent expired, or something like that. Patent on LZW algorithm expired so the support for GIF and TIFF images is now back in the main Gimp package. Greets -- Jose M. Fernández Navarro | Debian GNU/Linux User #197079 Benetússer - València, Spain | http://mural.uv.es/~joferna
Re: Bits from the RM
On Fri, Aug 22, 2003 at 02:41:40PM -0400, Joe Drew wrote: On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: * Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) What are the criteria for the apache package to become Apache 2? Having working ports of a reasonable number of the widely used Apache module packages might be a good start. (E.g., there are no packages today for php4 under Apache2, and if there were, much functionality would be missing due to thread-safe issues with php upstream.) -- Steve Langasek postmodern programmer pgpFJmPZUWmFI.pgp Description: PGP signature
ruby1.6 and ruby-defaults 1.6 is uploaded (Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby))
Hi, I uploaded ruby1.6 and ruby-defaults (1.6.8-6) now. Packages built from ruby1.6 source package is simply renamed from ruby 1.6.8-5. I plan ruby 1.8 transition: - Wait a while until ruby1.6 and ruby-defaults are installed, because these are NEW packages. - Keep ruby-defaults to 1.6 for about a week. In this period, ruby packages change to follow new debian ruby policy, renaming -ruby to -ruby1.6 or so. For important ruby module packages, that is, many packages depend on it, we'll NMU to rename -ruby to -ruby1.6 end of August(?) unless it is done by the maintainer. We already have ruby1.8 in unstable, you may build ruby packages named *-ruby1.8 for ruby1.8 now. - Change ruby-defaults from 1.6 to 1.8 Regards, Fumitoshi UKAI pgptL0diikTBd.pgp Description: PGP signature
Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)
At Wed, 20 Aug 2003 19:37:17 -0500, Joe Wreschnig wrote: On Wed, 2003-08-20 at 12:53, Fumitoshi UKAI wrote: Joe Wreschnig [EMAIL PROTECTED] libtest-unit-ruby1.8 (- libtest-unit-ruby) Actually, I now only maintain Test::Unit for Ruby 1.6. Since it became included with 1.8, akira yamada maintains that version, and when 1.8 was packaged I dropped support for 1.7 from my package. I'll rename the 1.6 package appropriately, though, but I'll wait until the Ruby/GTK packages are renamed (unless that's going to take a very long time?) Maybe, akira yamada will do it soon, or I'll NMU. Currently, ruby upstream doesn't support such version independent module path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later to support this? I think so, but I'm open to suggestions about it. It does IMO make packaging modules without C code much simpler. The downside is when a major incompatibility happens (i.e. code that works correctly on more than one version is impossible), but I believe this is a rare enough case to ignore (AFAIK it's never happened). Hmm, we'll reconsider this issues after transition to 1.8 almost is done, or after sarge is released if sarge release is on time. Regards, Fumitoshi UKAI pgpNUV1g52qHd.pgp Description: PGP signature
Re: Re: Patents, gimp-nonfree and LAME
Hi, Jose M. Fdez wrote: Patent on LZW algorithm expired so the support for GIF and TIFF images is now back in the main Gimp package. Only in the US... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgpJb2drKCO42.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
Manoj Srivastava [EMAIL PROTECTED] writes: More seriously, I do not consider that documentation is software and this is the reason why I don't know how to reply to you survey: is this another way to exclude people from discussions? I cannot imagine it wasn't deliberate. So I take it you can't understand English? The 4 rth option (none of the statements above express what I think) somehow passed you by? Additionally, whether the DFSG should apply to documentation in Debian is not relevant to the survey, which asks whether the GFDL complies with the DFSG: we can deal with the insanity of whether this software over here is or is not software later, but figuring out whether the GFDL is a DFSG-free licence for software is also important. That's what the survey's asking about. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)
At Thu, 21 Aug 2003 20:33:10 +0300, Dmitry Borodaenko wrote: On Thu, Aug 21, 2003 at 02:53:12AM +0900, Fumitoshi UKAI wrote: FU Dmitry Borodaenko [EMAIL PROTECTED] FU libyaml-ruby1.8 (- libyaml-ruby) I think that since whytheluckystiff is developing Syck/YAML right in the Ruby CVS, there is little chance for a separation of libyaml-ruby1.8 in the near future, and I'm quite happy with it being maintained by akira as part of ruby1.8. Ok, I see. I am inclined to keep libyaml-ruby1.6 (renamed from current libyaml-ruby as soon as ruby-defaults is out), and make a libyaml-ruby metapackage that depends on libyaml-ruby1.6 | libyaml-ruby1.8, so that a program that doesn't care about Ruby version would pull in either 1.6 or 1.8 version, depending on the version of Ruby installed. Yes, please keep libyaml-ruby1.6 while ruby1.6 around. Regarding libyaml-ruby, do you want to maintain it by yourself? Now, ruby-defaults packages contains all -ruby packages for -ruby1.6 packages that are built from ruby1.6. So, as the same rule, I suppose ruby-defaults provides all -ruby packages for -ruby1.8 in ruby1.8 source package, after ruby-defaults becomes ruby1.8. But I'm not sure which is the better way. Regards, Fumitoshi UKAI pgpa62qvr5umA.pgp Description: PGP signature
Messaging Mgmt System (MMS) notification
The Airborne Express mail system will not accept this attachment due to recent virus threats. CAUTION- Airborne Express has detected Computer Viruses in an email message you recently sent to this location. The infected message was blocked and will not be delivered to recipients at this organization. Please run your desktop Virus Manager program to ensure that your workstation is completely free from Viruses prior to resending this message or any future file attachments via email. If you require assistance, please contact your Network Help Desk. Virus information on this infected message follows: Virus Scanner found the W32/[EMAIL PROTECTED] virus in the attached file: details.pif ---BeginMessage--- ---End Message---
Re: Patents, gimp-nonfree and LAME
* Jose M. Fdez ([EMAIL PROTECTED]) [030822 21:05]: Patent on LZW algorithm expired so the support for GIF and TIFF images is now back in the main Gimp package. I hope this is not true, otherwise it would be a RC-bug. According to http://www.gnu.org/philosophy/gif.html the unisys patent | does not expire in most of Europe until 18 June 2004, in Japan until | 20 June 2004 and in Canada until 7 July 2004. (It is expired in the US.) (That is the cause why ppmtogif will stay in netpbm-nonfree until 7 July 2004, so it's not in netpbm-free at sarge release.) Cheers, Andi - netpbm maintainer - -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: stack protection
Brian May [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 11:39:21AM +0200, Goswin von Brederlow wrote: Which means you need about 100 device nodes so you can boot of any of the 65536 disks you could have connected? Why? The kernel currently has hardcoded logic to convert the root=... string into a major,minor number, it doesn't use /dev for this. Once user space has started, it can populate /dev as required. Or did I miss something here? Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. Might burden the installer. Mfg Goswin
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 12:06:39PM -0500, Branden Robinson wrote: On Fri, Aug 22, 2003 at 09:58:30AM +0200, Jérôme Marant wrote: Branden's survey is misleading and assumes that documentation is software. It is unfair and doesn't count. No, my survey is narrowly scoped. The Social Contract[1] says that Debian will remain 100% Free Software, and that the Debian Free Software Guidelines shall be a tool that we use to for determining whether something in the Debian distribution is Free Software or not. Debian Developers have pledged to The corrolary is that 0% of Debian is non-free software. Documentation is not software at all. The mere fact that the social contract says that 100% of Debian is Free Software does not magically make everything that is part of Debian software. Just saying something is so is begging the question, and I am getting tired of that game. act to uphold the Social Contract and DFSG. If you want to change them, you know the process. But do not attempt to subvert them by attempting to persuade people that clause 1 of the Social Contract says things it obviously does not. If you take Clause 1 of the Social Contract to literally mean that Debian contains nothing save software that is free, then that clause has never been true since it was introduced, since we have always contained many non-software items (documentation, bibles, Linux Gazette issues, RFCs, graphics, wallpapers, sounds, etc.) If you take Clause 1 of the Social Contract to mean that all software in Debian is free, it makes a lot of sense to me, and does not itself remove the moral requirement that documentation and other files are free as well. Not that I see that this whole discussion bears any relevance to the DFSG/GFDL discussion.
Re: stack protection
* Goswin von Brederlow ([EMAIL PROTECTED]) [030822 22:15]: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. According to http://www.kroah.com/linux/talks/ols_2003_udev_talk/ http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Kroah-Hartman-OLS2003.pdf this is very small. But - I'm not even near a kernel expert. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Quoting Stephen Frost ([EMAIL PROTECTED]): Except what you don't realize is that one should never, ever, ever just NMU and then forget about the package. If you do an NMU then you need to make sure it worked, follow the package and make sure there aren't problems with it and follow up with the maintainer on the bugs. I don't care what you change in the package, if you NMU then you need to do that at a *minimum*, just as if you were the maintainer. It's not until the official maintainer incorporates the NMU changes and closes the bugs that the NMU'er can forget about it. But *why the hell* do you assume I don't already do this for packages I NMU ? I'm really sorry, but it seems that you've decided in your mind that I do NMU without care. I'm really sorry to say that it's exactly the opposite. The only difference is that I follow the package the time necessary for being sure that I didn't break anything. I don't want to follow it indefinitely, that's all. And, as Steve pointed out, translation stuff is minimalistically invasive so this does not require an enormous amount of attention after the NMU. But, sorry, if a RC bug is raised which is obviously unrelated to the things I changed, why should I care for it more than the normal wayt (ie, if by chance I can deal with it...I *will* do just like I would with any RC bug I'm able to fixbut if I'm perfectly unable to fix it besides tagging the bug help, what should be done ?) Oh yes : I shouldn't have NMU'ed the package. I'd rather leave this pt_BR.po file sent by one of the most active brazilian contributors sleep in the BTS and slowly dying because noone cares about it. mostly po-debconf switches or translation incormoration. But, if a bug related to something completely different in the package occurs, then I cannot fix it be cause I'm not invloved in the given software. Then you shouldn't be doing an NMU on it. When you NMU something you take responsibility for it temporairly until the maintainer gets back. We seem to have different interpretation of the various documents which try to define common sense.. :-) For what I read, it is not required to be able to maintain everything for a given package for being able to NMU it. It is just required to be able to fix possible introduced bugs Then what you read is wrong. Nope. Your interpretation differs from mine.. :-) This is precisely what's currently happening.. :-) Glad to hear it, perhaps some day you will, though personally I hope to hell you never manage to get it considered an RC bug, and I'll work to make sure that doesn't happen. This does just mean you don't care a lot about translation and can live with an (sometimes bad) english-only distribution. I cannot and most people cannot too. This is why maybe some day using tools which help translation work may become mandatory (ie po-debconf instead of plain debconf templates, gettexted README.Debian files, translated man pages and so on...). Such tools make translation minimalistically invasive, thus allowing people with limited noble hacking knowledge to still make significant contributions to the whole stuff. I (and the whole l10-french team too), currently, have one goal : just have 100% prompting made in french in my favourite Linux distribution. The tools are there, the manpower is there and the motivation is there also ... :-). I'm nearly sure that all l10n teams have more or less secreteky the exact same goal (but as the french are arrogant people, we confess our goals.)
Re: FTBFS: architecture all packages
Colin Watson [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 11:46:42AM +0200, Goswin von Brederlow wrote: Tollef Fog Heen [EMAIL PROTECTED] writes: * Goswin von Brederlow | The bandwith for buildds is a fixed price and already paid/sponsored. | Whats variable is the traffic. How can you say that? It might be on an ADSL line or something. Have fun building kde i18n. Its 200MB sources alone plus probably the same for the debs. The buildd would probably spend more time up/downloading than building. Have you ever built kde-i18n? When I last NMUed it it took something like nine hours for my laptop to build it, and my laptop isn't all *that* wimpy. Not surprising given its a ~650 MB sources. Unpacking and packaing alone will take hours on m68k I guess. But an idle buildd is idel so no harm in him building it. On the other hand you downloading 200 MB and uploading 400 MB with a 38400 modem would realy hurt. Well not you but someone only having a 38400 connect. MfG Goswin
Out of Office AutoReply: {Virus?} Re: Your application
Sorry, I'm not in the office, now. I will be back at the 5th of September 2003 In case of emergency please contact [EMAIL PROTECTED] Uli Friedrich best regards Ulrich Friedrich
Re: GR: Disambiguation of Section 4.1.5 of the constitution
On Thu, Aug 21, 2003 at 11:24:11PM -0500, Manoj Srivastava wrote: Since I am no longer merely an interested observer in the GR process, this is going to be hard. [...] I would like to re-propose what I had proposed on -project more than three years ago: Well, it doesn't look like it turned out to be so hard after all. :) -- G. Branden Robinson| There is no gravity in space. Debian GNU/Linux | Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon? http://people.debian.org/~branden/ | Because they wore heavy boots. pgpvQRwpidFGN.pgp Description: PGP signature
Re: stack protection
On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
cat /dev/zero /dev/mem is a feature and not a bug, but today
more and more people disagree.
cite Doug Gwin
UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things.
/cite
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
* Christian Perrier ([EMAIL PROTECTED]) wrote: Quoting Stephen Frost ([EMAIL PROTECTED]): Except what you don't realize is that one should never, ever, ever just NMU and then forget about the package. If you do an NMU then you need to make sure it worked, follow the package and make sure there aren't problems with it and follow up with the maintainer on the bugs. I don't care what you change in the package, if you NMU then you need to do that at a *minimum*, just as if you were the maintainer. It's not until the official maintainer incorporates the NMU changes and closes the bugs that the NMU'er can forget about it. But *why the hell* do you assume I don't already do this for packages I NMU ? I'm really sorry, but it seems that you've decided in your mind that I do NMU without care. I'm really sorry to say that it's exactly the opposite. You just said that you weren't able to maintain the package. If you ever NMU a package without being able to maintain it yourself then you're NMU'ing without care. I don't see what's hard to understand about that. The only difference is that I follow the package the time necessary for being sure that I didn't break anything. I don't want to follow it indefinitely, that's all. You shouldn't have to if the maintainer is active and if he isn't then it should be orphaned to QA or removed. And, as Steve pointed out, translation stuff is minimalistically invasive so this does not require an enormous amount of attention after the NMU. When you do an NMU you're taking the responsibility to maintain the package until the maintainer is active on it. If you're not willing (or able) to handle the package just for a translation then you shouldn't be doing the NMU just for the translation. But, sorry, if a RC bug is raised which is obviously unrelated to the things I changed, why should I care for it more than the normal wayt (ie, if by chance I can deal with it...I *will* do just like I would with any RC bug I'm able to fixbut if I'm perfectly unable to fix it besides tagging the bug help, what should be done ?) Maintainers aren't always able to fix RC bugs themselves so you should do exactly what the maintainer would do in such a case since it's against your NMU, even if it's unrelated to the specific change in your NMU it's still your NMU so it's your responsibility. The maintainer would probably tag it with help and work with upstream to find a fix for it. Oh yes : I shouldn't have NMU'ed the package. I'd rather leave this pt_BR.po file sent by one of the most active brazilian contributors sleep in the BTS and slowly dying because noone cares about it. If you're not willing to be responsible for your NMU then you shouldn't do the NMU, that's correct. We seem to have different interpretation of the various documents which try to define common sense.. :-) Everyone has an opinion. Nope. Your interpretation differs from mine.. :-) You see, mine is actually right though. Glad to hear it, perhaps some day you will, though personally I hope to hell you never manage to get it considered an RC bug, and I'll work to make sure that doesn't happen. This does just mean you don't care a lot about translation and can live with an (sometimes bad) english-only distribution. It means I don't feel it should be release critical. Perhaps more than 'wishlist' but I don't feel a translation is release critical. I expect most would agree with me. I cannot and most people cannot too. If you're confident of that then write up the appropriate language and put it to a vote. This is why maybe some day using tools which help translation work may become mandatory (ie po-debconf instead of plain debconf templates, gettexted README.Debian files, translated man pages and so on...). Perhaps, though I doubt it. At least not until the overwhelming majority of the packages are already there. I think it is a very long way off before lack of complete support for a language would hold up a release. I think we would need a much larger set of people performing the translations and alot more support in the base tools, at a minimum. Such tools make translation minimalistically invasive, thus allowing people with limited noble hacking knowledge to still make significant contributions to the whole stuff. Sure, perhaps some day everything will support translations and we'll have a hundred or more people translating everything from debconf questions to changelog entries. I see it as quite a ways off before that happens and I don't think translations should even be considered for the possibility of being release-critical until we have such a devoted group of people who have translated basically everything in Debian. I (and the whole l10-french team too), currently, have one goal : just have 100% prompting made in french in my favourite Linux distribution. The tools are there, the manpower is there and the motivation is
Norton AntiVirus failed to scan an attachment in a message you sent.
Recipient of the attachment: SEXCHANGE, RADIANT\RII, StellaHsieh()/ Subject of the message: Re: That movie No action was taken on the attachment. Attachment document_9446.pif was Logged Only for the following reasons: Scan Engine Failure (0x80004005)
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
Looks like it's time to drop down this one... :-). Such debate with strong opposition would now need a meeting around a beer : we've reached the point where none of us will move anymore.. :-)
Norton AntiVirus failed to scan an attachment in a message you sent.
Recipient of the attachment: SEXCHANGE, First Storage Group\Mailbox Store (SEXCHANGE), mailbackup/ Subject of the message: Re: That movie No action was taken on the attachment. Attachment document_9446.pif was Logged Only for the following reasons: Scan Engine Failure (0x80004005)
Re: FTBFS: architecture all packages
On Fri, Aug 22, 2003 at 10:57:53PM +0200, Goswin von Brederlow wrote: Colin Watson [EMAIL PROTECTED] writes: ... Have you ever built kde-i18n? When I last NMUed it it took something like nine hours for my laptop to build it, and my laptop isn't all *that* wimpy. Not surprising given its a ~650 MB sources. Unpacking and packaing alone will take hours on m68k I guess. But an idle buildd is idel so no harm in him building it. On the other hand you downloading 200 MB and uploading 400 MB with a 38400 modem would realy hurt. Well not you but someone only having a 38400 connect. Build package on debian machine with fast connection by accessing with ssh. Then copy 2 small files (dsc, changes) to the local machine and sign. Copy back them and upload. You do not need to upload rom your local machine. So your bandwidth is not key issue here. (I have ADSL connection and I admit I do things locally.) Osamu
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 12:19:57PM -0500, Branden Robinson wrote: No. It's a way to assess whether the silent majority arguments raised by a few loud people on debian-legal, claiming that most people don't really believe that the GNU FDL needs to satisfy the DFSG, are the real consensus view. ??? The survey asks whether the GFDL _does_ satisfy the DFSG, not whether it needs to. Did you misspeak here? Richard Braakman
Re: Debian Weekly News - August 19th, 2003
On Fri, 22 Aug 2003, John Goerzen wrote: The corrolary is that 0% of Debian is non-free software. Documentation is not software at all. Ah. So we're 97% Free Software, 3% Documentation, and 0% Non-Free Software.[1] Thanks for clearing that up. If you take Clause 1 of the Social Contract to literally mean that Debian contains nothing save software that is free, then that clause has never been true since it was introduced, since we have always contained many non-software items (documentation, bibles, Linux Gazette issues, RFCs, graphics, wallpapers, sounds, etc.) But typically those files have had the same freedoms that software has in Debian. In cases where they don't, RC bugs have been filed and stinks raised. [IE, for RFC's, and GFDL'ed documentation.] Regardless, if Debian wants to include documentation that is not free under the DFSG, it pretty much has to do so via GR. Why don't you draft and propose a GR on -project that modifies the Social Contract and provides a DFDG or similar to remove this ambiguity? Until that point, I don't really see -legal and/or ftpmaster doing much else than conservatively interpreting and acting upon the Social Contract and the DFSG. Don Armstrong 1: Obviously arbitrary percentages -- People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpm5QUbyrvW1.pgp Description: PGP signature
Re: stack protection
On Fri, Aug 22, 2003 at 10:05:13PM +0200, Goswin von Brederlow wrote: Depending on the size of udev it might be on the initrd or not. If its not then you need a lot of /dev entries to mount the real root device and get udev started or a extra script that created node on the fly from /proc/something. Actually, no you don't. The real root is created on the fly with mknod with the major,minor numbers supplied from the kernel (/proc/sys/kernel/real-root-dev). See /usr/share/initrd-tools/init for details. (at least thats how I read the code, I don't claim to be an expert on this file, under certain circumstances it would appear to parse the /proc/cmdline directly). -- Brian May [EMAIL PROTECTED]
Tune-Town auto response Mail.
Tune-Town auto response Mail. Thank You for shopping Tune-Town. INSTALLATION NEEDS This message is to confirm we have recieved your mail. For all questions please call toll free 1-877-227-0003. If you are an installer check out our Exclusive Technical Section, for installers only. With hundreds of detailed techtips, check out the free samples. They include details on relays, radio wiring harnesses, autostarters, alarms, passlock I II III, and so much more. All for just $10.00 per Year. http://www.tune-town.com/technical.asp If you have mailed a Question, that you would rather call. Please call 1-419-627-0065 1-877-227-0003 (USA Only) during store hours. Store Hours Mon-Fri 9:00am - 5:00pm / Sat - 10-4pm / Sun. Closed Eastern To Fax 1-419-627-0099 http://www.tune-town.com/ What fits My Car? http://www.tune-town.com/Cars/stuff/Default.htm
Re: Debian Weekly News - August 19th, 2003
On Aug 22, Brian T. Sniffen [EMAIL PROTECTED] wrote: Additionally, whether the DFSG should apply to documentation in Debian is not relevant to the survey, which asks whether the GFDL complies with the DFSG: we can deal with the insanity of whether this software over here is or is not software later, but figuring out whether the GFDL is a DFSG-free licence for software is also important. That's what the survey's asking about. I'd say that you have your priorities wrong. If we decide that documentation is not software then there is no reason to waste time to figure out if the GFDL is DFSG-free or not. -- ciao, | Marco | [1421 le2huYnaegCMI]
Re: Your details
Hi, I'm on holiday from 16th August until 31st August, but I'll reply to you as soon as I'm back. For urgent issues, you can try contacting my manager, [EMAIL PROTECTED], who may be able to help. This message is automatically generated, and will only be sent to you once. -- Alan Burlison --
Bug#206807: ITP: pythoncard -- PythonCard GUI Framework
Package: wnpp Version: unavailable; reported 2003-08-22 Severity: wishlist * Package name: pythoncard Version : 0.7.2 Upstream Author : PythonCard Developers * URL : http://pythoncard.sourceforge.net/ * License : BSD Description : PythonCard GUI Framework PythonCard is a GUI construction kit for building cross-platform desktop applications on Windows, Mac OS X, and Linux, using the Python language. It is based on the Python bindings for the WxWindows toolkit. I already have preliminary packages completed, and I'm in the process of having them beta-tested by users on the PythonCard mailing list. I intend to upload after the 0.7.2 release of the package early next month. The source package is split into several binary packages: pythoncard - Meta package pythoncard-tools- Scripts, tools, etc. pythoncard-doc - Documentation and samples python-pythoncard - Installs python2.3-pythoncard python2.3-pythoncard- Python libraries The license situation was what stopped me from uploading this the last time (in February); since then, they've settled on a BSD-style license, and someone will be putting together a list of contributors and making sure that everything is in order before I upload. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux agamemnon 2.4.18 #1 Sun Aug 17 17:40:33 CDT 2003 i686 Locale: LANG=en, LC_CTYPE=en_US (ignored: LC_ALL set) pgpGC223aLNhZ.pgp Description: PGP signature
Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)
On Fri, Aug 22, 2003 at 05:17:54PM -0400, Stephen Frost wrote: And, as Steve pointed out, translation stuff is minimalistically invasive so this does not require an enormous amount of attention after the NMU. When you do an NMU you're taking the responsibility to maintain the package until the maintainer is active on it. If you're not willing (or able) to handle the package just for a translation then you shouldn't be doing the NMU just for the translation. But, sorry, if a RC bug is raised which is obviously unrelated to the things I changed, why should I care for it more than the normal wayt (ie, if by chance I can deal with it...I *will* do just like I would with any RC bug I'm able to fixbut if I'm perfectly unable to fix it besides tagging the bug help, what should be done ?) Maintainers aren't always able to fix RC bugs themselves so you should do exactly what the maintainer would do in such a case since it's against your NMU, even if it's unrelated to the specific change in your NMU it's still your NMU so it's your responsibility. The maintainer would probably tag it with help and work with upstream to find a fix for it. Er. You're going to hold NMUers responsible for the general crappy state of a package before they got to it? Are you also going to concede to them the authority to request the package's removal from the archive without the maintainer's consent, or is your position specifically formulated to discourage QA work? Responsible NMUing means taking responsibility for *your changes* to the package and any bugs that may result from them. It does not mean being stuck with the responsibility for fixing all new bugs filed against the package, like the loser of a game of hot potato. That makes no more sense than to say an NMUer is responsible for all open bugs on the package unless the maintainer uploads. -- Steve Langasek postmodern programmer pgpUOJbPjciwI.pgp Description: PGP signature
/etc/shells management
I just uploaded a version of shadow that provides scripts for the maintenance of /etc/shells. I decided very quickly when I became the shadow maintainer that I didn't want to (and probably wasn't qualified to be) an arbiter of acceptable shells. So: /etc/shells is no longer a config file, but is maintained by the add-shell and remove-shell programs. So, if a package contains something that the maintainer thinks ought to be a valid login shell, it's postinst should, (on initial install only, to allow a sysadmin to take it out again), run: /usr/sbin/add-shell /path/to/shell In the postrm, probably on remove, the package should call /usr/sbin/remove-shell /path/to/shell Packages using this mechanism must declare a dependency on passwd (= 4.0.3-10). As the various shells start to use it, the default shells list will start getting shorter, but that's not expected to happen until at least sarge+1. (you will be able find the above documentary verbiage in /usr/share/doc/passwd/README.shells) share and enjoy kcr
Accepted mew 1:3.3-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Aug 2003 07:33:42 +0900 Source: mew Binary: mew mew-bin Architecture: source all i386 Version: 1:3.3-2 Distribution: unstable Urgency: low Maintainer: Tatsuya Kinoshita [EMAIL PROTECTED] Changed-By: Tatsuya Kinoshita [EMAIL PROTECTED] Description: mew- Messaging in the Emacs World mew-bin- The external commands for Mew Changes: mew (1:3.3-2) unstable; urgency=low . * debian/control (Suggests): Add `x-face-el, mule-ucs, mhc'. * debian/control (Description): Revised. * debian/rules: Don't use dh_undocumented. * debian/*: Ready for mew-beta. Files: 68040c75d92aa7a315a596281472aae6 582 mail optional mew_3.3-2.dsc 862e1385c432f3ae7bce6f789e39287f 18328 mail optional mew_3.3-2.diff.gz 62c74caf98d2dead605c89c83df05c36 687966 mail optional mew_3.3-2_all.deb ca166d3521324f526a8b65bd91bf96ba 41116 mail optional mew-bin_3.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/RaHthgeQPb3wqtARAndPAJ9eIEkuh8WgufQyQoFG19J/NKGf+ACfRfcB ypLQODJSKMRdCavLjRZsff0= =4qPF -END PGP SIGNATURE- Accepted: mew-bin_3.3-2_i386.deb to pool/main/m/mew/mew-bin_3.3-2_i386.deb mew_3.3-2.diff.gz to pool/main/m/mew/mew_3.3-2.diff.gz mew_3.3-2.dsc to pool/main/m/mew/mew_3.3-2.dsc mew_3.3-2_all.deb to pool/main/m/mew/mew_3.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
