Example for use of dh_strip --dbg-package=... and CDBS?
Hi, are there any CDBS based packages using dh_strip with the --dbg-package option? I tried, but no /usr/lib/debug/ directory is created. I'm using debhelper 4.2.30 with cdbs 0.4.26-1.1. Many thanks in advance! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Example for use of dh_strip --dbg-package=... and CDBS?
Quoting Josselin Mouette <[EMAIL PROTECTED]>: > I'm using it with fontconfig, just have a look at the rules file. Thanks to Aaron and Josselin! My fault was to set --dbg-package=libfoo-dbg instead of --dbg-package=libfoo :-) Both fltk1.1 and fontconfig are fine examples. Cheers! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS and other build systems
Quoting "Ivan S. Dubrov" <[EMAIL PROTECTED]>: > The problem is I can't find thorough documentation or some kind of "How To" > there I can find how to write these extensions. Although they just simply > pieces of make-files, I find it difficult to start understanding them. For > example, the diffirence between "rule" and "class" are not very clear for me. I like CDBS a lot and all my packages use it. Unfortunately, the documentation is not very extensive. OTOH, the variables are well documented in the makefiles, i.e. just read through /usr/share/cdbs/1/{class,rules/* Furthermore, there is https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml in English and http://www.ngolde.de/cdbs.html in German. Other things, I did: I looked for packages build-depending on CDBS and stole from the debian/rules, and I asked "stupid" questions on the CDBS hackers spam exploder: http://lists.alioth.debian.org/mailman/listinfo/build-common-hackers With some luck, questions get answered. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploading amd64 packages
On Sun, Nov 20, 2005 at 11:20:59PM +0100, J?r?me Marant wrote: > I meantioned one solution. There is another possible one: source uploads. > And no, I don't think it would cause more breakages than nowdays because > uploading sources only doesn't meant packages have not been build on > our systems. I couldn't agree more: source uploads are a good idea. It seems to work for Ubuntu. However, we have discussed this issue before and there was no consensus and worse, no implementation. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336698: dh_strip: debug data going to the wrong place
On Sun, Nov 20, 2005 at 04:21:29PM -0500, Daniel Jacobowitz wrote: > - They may be compiled with lower optimization. > - They may be compiled with behavior-altering debugging options. Yes: One has a crash, tries a debug version of a library and suddenly everything behaves totally different, e.g. no crash or a different one :-( So, unfortunately you're right. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
Quoting Thiemo Seufer <[EMAIL PROTECTED]>: > Arabic is "ar", IIRC. For groups of languages like cjk or indic it might > make sense to split the packages further, or, if that's not feasible, > use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style > two-character). ISO-style can be two-character (ISO 639-1) or three-letter (ISO 639-2). The latter is IMHO more useful for TeX, as more languages have a code. Arabic is either "ar" or "ara", Aramaic is "arc", Apache is "apa"... "cjk" is currently not an ISO code, but it could be in the future. However, cjk is well-known, so ISO would be very stupid to use this code for anything else than zho-jpn-kor. Indic already has an ISO language code: "inc". Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Multiple package variants with CDBS?
Hi, I have a package that is configured and compiled two times, so that two binary packages are built in one dpkg-buildpackage run: One with --enable-gnome, the second without. Is this supported by CDBS somehow? Is there a package, that already does such a thing using CDBS? Any hint or example debian/rules file appreciated, thanks in advance! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_installinit and update-rc.d start vs. restart
Hi, for some kind of CDD I have created a package "X" that changes another packages "Y" config file (using cfengine) and restarts the respective daemon. That works well, if I upgrade package X only or Y only. Problem: If I upgrade both package X and Y at the same time the daemon of package Y will be stopped, than X changes the config, restarts daemon of Y, finally Y tries to start its daemon, but fails, as it already runs. If package X would update-rc.d restart in postinst, it would be perfect, right? Is there a convince dh_installinit to use "restart" instead of "start" in package X? Are there other ways to solve such a problem? Cheers, WB Btw: Both X and Y use CDBS and debhelper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit and update-rc.d start vs. restart
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>: > File a serious bug against package Y. initscripts have to exit with a > successfull status if the daemon is already running. OK. As this package Y is not (yet) part of Debian, I just changed it: I added --oknodo to start-stop-daemon and check for $? -eq 0. Seems to work, thanks! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is there a serious NPTL problem with sarge?
Hi, a colleague observed crashes in some heavily multi-threaded Python applications. He is running Debian sarge with stock kernel 2.6.8-2-686. Using LD_ASSUME_KERNEL "fixes" the crash, so it seems to be an NPTL issue. (Maybe stupid) questions: - Is it relevant, whether Python is compiled on a system with 2.6 or 2.4 kernel? If so, how can I find out on which kernel the Debian package has been built? In http://mail.python.org/pipermail/python-bugs-list/2005-February/027693.html Martin von Loewis wrote: "The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries." - Is the Debian stock 2.4 kernel patched to be compatible with NPTL? If not, isn't there a problem for some multi-threaded applications to switch between 2.4 and 2.6? (Note: AFAIK, RH, Mdk, and SuSE use some patch, at least Fedora seems to have "nptl" in the 2.4 kernel version number.) Thanks in advance for any clarification. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304401: ITP: libstatgrab -- library providing interface to system statistics
Webpage: http://www.i-scream.org/libstatgrab/ not www.example.org :-) It would be great, if you package pystatgrab (http://www.i-scream.org/pystatgrab/) as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Provide a DocBook/XML version
Package: vera Version: 1.12-1 Please provide a dbk version of vera, as this can be used by document authors (automatic inclusion of used glossary entries is supported by docbook-xsl!). [Note: Maybe it's easier to use dbk as source format and generate info than the other way around.] Btw.: You should ask upstream, whether he likes to change the GFDL of vera into GPL (or to dual license it). Example for DocBook glossary from http://www.faqs.org/docs/docbook/html/glossary.html: http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";> Example Glossary This is not a real glossary, it's just an example. E Extensible Markup Language XML Some reasonable definition here. SGML S SGML Standard Generalized Markup LanguageSGML ISO 8879:1986 Some reasonable definition here. XML -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315903: ITP: evilfinder -- proves that any given subject is evil
Package: wnpp Severity: wishlist Owner: "W. Borgert" <[EMAIL PROTECTED]> Package name: evilfinder Version : 666(?) Upstream Author : Michal Zalewski <[EMAIL PROTECTED]> URL : http://lcamtuf.coredump.cx/evilfinder/ef.shtml License : under clarification, hopefully GPL Description : proves that any given subject is evil Example output for input "Debian": THE PROOF THAT Debian IS EVIL D E B I A N 4 5 2 9 1 14 - as numbers 4 5 2 9 1 5 - digits added \_/ \_/ \_/ \_/ \_/ 4 5 2 9 6 - digits added Thus, "Debian" is 45296. Subtract 140, the smallest harmonic divisor number. The result will be 45156. Turn the number backwards, subtract 1926 - the year "Playboy" publisher, Hugh Hefner, was born. The number is now 63228. Subtract 1789, the year of French Revolution, a bloody farce engineered by the Illuminati. The result will be 61439. Add 7691 to it - this is the year Che Guevara was executed in Bolivia, written backwards - you will get 69130. Turn the number backwards, subtract 1964 - the year Beatles with "Can't buy me love" topped the charts in a very mysterious way. The number is now 1232. This number, read as octal, gives 666 - the number of the Beast. This is truly evil. QED. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315903: ITP: evilfinder -- proves that any given subject is evil
Quoting David Pashley <[EMAIL PROTECTED]>: > Do we really need this in the archive? Can we not add this to another > package under games? It is rather small and doesn't serve a significant > amount of functionality. Yes. Please suggest a package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Embedded(/RT) Debian? Embeddian GNU/Linux?
Hi, does anybody know, wether there are ideas or plans to make an Debian GNU/Linux especially for embedded and/or realtime systems, i.e. "Embedian GNU/Linux"? I think, that the Linux Router Project was once based on Debian, but this is very specialised on one task. And I don't know what Mobile Linux (Crusoe) will be. I think, that the standard Debian GNU system is not well suited for embedded systems, because - policy requires docs and man pages, but one does not want any docs or man pages on an embedded system; - the base system/required packages is far too much for embedded systems, e.g. one does not want perl necessarily; - packages have to be even more fine-grained, or one does need some options to install packages partially. OTOH, embedded Debian GNU would be cool, because, - superior package management; - large number of packages in potato; - good Debian infrastructure; - it would be easy to have one distribution, that would work for a lot of different computers, like routers, telephones, VCRs, ATMs, washing machines, PDAs... Well, is there sth. like this already or are people working on this? TIA, -- W. Borgert <[EMAIL PROTECTED]>
ITP: ttcn-el (programming modes for protocol test)
Hallo, I am right now packaging three Emacs programming modes, I wrote between 1997 and last week: ttcn3.el, ttcn.el, and tm.el. These are for the TTCN-3 core language, the current TTCN.MP language (version 2), and the Test Manager language (an Forth enhancement of the Tektronix K1297 protocol tester). So, it's all related to protocol testing. I'll release this under GPL, of course. Section: editors Priority: optional Package: ttcn-el Architecture: all Depends: emacsen Description: GNU Emacs modes for TTCN-3/protocol testing languages. Cheers, -- W. Borgert <[EMAIL PROTECTED]>
Usability: Technical details in package descriptions?
Hi, what do you think about the usefulness of technical (and other strange) details in package description? I think, those are annoying and should be avoided, but maybe I can learn, why they are useful. Examples: "Foo is a Perl-based program that..." "libBar is written in C..." "libBang is written in only 42 lines of source code..." "Baz has been written by me..." Do such descriptions justify bug reports of severity=minor? Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to use svn(-buildpackage) with pbuilder?
Hi, what is the right/best way to build packages from SVN using pbuilder? I am new to both, please be patient. Suppose, I have a package with complete upstream sources (no tarballs) under svn://svn.debian.org/svn/pkg-greetings/hello/ with the subdirectories branches/, tags/, and trunk/. - How do I have to arrange the repository, so that svn-buildpackage differentiates correctly upstream and debian stuff? Is it correct to have the upstream source only under pkg-greetings/hello/tags/1.0/ and the complete debianised tree under pkg-greetings/hello/tags/1.0-1/? Or do I have to put the upstream under pkg-greetings/hello/branches/upstream/1.0/? - How do I call svn-buildpackage, so that pbuilder is used? Is --svn-builder=pdebuild enough? - Has somebody a good build script that does all steps automatically? 1. checkout from svn, 2. build in pbuilder, 3. run linda, 4. run lintian, 5. run piuparts. Many thanks in advance! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote: > (1) keep vulnerable packages in stable, > (2) remove affected packages from distribution, > (3) allow new upstream into stable. ... > What do you think on this? I'ld "vote" for (2), maybe with the goal of creating pressure towards upstream to take security more serious. Don't forget: The new versions will bring trouble to our poor users, as it's not API nor ABI compatible, has different bugs, etc. Can't Debian + Ubuntu + ... create enough demand for useful security patches? Remember the KDE/Qt licensing discussion... (3) is second best. At least typical server installations are not affected (we use w3m, don't we?) and desktop users are used to frustration anyway. (1) is not an option. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
On Sun, Jul 31, 2005 at 10:07:10PM +, Roland Rosenfeld wrote: > But how do you push the users to remove the package from their > systems? In reality they will keep the broken version installed and > so you have (1) again :-( Empty package with a higher version number? Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use svn(-buildpackage) with pbuilder?
On Sun, Jul 31, 2005 at 07:03:14AM -0400, Yaroslav Halchenko wrote: > borrowed from a nice minimalistic HOWTO > http://workaround.org/moin/SvnBuildpackage That is indeed a very helpful HOWTO. Thanks! > 3 and 5 just add them to --svn-postbuild as IT IS SAID IN THE MAN PAGE: :-) OK, thanks. One more question, I could not answer myself from reading the man page: If I have the complete upstream source in SVN, but not the .tar.gz, how do I create the .orig.tar.gz, when I have a new upstream version? Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use svn(-buildpackage) with pbuilder?
On Tue, Aug 02, 2005 at 03:49:54PM -0400, Yaroslav Halchenko wrote: > Look down the thread -- your question was answered: > > Date: Mon, 01 Aug 2005 16:03:03 +0200 > From: Arjan Oosting <[EMAIL PROTECTED]> > > It is, the orig.tar.gz is created if you do a > FORCEEXPORT=yes svn-buildpackage Works OK, thanks. There should be an automatised way: If it's a 'xxx-1' version (first package of an upstream release), the .orig.tar.gz should be created, otherwise not. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shouldn't I use update-alternatives for this?
Quoting Sebastian Kuzminsky <[EMAIL PROTECTED]>: > I've pushed the "rename it upstream" idea on the upstream maintainers > twice now and it gets shut down by both Linus (the original author) > and Junio (the current maintainer). [2] There is still the option to rename it for Debian only, without changing it upstream. Not really nice, but possible and used in the past, IIRC. > Qingning Huo suggested using diversions to make /usr/bin/git a little > selector script that lets the admin & user choose between git-the-shell > and git-the-scm. This sounds good to me, who objects? Aarrgghh! :-) That's what alternatives are for and people already objected for good reasons. Please not. Either rename the executable to /usr/bin/git-the-scm (or whatever) or conflict with the other git. Or ask the other git people to rename their binary. Maybe git-the-scm is (or will be) in wider use than git-the-shell, so it might be OK to rename the more "obscure" executable. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shouldn't I use update-alternatives for this?
Quoting Henning Makholm <[EMAIL PROTECTED]>: > Conflicting is Not An Option. So policy says, for good reasons. OK, bad idea. > There is precedence to consider. Sarge already contains a git package > that provides /usr/bin/git. Users who update from sarge to etch would > not be served well if the software they are used to suddenly changes > name just to accommodate a newcomer. > > OTOH, cogito is not in sarge; there are no prior user expectations > about what its command name should be. Well, there will be user expectations (e.g. if people use cogito-git on other distributions as well), but I agree: We can live with that. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: runlevels remodeled
Quoting Timo Aaltonen <[EMAIL PROTECTED]>: >Is there will to change the current policy regarding runlevels in > Debian? I'd propose to use the recommendation made by LSB: IIRC, there were discussions about that issue. I don't remember the outcome and would like to see Debian more LSBish here. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New appearance of bugs on BTS web pages
On Fri, Aug 12, 2005 at 04:26:00PM -0400, Roberto C. Sanchez wrote: > However, I am wondering if it is a bug that the pages are not even valid > HTML 4.01. Is this a bug? Should I file a bug agains the b.d.o psuedo Shouldn't it be XHTML nowadays? Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
README - confusing, irrelevant, redundant, useless
Hi, I have to start yet another discussion about our packaging practise. Did anyone ever take a look at our /usr/share/doc//README{,.gz} files? If the users have difficulties with a package, we often reply "Why didn't you read the README? It's called README for a reason!" However, the README files are cluttered with confusing, irrelevant, redundant, and useless stuff. That way, we educate our users not to ReadTheFineReadme. Do you think, that this does any favour to our users? E.g. - "Debian packages of this software are currently available. It should be possible to run "apt-get install " and have a recent version installed." This is a Debian package, so what? - "Please send bug reports, requests for features, etc. to ." Don't we ask our users to use our BTS primarily? - "To build , please run: ./configure; make; make install." This is OK to have in the source, but not in the .deb. Same goes for information about possible configuration options. OTOH, the configuration options actually used in the Debian package are seldomly documented :-( - ...long history of who maintained the package when... This information - not really relevant to the user - is, of course, in the changelog as well. - ...stuff about API usage in a library package... That does belong to the -dev package only, right? - "Common options: --foo --bar --baz" According to our policy, the program has a manual page. While it's not bad, to repeat the information in other formats, it does - IMHO - not make sense in a README. - "Readme file for ." Really? - "This program is..." - exact copy of the package description. This README is redundant. - "$Id: ... $" (one line Id plus four lines of text) Maybe I become picky, but CVS/RCS ids are not relevant to the user, esp. if the remainder of the README is irrelevant, too. - "The latest version of can be obtained at ." As a Debian user, I expect to get packages the Debian way. It's nice to have the upstream website address, but according to our policy I can find it in the copyright file. Package maintainers, please: 1. Do not include the upstream README in the binary package, if it's not really important to the user. 2. Just copy the 5..10% of relevant information into the README.Debian, if appropriate. 3. Don't invent a README file artificially, if you don't have to say anything. 4. File minor bugs about such README files. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dogme05: Team Maintenance
Hi, as a conclusion of many discussions at DebConf5, I propose to maintain all packages by teams. A fine way to do this, is by having a pkg- project at alioth.debian.org. It is useful to invite non-DDs, esp. upstream developers and people from Debian derivatives to participate in such teams. Assumptions: I. The most important packages in Debian are maintained by teams. The experience with that modus operandi is very good. II. Team maintainance gives higher quality packages, as more people look at the packaging details. III. The responsiveness on bug reports is higher, as more people can react without having to NMU. Adjustments between team members can slow down this, but this is just a matter of agreements inside the team. IV. Less need to orphan packages, as most teams will not collapse, if a single maintainer drops out. Less work for our lion-hearted QA team. V. If not at least two maintainers can be found for a particular package, it is not worthwhile to have it in Debian, at least not in a release. experimental is OK. VI. The advantages of team maintenance outweigh the problem of team maintenance overhead. VII. Team maintainence helps us to collaborate with upstream and derivers. VIII. Packages not maintained by teams are not to go into unstable/testing/stable. IX. As alioth becomes even more important to Debian, we will have to strengthen (HA-ing) this resource. X. Teams shall meet online or in sauna. They are allowed to do DDR or ballroom dancing. [Dogme05 is, of course, a pun on Dogme95.] Cheers, -- Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323076: ITP: dealer -- bridge hand generator
On Sun, Aug 14, 2005 at 06:58:40PM +0200, Jesus Climent wrote: > On Sun, Aug 14, 2005 at 06:09:57PM +0200, Christoph Berg wrote: > > * Package name: dealer ... > > Description : bridge hand generator ... > 2. after reading and re-reading both the description and the long description, > i have no clue whatsoever what the program is for. Hopefuly in the final > package it will be reworded... A "bridge" works on OSI layer 2 (data link layer), unlike a router. So it must be a dll network traffic "generator", you have to manually ("hand") pay for ("dealer"). Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Sun, Aug 14, 2005 at 12:55:11PM -0400, Benjamin Seidenberg wrote: > While I agree the README can be confusing, I think we do a disservice > to our upstream by not including it. Some readers may be interested in > the people who brought them the software, or knowing upstream's email /usr/share/doc//copyright, according to our policy? > or any of these items you mention. As for readme versus man page, I Don't you think that most of the examples I gave are utterly irrelevant to about 100% of our users, including me and you? > find manpages are usually more of a reference about syntax while > readme's are closer to a tutorial on usage. All my examples show, that a lot of READMEs do not contain tutorials, but irrelevant information. I did not say anything against useful information or tutorials in README files. I personally would prefer a tutorial in a file named, hm, maybe "tutorial"? > I think a better solution would be to duplicate all the important > information about the software into the README.Debian and train users > to read that soley. The original readme is still intact for those > users who care. In addition, I would like to see a standardazation on The name of the file "README" suggests reading its content is highly important to the user. Sometimes it really is. The huge number of useless READMEs thwarts that. I still think, information irrelevant to the user should be removed from the binary package. If one really cares, apt-get source . > whether to compress the README and similar files, I always end up > typing less /usr/share/doc/blah/README.Debian[.gz] using tab > completion and have to go back and correcting my command to use zless > because half are compressed and half aren't. I also agree with what Doesn't /bin/zless work for both? > Branden said in his WTFM presentation at debconf.. a readme command to > display the readme's to the user would be a very nice tool. Yes. Unfortunately, I arrived one day too late for the talk. Otherwise, I would have criticised Branden for proposing hacking *roff instead of using DocBook/XML refentries :-) Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323076: ITP: dealer -- bridge hand generator
On Sun, Aug 14, 2005 at 07:51:47PM +0200, Christoph Berg wrote: > (Maybe ITPs should include the proposed section (games in this case) > to resolve confusions like these.) Or better, as sections become obsolete, the proposed debtags. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Sun, Aug 14, 2005 at 08:17:53PM +0200, Jesus Climent wrote: > On Sun, Aug 14, 2005 at 12:02:36PM +0000, W. Borgert wrote: > > - "Readme file for ." > > > > Really? > > Well, you want to know which package a README belongs to when you get a README > without any other information... right? Nice, if you find the README under /lost+found/ (remember the times before journalling?), but in all other cases, a user knows their files. Or do you suggest to tag all files in Debian with such an information? :-) Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 08:45:43PM +0200, Marco d'Itri wrote: > On Aug 14, "W. Borgert" <[EMAIL PROTECTED]> wrote: > > as a conclusion of many discussions at DebConf5, I propose to > > maintain all packages by teams. A fine way to do this, is by > "One size fits all" methods are a bad idea. Different packages and > different maintainers have different requirements. You would have different teams still, so it's not "one size fits all". Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Sun, Aug 14, 2005 at 10:10:42PM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > their files. Or do you suggest to tag all files in Debian with > > such an information? :-) > > Open a man page. Because it has a NAME section? OK, you won :-) Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 03:52:55PM -0500, Adam Heath wrote: > Haha, this gave me a good laugh for an email. Altho, as far as jokes go, this > was rather poorly delivered. If I would make my living as an entertainer or comedian, I would have to live on social security or be hungry :-( Sorry. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 03:42:23PM -0500, John Hasler wrote: > You would have a team maintain 'units'? That's silly. If the team maintains only the package 'units', yes. If the same team maintains multiple relating packages, it's different. E.g. the Debian XML/SGML group maintains 22 packages. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Mon, Aug 15, 2005 at 02:18:39AM +0200, Henning Makholm wrote: ...a lot of wise things... I have to agree. So how to proceed? File minor bugs against README files, that contain predominantly useless information? Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
On Sun, Aug 14, 2005 at 08:29:47PM -0300, Ben Armstrong wrote: > Says who? I maintain some packages like this. Let's say I support 50 > to 100 niche users for a given package, but I'm the only developer in > the user community who cares to maintain the package in Debian. I > maintain the package well, and my users are happy. I would not be at > all happy if my package were forced out of Debian because it's "not > worthwhile". I think that would be a terrible injustice to my users. Some of the things under Dogme05 is certainly exaggeration. Sorry, if people thought I want to propose enforcement of "team maintenance policy". However, team maintenance for all essential and standard is worthwhile and not un-realistic. > "HA-ing". I'm sorry. I don't know what you mean. Sorry, we may have to many abbreviation based verbs already, so I should not invent new ones: HA = high availability. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Mon, Aug 15, 2005 at 10:55:20AM +0200, Andreas Tille wrote: > Idea 1: > lintian: W: /usr/share/doc/README contains installation instructions I like that one. Cheers, -- Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Mon, Aug 15, 2005 at 09:53:37AM +0200, Henning Makholm wrote: > Go ahead and file bugs. With patches. And perhaps an explanation > of why a README in the .deb is not required and, if it exists, is not > required to equal upstream's. > > When a few dozen of your patches have made it to sid, condense your > experience into a well-reasoned, not too long, best practices summary > which acknowledges that maintainer discretion is still required for > many things, and offer it for inclusion in the Developer's Reference. I'll start with my own packages. They give really bad example of useless READMEs. Cheers, -- Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: README - confusing, irrelevant, redundant, useless
On Mon, Aug 15, 2005 at 12:42:27PM +0200, Henning Makholm wrote: > Yes - but how should Lintian detect it? Of course one could look for > lines that start with whitespace plus "./configure ", but how reliable > is that? Attached test found some culprits: aptitude autofs dbus-1 dbus-glib-1 deborphan dhcp3-client docbook2x etherape ethereal-common ettercap-common finger ftp gettext gimp-gap gjdoc gpm kismet libatk1.0-0 libpam0g libpcre3 libtiff4 libungif4g libxml2 m4 man-db nano netkit-inetd nfs-common python-gtk2 python2.3 ruby1.8 sharutils tar telnet w3m xfce4-session xfwm4-themes xfwm4 zlib1g Cheers, -- Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ import gzip import re from linda import libchecks, checks class ReadmeCheck(libchecks.LindaChecker): 'Checks the upstream README file' def check_binary_2(self): self.parse_readme() def parse_readme(self): k = None readme = os.path.join(self.information['dir'], 'unpacked/usr/share/doc', self.pkg_name, 'README') readmegz = os.path.join(self.information['dir'], 'unpacked/usr/share/doc', self.pkg_name, 'README.gz') if os.path.exists(readme): f = open(readme) k = f.read() f.close() elif os.path.exists(readmegz): f = gzip.open(readmegz) k = f.read() f.close() if k: configure = re.compile(r'\./configure') if not self.pkg_name.endswith('-dev') \ and re.search(configure, k): self.signal_error('readme-contains-make-instructions') del k checks.register(ReadmeCheck) Tag: readme-contains-make-instructions Type: Warning
Re: Dogme05: Team Maintenance
On Tue, Aug 16, 2005 at 02:38:01PM +0200, Alexander Schmehl wrote: > Do you realy think you can enforce teamwork? I don't think so. Either > some people will work together as a team or individuals will do it their One cannot enforce teamwork. Dogma #10 suggests team meetings in sauna as encouragement for team building. > own way. And I don't think it will be a good idea, to force those > individuals to work in a team. Debian is a large-scale team. Teamwork is a necessity for all the 1278(?) of us. Not by force, maybe by sauna. Cheers, -- Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323923: ITP: base -- Basic Analysis and Security Engine
On Fri, Aug 19, 2005 at 05:59:49PM +0200, martin f krafft wrote: > also sprach Jon Dowland <[EMAIL PROTECTED]> [2005.08.19.1747 +0200]: > > I suggest base-security-engine, even though it's quite verbose and > > the latter two words redundant after the acronym. `base-engine' is > > better than just base, but similarly could be mistaken for something > > else important. > > How about acid-base? This sounds less confusing than base-{,security-}engine. For the latter I would assume an important security package of the Debian base system or so. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323923: ITP: base -- Basic Analysis and Security Engine
On Sat, Aug 20, 2005 at 12:05:51AM +0200, martin f krafft wrote: > also sprach W. Borgert <[EMAIL PROTECTED]> [2005.08.19.2049 +0200]: > > > How about acid-base? > > > > This sounds less confusing than base-{,security-}engine. For > > the latter I would assume an important security package of the > > Debian base system or so. > > And the next, or a related project, could be called saltwater. At least that's not a contradiction in terms :-) No, I really did not think about chemistry, when I read acid-base. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Be sure you pack your bags yourself (was: Results of the meeting...)
On Sun, Aug 21, 2005 at 07:28:55PM +0200, Jonas Smedegaard wrote: > Currently, sponsored packages are only signed, not built, by official > Debian Developers. Be sure you pack your bags yourself. Keep your bags under your control at all times. Never carry a package with unknown contents for any reason. I hope, that no DD ever signs a package, unless created by a DD and already signed by them. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Using buildds only (was: Results of the meeting...)
Quoting Sven Luther <[EMAIL PROTECTED]>: > All packages should be built by official debian buildds anyway, not on > developper machines with random cruft and unsecure packages installed, or > even > possibly experimental or home-modified stuff. That would be very good, indeed. I am very much in favour of allowing only source-only uploads and having all binaries build by the buildds only. The argument against it is, that DDs wouldn't check, whether the package builds cleanly etc. I think, that this is a poor argument, but anyway. Fortunately, Martin Krafft came up with the idea of allowing source-only uploads only together with a signed test protocol. The test protocol would have to include the output of lintian, linda, and piuparts - warnings allowed, errors not. Maybe we would need one more buildd for i386 and one or two buildds for 'all', which does not have a buildd, AFAIK. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
Quoting Steve Langasek <[EMAIL PROTECTED]>: > code that's not portable, then I don't see any point at all in treating > these as release architectures to begin with, because at that point > they're *not* shipping the same OS that the other architectures are. Agreed, however, I would see "optional" packages, as, hm, optional. If for some arch an optional package doesn't build (or is impractical, like GNOME/KDE/OpenOffice for, say, m68k, IMHO) there is no problem. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Wouter Verhelst <[EMAIL PROTECTED]>: > According to stories I've heard from people from Ubuntu (that does it > this way), it quite clearly isn't, because of the pretty high number of > people who upload packages without even testing the build themselves. Of course, DDs will do better :-) > That doesn't test buildability. But it tests binary packages, so somehow those are built. One could also add the requirement of adding a build log to the test protocol. > Additionally, it's very easy to fake, because lintian and linda produce > _no_ output if you don't have warnings or errors... '-v'/'--verbose' could be hard-coded in the test script. People could always fake, forge, and fraud, but that's just an FTBFS. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>: > At doing stupid things, you mean :-( Our demographics do not allow > source-only uploads unfortunately. I don't really get this sentence, could you please re-word? (Sorry, I'm not a native speaker of English) > Which doesn't mean we can't simply trash the binary debs that are uploaded > and rebuild the package using a buildd, though. That would be at least much better than the current situation. Source-only uploads (with mandatory, signed build- and test-logs) would have the advantage of not having to upload large binaries. I have DSL - upload is ca. eight times slower than download here. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Thijs Kinkhorst <[EMAIL PROTECTED]>: > I dislike this idea: it is way overengineered. For starters I don't > understand why you would want to run both lintian and linda, since those I really don't care whether one has to run either lintian or linda or both. That's an implementation detail. If it's automised by a script, no maintainer ever has to care about it. > The whole certificates construction implies that people would want to > deliberately circumvent running lintian on their packages. I don't believe > there are a significant number of people doing that, and if they really > want to, they can do so anyway. > > If you really want to enforce lintian checks, you should run them > server-side. O wait, we already do that. IMO, that works just fine as it The idea of running lintian/linda and piuparts on side of the developer machine is giving a reasonable confidence, that a package is good enough for source-only upload. The log could be automatically signed with the .dsc. No burden to the DD. > does now; the results are visible for everyone. You could extend this to > running lintian for new uploads and rejecting them on errors if you would > so wish, but I do not see indications that this is actually necessary. AFAIK, you can run lintian/linda on binary packages. I was proposing source-only uploads. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>: > On Mon, 22 Aug 2005, W. Borgert wrote: > > I don't really get this sentence, could you please re-word? > > The current set of DDs will do unverified source uploads immediately if > given half a chance. Unverified binary uploads are rather common, already. Ah, understood :-) and agreed :-( (That's why I like Martins idea of mandatory, signed build and test logs.) Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Matthew Palmer <[EMAIL PROTECTED]>: > I used to think that too. I took a wander through queue/reject on merkel. > I don't think that any more. I'm curious as to how Ubuntu is going to > sustain source-only uploads, honestly. Mandatory, signed build and test logs? I've no idea... Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324296: ITP: ldapscripts -- Add and remove user and groups stored (using ldap)
Quoting "Roberto C. Sanchez" <[EMAIL PROTECTED]>: > Because the "user" is (99% chance) an admin. We should use debtags for this kind of information, IMHO. > Because the "user" may not want extraneous or extra Perl modules > installed on his system. If you are building a production box, you may > want to know. An admin user should be able to use the apt-get tools to check easily which dependencies etc. a package has. No need for prose, which might not be as accurate as the real dependencies anyway. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
Quoting Hamish Moffatt <[EMAIL PROTECTED]>: > There is the possibility that developer builds get extra features > enabled due to other installed libraries etc. This could be checked for > by analysing the packages files for different architectures or similar. This is a really nice idea: A DD with a strange sense of humour could "enable an extra feature" in their binary package, that is not in the source code - at least not in the uploaded source. Could be a virus, a Trojan horse, a root kit, a time-bomb. As >= 95% of our users have i386, it's easy to generate nice damage. Security-wise, binary uploads are no go. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only
Quoting Olaf van der Spek <[EMAIL PROTECTED]>: > Indeed. Why would those checks be done client-side instead of > server-side anyway? To prevent overload from the buildds. But maybe Martin Pitt is right, and we should just do it like Ubuntu (source-only uploads) and invent measures, if the need really arises. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Results of the meeting in Helsinki about the Vancouver proposal
On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote: > really matters: can we (the Debian project) maintain the port? Thus I > propose we only limit on the number of developers: are there people who > are willing and competent to maintain kernel, boot loader, platform > specific installer bits, libc and toolchain? That sounds sensible. > Furthermore, I think port maintainers should be much more aggressive to > exclude packages from being built on their port. For example (without ... > (discalimer: I only run x86 myself, so perhaps this is a stupid idea.) Same for me, so I like the idea. Any port should have to have essential and standard, optional is - optional. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
WebSVN of svn.debian.org uses wrong encoding
Hi, I have checked in some files into svn.debian.org. The files are in UTF-8 encoding[1], but the web front-end seems to believe in ISO-8859-1. Did I do something wrong when checking in files, or is WebSVN too plain in its assumptions? How/where can I file a bug, if the problem is in svn.debian.org? TIA! [1] http://svn.debian.org/wsvn/ddp/refcard/trunk/entries-ru.dbk?op=file (If WebSVN does not know about encodings, UTF-8 might be a more sensible default than ISO-8859-1 nowadays.) Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WebSVN of svn.debian.org uses wrong encoding
Quoting Frans Pop <[EMAIL PROTECTED]>: > WebSVN does not know about the contents of files in the repository period. OK. > As it is just a frontend to svn, you cannot expect it to know about every > weird file format and encoding around. OK. > IMO, the main purpose of websvn is to be able to view diffs in _code_ and > maybe download individual files. I handle documentation like code :-) > For everything else, use svn itself and work with its files in their > proper environment. Not all of "my" translators are easy with svn command line. WebSVN would be helpful, so they see, whether I did my homework and checked in their latest changes correctly. Could be useful for d-i, too. > If you really want to file a bug about it, the Tech Support Tracking > System for project alioth on alioth is probably your best bet, but I > doubt that is really useful. I did this anyway :-) > Food for endless flames^Wdiscussions. As nearly everything :-( Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WebSVN of svn.debian.org uses wrong encoding
Quoting Frans Pop <[EMAIL PROTECTED]>: > For that you should enable the svn keyword "Id" (using 'svn propset > svn:keywords Id') and add a comment in your English files containing > "$Id:". I will do that, thanks for the hint! (However, my original plea for using UTF-8 in WebSVN remains.) Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update of (several) config files
Hello Tomas, this question should better go to [EMAIL PROTECTED] Quoting Tomas Davidek <[EMAIL PROTECTED]>: > I am trying to set up a tool for easy update of several computers in > our institute. For example, I would like to create a package that > updates several config files, e.g. /etc/apt/sources.list etc. > What is the best way of doing that ? It depends very much on your needs. For simple cases look into cfengine/cfengine2 (I do not like cfengine, but there is no alternative). For really cool stuff look at FAI (fully automatic install), which has some system update features. At the list mentioned above you will get better information. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WebSVN of svn.debian.org uses wrong encoding
Quoting Christian Perrier <[EMAIL PROTECTED]>: > Several translation teams (including mine) still use Latin-1 as their > default...but this is not a reason to still use Latin-1 as an overall > default...:-) Btw. I looked into the d-i manuals in SVN and some Western European languages, e.g. German, are already in UTF-8. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Results of the meeting in Helsinki about the Vancouver proposal
Quoting Peter 'p2' De Schrijver <[EMAIL PROTECTED]>: > Most packages are not tested automatically at all. Unfortunately not. > Most cross compiled software also runs 24/7. I have yet to see problems > produced by cross compiling the code. ... > I don't think the risk is real considering the amount of cross compiled > software already running in the world. Yes. In "my" company we rely heavily on cross-compilation, because our target environment is not (meant to be) self-hosting. There is absolutely no problem in terms of stability, that is related to the cross-compilation. Sometimes we ran into gcc bugs, but those were not only in the cross cc. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
Quoting Robert Lemmen <[EMAIL PROTECTED]>: > 1. just make it public (after a warning period), anybody who doesn't >want that can delete his information from the database. my preferred >option! I don't like opt-out. Better opt-in: 4. Invent a new field "public location info" and developers who care, could enter what they think is appropriate. I'm not sure, whether I would use the field. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
On Thu, Aug 25, 2005 at 07:39:08PM +0200, Robert Lemmen wrote: > anyway, i did get your point: you would very much wish for that > information to stay non-public unless one explicitely makes it public. Yes, please. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
Quoting Javier Fern�ndez-Sanguino Pe�a <[EMAIL PROTECTED]>: > presents themselves and suggest meeting for a beer. They don't walk to > your house, knock on your door and say "Hi! I just got your coordinates > from db.debian.org, wanna meet and keysign?". And I wouldn't want that. I do not understand this discussion. Why on earth is someone so interested in the public availability of DDs location? This would only make sense when cross-connecting with other things, like belief, gender, sexual preferences and phantasies etc. Are those fields of db.debian.org already public or not? Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325164: ITP: docbook-css -- Cascading Stylesheet for DocBook/XML
Package: wnpp Severity: wishlist Owner: "W. Borgert" <[EMAIL PROTECTED]> Package name: docbook-css Version : 0.4 Upstream Author : David Holroyd URL : http://www.badgers-in-foil.co.uk/projects/docbook-css/ License : "free to use/modify/distribute, no warranty" Description : view DocBook/XML files styled in the web browser This Cascading Stylesheet allows you to directly view a styled XML document in software that supports XML styled with CSS2 (e.g. a recent Mozilla browser). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why does "vbetool dpms off" work and "xset dpms *" not?
Quoting Bastian Venthur <[EMAIL PROTECTED]>: > Hi devels, > > I'm trying to get my backlight powered off in order to save power. It does ... This question should probably go to [EMAIL PROTECTED] Good luck! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
On Mon, Sep 19, 2005 at 10:45:26AM +0930, Debonaras Project Lead wrote: > The Debonaras project (http://www.debonaras.org) is a group of Linux > developers who have created the beginnings of a big-endian ARM (armeb) > port of Debian. We have built 2500+ stable packages so far (see > http://ftp.debonaras.org). Just a completely uninformed question: Wasn't the -el (endian little) in mipsel a pun on the "wrong" endianess? If so, shouldn't it be armBE, because it's the "right" endianess? Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
Quoting Thiemo Seufer <[EMAIL PROTECTED]>: > -EL/-EB/-el/-eb are commonly used gcc switches to select endianness. OK, thanks. Another mystery solved :-) Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
Quoting Sam Hocevar <[EMAIL PROTECTED]>: >Wrong is endian little that knows everyone but. Thgir yltcaxe! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture-specific release criteria - requalification needed
Quoting Andreas Barth <[EMAIL PROTECTED]>: > * Ingo Juergensmann ([EMAIL PROTECTED]) [050921 16:53]: > > What about such ports like m32r? Some embedded devices might run that port, > > but the user doesn't even know about which arch he's using nor that he's > > using Debian and certainly not that he is intended to give a "hey, i'm using > > that port" message to Debian... > > Well, it doesn't necessarily be the user himself. But if a port is only > used on embedded devices, the question arrises if it is necessary to > include that port in testing and stable. 1. If the user theirself don't know about using Debian on the embedded device, I'm sure that someone knows about the fact and can easily provide information about it. E.g. we all know about the Nokia 770 arm machines. If we can believe that Nokia sold more than fifty gadgets, the goal is reached. 2. Even for embedded systems, stable releases are a good thing. (Easier to follow GPL rules of having sources available for some years. Easier to build/install additional software, if one knows, which Debian release is used. Easier to clone.) Btw., IMHO, the new release criteria are very sensible, maybe with the exception of the 98%-rule, which might be too strict. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
planet.debian.org vs. blog illiteracy
Hi, I found out, that more and more important information about Debian development are on the planet.debian.org/.net website. I'm illiterate on "blogging", so please could someone tell me whether/how I can view this page in a "Debian only" mode? E.g. without vacancy travel reports, personal opinions on all kind of political issues, or other private stuff? (I would prefer to get all the technical information on debian-devel, but of course this is up to the posters.) TIA! -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.org vs. blog illiteracy
Quoting Andreas Tille <[EMAIL PROTECTED]>: > Thanks for this hint - I just skipped this thread because I regarded > it relevant for blogs (and thus not for me). But I do not really want > a new list - I just want technical information neither spread to debian-devel > and planetdebian nor debian-devel and an assumed debian-planet mailing list. > I just want it here were it belongs. It seems that some of the blog writers think that the respective information belong to the blog and not to debian-devel :-( Maybe there is an easy way (tool-wise) for the blog authors to automatically duplicate entries of technical relevance to the list? IMHO, the blog has some drawbacks: - offline reading is difficult - answering to questions difficult (not as easy as pressing 'r'eply or 'g'roup reply in mutt) - not archived (or is it?) - valuable technical contents mixed with weather reports (low SNR) So please, fellow DDs, if you have important information, share it via the list, too! Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.org vs. blog illiteracy
Quoting Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>: > Use rss2email. It makes blogs almost as useful as maillists. Sounds OK, but it would be more convenient to just have all relevant (= technical) information in debian-devel. > Right, that's a real disadvantage. Everyone knows that debian-devel has > an extremly high SNR, right? :-) At least it is easier to cope with the noise by procmail and ^D (delete-thread in mutt) and there's no talk about the weather. Noisy WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.org vs. blog illiteracy
Quoting Margarita Manterola <[EMAIL PROTECTED]>: > I think that this is part of the essence of blogging. When you write > a mail to debian-devel you risk being flamed about whatever you are > saying. When you blog about it, it's your right to say what you think > and feel like. People managed to start flamewars on their blogs :-) So one has to be fireproof anyway. For me, as a poor reader, it is harder to follow, as there is no equivalent to a mail thread. > Besos, Cheers, Wolfgang (lowering the SNR of this in this very moment) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.org vs. blog illiteracy
On Mon, Sep 26, 2005 at 12:35:36PM -0700, Daniel Burrows wrote: > I generally don't see any value in cluttering up -devel with the stuff I > post on my blog. I hope people who read it will find it interesting, but > it's not broadly important and I don't think there's any need to annoy large > numbers of people by sending it here. :) In the past, there were important blog entries by Martin Joey Schulze on security, by Branden Robinson on Debian trademark issues, and some interesting thoughts on the upload process by Martin F. Krafft to name just a few. I'm pretty sure, that I found some of your entries informative as well :-) Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: i386-uclibc debian
On Wed, Sep 28, 2005 at 12:12:33PM -0300, Daniel Ruoso wrote: > What do you think? I would like to see a d-i port to that architecture! (not volunteering, sorry) Did you contact the emdebian people? Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: old question with new status? Sun-Java in Debian non-free?
Quoting Jason Clinton <[EMAIL PROTECTED]>: > If so, what can I do to take the initiative to package it up for Debian > non-free? > > I apologize in advance if this brings up an old flame war... I don't expect one about this issue. Just don't expect Debian to join any "Partner Programme", which seems to be necessary. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: real-i386 (was Re: i386 requalification for etch)
On Sun, Nov 06, 2005 at 12:10:05PM +0100, Andreas Metzler wrote: > I am a little bit confused. Does Via/C3 need strict 386-instructions > or does it play nicely with the current status, i.e. 486 instruction > set? A standard sarge install works perfectly on my brand-new VIA C3. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463069: ITP: refcard -- printable reference card for the Debian system
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" <[EMAIL PROTECTED]> Package name: refcard Version : 3.2 Upstream Author : W. Martin Borgert <[EMAIL PROTECTED]> URL : http://people.debian.org/~debacle/refcard/ License : GPL-3 Programming Lang: XML (docbook-xsl, FO) Description : printable reference card for the Debian system The Debian GNU/Linux reference card provides new users help with the most important commands. Basic knowledge of computers, files, directories and the command line is required, however. The package contains printable PDF files in multiple languages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Official presentation template
On Wed, Jun 27, 2007 at 02:32:56AM +0200, Javier Fernández-Sanguino Peña wrote: > Oh, and if a design was settled, it would be really nice to have the design > implemented in some other presentation toolkits (besides beamer) such as OO's > impress or Kpresenter. For the benefit of those that do not like LaTeX (I'm > not one of them :) I like LaTeX, but I use DocBook XML slides as source and S5-HTML as output for presentations. I have a simple debianesque CSS, I can share. Cheers, -- W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Source only uploads?
Hi, a few days ago, I uploaded an emacs mode package (all) source only w/o problems to ftp-master. Today, a source only upload was rejected. Why? I think, we should get rid of binary uploads... Cheers!
Kernel 2.6.x real time clock hang on Dell
Hi, I'm bitten by a problem, that is already known to some people, but for which I found no solution. On a Dell server, the 2.6.7 kernel (kernel-image-2.6.7-1-686-smp) hangs during boot at the real time clock. It seems, this problem is only known to Debian users :-( Is there a solution or a workaround? "I have problem on a Dell Precision 670. I have installed the kernel 2.6.8 using the debian Sarge net installation. The boot hangs after loading the driver for the Real Time Clock." http://www.linuxquestions.org/questions/showthread.php?s=&postid=1188223#post1188223 "...always hang on the "Real Time Clock Driver". I figured it a bug in the 2.6 kernel..." http://zacbowling.com/archives/2004/10/06/debian-dell/ Thanks in advance! Cheers, WB
Bug#126775: omniorb-doc examples don't compile
Package: omniorb-doc Version: 3.0.4-2.4 Tags: patch I have adopted the examples to autoconf/automake. This works very well. Maybe one can push this to the upstream developers? What I did: All files dir.mk, dir.mak, GNUmakefile, *.module, *.pkg, and the obsolete directories lifecycle and partcl are removed. They are replaced by a configure.ac, a dozen Makefile.am files and a bootstrap script to run aclocal, automake and autoconf. Two minor problems remain: 1. I put -DUsePthread directly into the Makefile.am files. Better would be to check for the pthread libs. 2. As suggested by the omniORB documentation, I have created a file /usr/include/omniORB3/sitedef.h, which contains only one line: #define __x86__ /* or: __sparc__, __powerpc__, ... */ This file is included by /usr/include/omniORB3/\ CORBA_sysdep.h mainly to set _OMNIORB_HOST_BYTE_ORDER_ to 0 for big endian machines and to 1 for little endian machines. I don't like this. It makes cross compiling impossible. Also, autoconf already has a macro AC_C_BIGENDIAN, which defines WORDS_BIGENDIAN or not depending on the byte sex. Btw: I believe that the bugs #49037 (omniorb-doc file placement, 2 years and 58 days old) and #114718 (empty dirs in omniorb-doc, 82 days old) are gone. Cheers, -- W. Borgert <[EMAIL PROTECTED]> diff -ruN examples.orig/Makefile.am examples/Makefile.am --- examples.orig/Makefile.am Thu Jan 1 00:00:00 1970 +++ examples/Makefile.amFri Dec 28 20:09:05 2001 @@ -0,0 +1 @@ +SUBDIRS=anyExample boa call_back dii dsi echo poa thread diff -ruN examples.orig/anyExample/Makefile.am examples/anyExample/Makefile.am --- examples.orig/anyExample/Makefile.amThu Jan 1 00:00:00 1970 +++ examples/anyExample/Makefile.am Fri Dec 28 20:45:32 2001 @@ -0,0 +1,11 @@ +IDLFILE = anyExample +noinst_PROGRAMS = anyExample_clt anyExample_impl +BUILT_SOURCES = anyExampleSK.cc anyExampleDynSK.cc anyExample.hh +anyExample_clt_SOURCES = anyExample_clt.cc $(BUILT_SOURCES) +anyExample_impl_SOURCES = anyExample_impl.cc $(BUILT_SOURCES) +LDADD = -lomniORB3 -lomniDynamic3 -ltcpwrapGK +CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread +CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh + +$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh: $(IDLFILE).idl + $(OMNIIDL) -bcxx -Wba $< diff -ruN examples.orig/boa/Makefile.am examples/boa/Makefile.am --- examples.orig/boa/Makefile.am Thu Jan 1 00:00:00 1970 +++ examples/boa/Makefile.amFri Dec 28 20:46:07 2001 @@ -0,0 +1,11 @@ +IDLFILE = becho +noinst_PROGRAMS = eg2_clt eg2_impl +BUILT_SOURCES = bechoSK.cc becho.hh +eg2_clt_SOURCES = eg2_clt.cc $(BUILT_SOURCES) +eg2_impl_SOURCES = eg2_impl.cc $(BUILT_SOURCES) +LDADD = -lomniORB3 -ltcpwrapGK +CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread +CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh + +$(IDLFILE)SK.cc $(IDLFILE).hh: $(IDLFILE).idl + $(OMNIIDL) -bcxx -WbBOA $< diff -ruN examples.orig/bootstrap examples/bootstrap --- examples.orig/bootstrap Thu Jan 1 00:00:00 1970 +++ examples/bootstrap Fri Dec 28 17:22:47 2001 @@ -0,0 +1,4 @@ +#!/bin/sh + +aclocal && automake --add-missing --foreign +autoconf diff -ruN examples.orig/call_back/Makefile.am examples/call_back/Makefile.am --- examples.orig/call_back/Makefile.am Thu Jan 1 00:00:00 1970 +++ examples/call_back/Makefile.am Fri Dec 28 21:11:12 2001 @@ -0,0 +1,12 @@ +IDLFILE = echo_callback +noinst_PROGRAMS = cb_client cb_server cb_shutdown +BUILT_SOURCES = echo_callbackSK.cc echo_callback.hh +cb_client_SOURCES = cb_client.cc $(BUILT_SOURCES) +cb_server_SOURCES = cb_server.cc $(BUILT_SOURCES) +cb_shutdown_SOURCES = cb_shutdown.cc $(BUILT_SOURCES) +LDADD = -lomniORB3 -ltcpwrapGK -lomnithread -lpthread +CXXFLAGS = -O2 -Wall -Wno-unused -D__OMNIORB3__ -D_REENTRANT -DUsePthread +CLEANFILES=$(IDLFILE)SK.cc $(IDLFILE)DynSK.cc $(IDLFILE).hh + +$(IDLFILE)SK.cc $(IDLFILE).hh: $(IDLFILE).idl + $(OMNIIDL) -bcxx $< diff -ruN examples.orig/configure.ac examples/configure.ac --- examples.orig/configure.ac Thu Jan 1 00:00:00 1970 +++ examples/configure.ac Fri Dec 28 20:22:23 2001 @@ -0,0 +1,28 @@ +AC_INIT(anyExample/anyExample_clt.cc) +AM_INIT_AUTOMAKE(omniorb-examples, 3.0.4) + +AC_PROG_CXX +AC_PROG_CXXCPP +AC_PROG_LN_S +AC_PROG_INSTALL + +AC_LANG(C++) +AC_HEADER_STDC +AC_CHECK_HEADERS(iostream.h omniORB3/CORBA.h omniORB3/callDescriptor.h omniORB3/tcDescriptor.h) + +AC_C_BIGENDIAN + +AC_CHECK_PROGS(OMNIIDL, omniidl, false) + +AC_OUTPUT(Makefile + anyExample/Makefile + boa/Makefile + call_back/Makefile + dii/Makefile + dsi/Makefile + echo/Makefile + poa/Makefile + poa/implicit_activation/Makefile + poa/persistent_objref/Makefile + poa/servant_manager/Makefile + thread/Makefile) diff -ruN examples.orig/dii/Makefile.am examples/dii/Makefile.am --- examples.orig/dii/Makefile.am
Intent to package: blinkd
Hi, I will upload blinkd, a small client/server pair, that let's blink your keyboard LEDs (numlock and scrolllock) in a rate that signals e.g. the number of incoming calls on your voice box or number of facsimiles in the spool. The software is written by myself and GPLed. This is my first deb, if everything is O.K. more packages will follow... Bye, -- W. Borgert <[EMAIL PROTECTED]> pgpo2CC9pVm59.pgp Description: PGP signature