Bug#60917: Request for NMU (console-tools)
About Bug#60917: I cannot upload a fixed version now. FIX: * replace the preinst code quoted in the report by the following (please test it first). Note that it uses evil "Press RETURN"s in case something is probably broken. = if [ -d /usr/local/share/keytables ] then if [ -d `readlink -f /usr/local/share/keymaps` ] then mv /usr/local/share/keytables/* /usr/local/share/keymaps rmdir /usr/local/share/keytables elif [ -e /usr/local/share/keymaps ] then echo >&2 "/usr/local/share/keymaps is buggy - please check it" ls -ld /usr/local/share/keymaps >&2 echo >&2 "Press RETURN to continue" read else mv /usr/local/share/keytables /usr/local/share/keymaps fi elif [ -e /usr/local/share/keytables ] then echo >&2 <= 1.13.1), as advertised in the readlink(1) manpage. Testing: install the package several times, in each of the following cases: 1. /usr/local/share/keytables/ is a dir and 1a. /usr/local/share/keymaps is a dir => should move subdirs 1b. /usr/local/share/keymaps is a special file (mknod(1) it) => should complain 1c. /usr/local/share/keymaps does not exist => should move dir 2. /usr/local/share/keytables/ is a special file => should complain * maybe apply the rules in "Filesystem hierarchy"/"Site-specific programs" of the policy (create and remove /usr/local dirs from postinst/prerm), but I don't know if this should really be done for potato, better leave this for woody. -- Yann.
Re: RFC: debhelper v2
About debian/tmp and friends: something I'd like would be to run make install on some dir like debian/INSTALL/, and have dh_movefiles take files from this one. This would provide greater consistency between binary packages (get rid of this concept of "main package"), and simplify things when moving some files from an "Arch: any" to an "Arch: all" package (no need to change debian/rules lines, just move them). -- /\ Yann Dirson<[EMAIL PROTECTED]> \\ \ \ \\ / Sun Microsystems Inc. <http://www.sun.com/> / \/ / /Consumer and Embedded / ChorusOS Support / / \//\ \//\ / / Phone: +33 139 44 74 50 / / /\ /Phone: 44450 / \\ \ \ \\ \/ Subcontractant from Logatique <http://www.logatique.fr/>
libdb[12] not DFSG-free ?
The http://www.sleepycat.com/packages/ URL in the debian/copyright in db2.diff seems to be outdated. When looking at http://abyssinian.sleepycat.com/db/ we MUST provide personal information (.../register.pl) in order to gain access to the package. -- Yann Dirson <[EMAIL PROTECTED]>
Re: How to automatically update files on alioth from svn
Frank wrote: > I'd like to keep the files in the "Project Home Page" area of alioth in > our SVN repository, and I'm looking for a way to automate the updating > of these pages. I have written a small post-commit hook for a somewhat different usage (the original problem was versionning the hooks themselves). It can surely be improved (eg. by only running "svn update" when the commit impacts the relevant part of the svn tree, like the gcc guys did in their own script). It only checks out (update, indeed) in a local directory, but it could probably be modified to have the "svn update" command run through ssh on the other machine. You will find it at http://ydirson.free.fr/soft/svn/svn-auto-checkout Documentation included in leading comments. > Ideally, we would use some post-commit hook that causes the changed html > file to be uploaded from svn.debian.org to alioth.debian.org, but I see > two problems: > > - how to write the hook so that only specific files are uploaded, and > put into the right location Those are the 2 parameters to the script. > - how to authenticate the transfer, since the svn repository and the > webspace is on different machines. https or svn+ssh to access the repo should provide the level of authentication you need, or do I miss something ? HTH -- Yann Dirson<[EMAIL PROTECTED]> | Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/| Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sysvinit and System.map (Was: dangling symlink System.map)
Guy Maor writes: > Yann Dirson <[EMAIL PROTECTED]> writes: > > > Don't know either. But it's been some time I wonder why this link > > isn't updated on boot to point to "boot/System.map-`uname -r`", or > > suppress the link and issue a warning if the latter is absent. This > > would ensure correctness, I think. > > That's not necesary as all the necessary programs will look for > System.map-version also. Then this link is useless... some base package should get rid of it, and we should make sure it never comes to the surface again ? BTW, psupdate is the only program I can think about using System.map. Are there any other ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Rob Browning writes: > I guess I was looking for -ko, since you wouldn't want to be rewriting > the $Id$ values for the upstream source unless you actually changed > things, and even then it's kind of iffy since your tree has nothing to > do with theirs. In addition, without -ko, you'd get a bunch of > spurious diffs against the upstream source. I don't how how to do that, but some people use their own keyword instead of $Id$. You'll find $XConsortium$ all around X11 code, I think; I already saw another such keyword, but can't remember where. I found nothing in the doc when I looked for it last year. On last resort, a specially-compiled CVS could be used ? Maybe we could use a $DebianId$ ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Alexander Koch writes: > ~ # init > Usage: init 0123456SsQqAaBbCc > > 1 is already multiuser, no networking (iirc). > single-user is S or s (just like using the single as argument for lilo)! > 2 is networking (basic, inn comes up etc) > 3 is full networking (whatever you desire) > 4 and 5 is to be filled with xdm (x) (for those who desire) > 6 is reboot > > Did I get anything wrong? * I think you at least missed something: runlevel 1 is a temporary one, and automatically switches to S. I think you should never ask 'telinit S', but 'telinit 1' * that's not complete either. As already mentionned, the manpage tells about undocumented runlevels 7-9. It also poorly tells about those AaBbCc I never really understood. More about these ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Taking over e2fsprogs ?
To Michael: Has anybody postulated to take over maintainance of the package ? If not, I'm a volunteer... Please let me know. Regards, -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Yann Dirson writes: > * that's not complete either. As already mentionned, the manpage tells > about undocumented runlevels 7-9. It also poorly tells about those > AaBbCc I never really understood. I just tried those runlevels 7-9, with sysvinit_2.71-2. It just need few modifications to have them work: * add rc[7-9].d, and 'cp -d rc2.d/* rcX.d' to get packages setup * add in inittab: runlevel (l7,l8,l9) entries, 7-9-awareness into getty and ctrl-alt-del entries (entries 1-6 and ca) There would surely be other things to update if they are to be used in debian (eg. update-rc.d). That just go fine, until you try to use 'halt' or 'reboot': as specified in the manpage (yes :), these only call shutdown when in runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it, it (probably among other unclean things) doesn't unmount cleanly filesystems. I don't know the reason why RLs 7-9 are handled just like 0 and 6. I think it should at least be possible to choose which behaviour they have in this case, if the current behaviour is meaningful (IMHO, it is only meaningful for halt/reboot-like actions). Should this be considered as a bug ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over e2fsprogs ?
Tom Lees writes: > On Wed, 28 May 1997, Yann Dirson wrote: > > > > > Has anybody postulated to take over maintainance of the package ? If > > not, I'm a volunteer... Please let me know. > > If you do take it, please try to get the e2compr patches into it. I have > requested that I take it to do this work on it. However, e2compr-ised > patches are only available against 1.06 - they will need some converting. ACK. I'll have a look at that when I'm familiar enough with the package. -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
locale errors
Erv Walter writes: > The locale errors are getting extremely annoying. What is the most > correct way to solve the problems. unsetting LANG solves the problem, > but I can't find where it is getting set in the first place. That's > not the most elegant solution anyway. [...] > Note: There are similar error from other programs (emacs, etc). This > becomes particularly annoying when installing new packages (which > calls perl many times in a row). ...and this is EXTREMELEY unpleasant when, using debian-changelog-mode in emacs, "finalize-version" inserts these error messages from perl in the buffer !!! -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
Enrique Zanardi writes: > As elf.h is unrelated to libelf in Linux systems (I don't know > about it in SVR4 or Solaris, from where that library was ported), > this test is broken for Linux. Don't know about these systems, but HP-UX 9.x had a similar problem, having a efl.h file, without necessarily the library installed. I think I reported this bug between 1 and 2 years ago to the autoconf upstream maintainers, but can't be sure anymore :) -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
Nicolás Lichtmaier writes: > On Mon, 23 Jun 1997, joost witteveen wrote: > > > > That would be enable the WWW pages to mark the new packages with a > > > `[NEW!]'. > > > It look a silly feature, but I think that it would be very useful to > > > users. Other package management utilities can take advantage of this > > > field > > > too... > > But at the moment the file modification date on most mirrors reflects > > the "Entered-Date" quite accurately. > > Yeah..! How did I miss that?? =) I think you should still consider to add this field into Packages.gz: this will allow the information to find its way down to your (our) debian-machines, when upgrading through FTP. -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
James R. Van Zandt writes: > There is an alternative I think we should consider. Let each binary > package include both .info and .html files. Give dpkg two additional > switches --no-html and --no-info which would be used with -i. These > would cause dpkg to immediately remove /usr/doc/foo/*html or any files > installed in /usr/info, respectively. Diety could still manage the > sysadmin's preferences, but the only effect would be to add the above > switches to the dpkg command line. If the sysadmin changes his mind, > he could simply reinstall the binary packages. > > This had the disadvantage of taking up more space on the mirrors and > CDROMs -- there is a copy of the documentation in the binary package > for each architecture. However, I think it would be much simpler to > implement and administer. This is IMHO definitely inacceptable: you forget network bandwidth, and phone communications to ISP for users (eg. french) who still have to pay for local calls :( -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Mark Eichin writes: > > > /usr/info/emacs-info. I suggest to split this off into a new package > > called "emacs-doc-info". In addition, we should create an "emacs-doc-html" > > Interesting. Not really an option, though; as far as emacs is > concerned, that's part of how it documents itself. [...] > This html/info split may make sense for other packages (I'm > unconvinced) but it does *not* make sense for emacs in particular. This could probably be worked around by making `emacs' Recommend:ing `emacs-doc-info', aknowledging emacs' priviledged relation towards info, while still allowing sysadmins to just install HTML on their own mono-user PCs. -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Bruce Perens writes: > From: Philip Hands <[EMAIL PROTECTED]> > > I think we should aim to get all documentation into separate packages. > > Please don't do this. Deity will have the capability to exclude installation > to certain directories (like /usr/doc) based on a system "policy file". > Packages should always contain the documentation for their programs in > at least "HTML" or "man" form. Omitting the documentation should be the > exception, not the rule. I must disagree here. Here's a summary of the main reasons why I do so: * it will cost bandwidth when you just want to install either binary-only or doc-only, using FTP * further more, it will cost money to users as pay for local calls, here in France * it will cost disk-space on mirror sites, as debian will probably support in a quite short term all 6 (soon 7 ?) kernel-supported architectures. Further more, docs are definetely architecture independant files! Please support me, someone :) Regards, -- Yann Dirson <[EMAIL PROTECTED]> http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Philip Hands writes: > There is of course a problem with trying to install all the documentation on > a > machine, since some conflicting packages provide man pages with overlapping > names. I think that the 'alternative' mechanism could be used there. -- Yann Dirson <[EMAIL PROTECTED]> http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
Hi all of you... I've just been reading this (quite old for now) thread. What's the status of the discussion now ? Has there been some new feeback from other groups ? -- Yann Dirson <[EMAIL PROTECTED]> http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
Greg Stark writes: > > We've got be be a little more careful with the Replaces header. I just > installed the libc6 version of comerr, and dpkg helpfully deinstalled > e2fsprogs. That's perfectly normal if you previously had e2fsprogs <= 1.10-6, which does contain libcom_err ! You should probably install e2fsprogsg to replace e2fsprogs. > dpkg: considering removing e2fsprogs in favour of comerr2g ... > dpkg: yes, will remove e2fsprogs in favour of comerr2g. > (Reading database ... 17790 files and directories currently installed.) > Unpacking comerr2g (from .../base/comerr2g_1.10-8.deb) ... -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
Scott K. Ellis writes: > BTW, is there a particular reason that e2fsprogs got renamed to > e2fsprogsg? This seems to be the biggest chance to completely screw over > someone's system in all of Debian now. Yes: e2fsprogs used to contain shared libs, on which dump and quota depend. Thus, e2fsprogs was assumed to be a package with libc5 libs, and I could not keep the name, without breaking dump and quota on a hamm upgrade. I thought that, e2fsprogsg being essential, would be flaged for installation as soon as it appears in the available packages. Is this not the case ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Mailinglists documented
Martin Schulze writes: > Good evening folks, [...] > All the mailing lists that are served on lists.debian.org are now > documented in one file and this should reflect their actual state. One nice thing would be to document a way for anyone to know which debian lists he's currently subscribed to. Is there such a mechanism, or is there only this stuff (what's its name, anyway ?) to be run on master to get the info ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
Scott Ellis writes: > Nope, didn't seem to be flagged for install on my end. I would have > suggested keeping the same name and conflicting with the versions of dump > and quota that would have depended on the libraries. OK. I think I'll change the name back to "e2fsprogs", and just make it conflict with old "dump" and "quota" packages. There's not much chances anybody else will complaint, except for people having build local packages depending on it. Anyone has objections to this ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: (fwd) cutils version 1.5.2 - C language miscellaneous utilities
Hamish Moffatt writes: > ctangle and cweave - simple literate C programming tools These are already part of the "cweb" package. If there're different, you may use alternatives ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
WARNING (Was: Uploaded e2fsprogs 1.10-9)
I had some problems with the dependency mechanism, which ended in a quite puzzling situation when upgrading from 1.10-7 to 1.10-9. Although I may just have done some error myself, I think there may be a problem in the way dpkg handles such a "complex" upgrade. I guess it would present a similar problem when upgrading from bo. Here are how the deps are set up: 1.10-9 Package: comerr2g Version: 1.10-9 Essential: yes Depends: libc6 Conflicts: e2fsprogs (<< 1.10-6), comerr2 Replaces: e2fsprogs (<< 1.10-6), comerr2 Package: e2fslibsg Version: 1.10-9 Essential: yes Depends: comerr2g, libc6 Conflicts: e2fsprogs (<= 1.10-7) Provides: ss2g, ext2fs2g, e2p2g, uuid1g Replaces: e2fsprogs (<= 1.10-7) Package: e2fsprogs Version: 1.10-9 Essential: yes Depends: comerr2g, e2fslibsg, libc6 Conflicts: e2fsprogsg Provides: e2fsprogsg Replaces: e2fsprogsg 1.10-7 Package: comerr2 Version: 1.10-7 Depends: libc5 (>= 5.4.0-0) Package: e2fsprogs Version: 1.10-7 Essential: yes Pre-Depends: comerr2, libc5 (>= 5.4.0-0) Provides: ss2, ext2fs2, e2p2, uuid1 Here is the log for a sample upgrade from 1.10-7 to 1.10-9: [Note that I removed all references to -dev packages in the logs to clean them up] * first pass: - selected (from dselect) e2fsprogs and new libs for install, old libs for remove. - only e2fslibsg can cause e2fsprogs to be deconfigured; it is even removed !! ~/trav/deb/local[595]$ debpkg -iGREOB ../*1.10-9*deb dpkg: considering removing comerr2 in favour of comerr2g ... dpkg: no, e2fsprogs is essential, will not deconfigure it in order to enable removal of comerr2. dpkg: regarding ../comerr2g_1.10-9_i386.deb containing comerr2g: comerr2g conflicts with comerr2 comerr2 (version 1.10-7) is installed. dpkg: error processing ../comerr2g_1.10-9_i386.deb (--install): conflicting packages - not installing comerr2g dpkg: considering removing e2fsprogs in favour of e2fslibsg ... dpkg: yes, will remove e2fsprogs in favour of e2fslibsg. (Reading database ... 38897 files and directories currently installed.) Unpacking e2fslibsg (from ../e2fslibsg_1.10-9_i386.deb) ... Skipping deselected package e2fsprogs. dpkg: dependency problems prevent configuration of e2fslibsg: e2fslibsg depends on comerr2g; however: Package comerr2g is not installed. dpkg: error processing e2fslibsg (--install): dependency problems - leaving unconfigured Errors were encountered while processing: ../comerr2g_1.10-9_i386.deb e2fslibsg * second pass: - now that old e2fsprogs is not there any more, the libs install smoothly, but dpkg seems to have decided to keep away e2fsprogs, which is essential ! ~/trav/deb/local[596]$ debpkg -iGREOB ../*1.10-9*deb dpkg: considering removing comerr2 in favour of comerr2g ... dpkg: yes, will remove comerr2 in favour of comerr2g. (Reading database ... 38872 files and directories currently installed.) Unpacking comerr2g (from ../comerr2g_1.10-9_i386.deb) ... Preparing to replace e2fslibsg 1.10-9 (using ../e2fslibsg_1.10-9_i386.deb) ... Unpacking replacement e2fslibsg ... Skipping deselected package e2fsprogs. Setting up comerr2g (1.10-9) ... Setting up e2fslibsg (1.10-9) ... * third pass: At last, all gets installed. ~/trav/deb/local[599]$ debpkg -iE ../*1.10-9*deb (or re-select using e2fsprogs using dselect, and use -iGREOB to emulate what dpkg-ftp does) Version 1.10-9 of comerr2g already installed, skipping. (Reading database ... 38873 files and directories currently installed.) Version 1.10-9 of e2fslibsg already installed, skipping. Unpacking e2fsprogs (from ../e2fsprogs_1.10-9_i386.deb) ... Setting up e2fsprogs (1.10-9) ... -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How to detach debug symbols from libraries
Fabrizio Polacco writes: > Hi folks! > > I remember someone suggesting to tetach debugging symbols from libraries > to package them separately on a -dbg binary package. I think the -dbg package contain the unstripped libs, and not only the symbols. There would be a way of separately providing the symbols (for gdb at least), but the last time I tried, it wasn't supported on i386. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress: 1997-12-12
Richard Braakman writes: > James LewisMoss <[EMAIL PROTECTED]>: > xemacs20-20.2-4 (Mixed dependencies; waiting for libcompface?) > xemacs19-19.16-1 (Mixed dependencies; waiting for libcompface?) libcompface has already been converted. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Taking over tkman
If noone objects, I'll take tkman. The version we have seems to be obsolete since August. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Adam P. Harris writes:
> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
>
> This would allow, for instance, MTA packages to ship little scripts to
> flush the mail queue when the link comes up, pop-deamons to start up,
[...]
I had the idea of adding such actions (flush mailqueue, fetch mail,
etc.) to my ip-up, but I didn't do that.
This is because some of these actions (eg. mail fetching) may be quite
long to complete, and may act badly if interupted by a 'poff'
(eg. fetched messages from the interupted session not erased from my
POP account - guess it's a security feature in fetchmail).
The solution I used was to manually ask to fetch my mail. Another
would be to have a (hopefully generic) mean of forcing the line to
stay up while such an action is taking place. But I'm not sure it
would be a good solution either, since fetching 200 mails/day from the
debian lists takes some time, and then the user would be compelled to
want till fetch is done.
In other words:
* we can't decide for the sysadmin what actions will take place on
boot.
* if we build such a system, a standard way of disabling parts of
these directories (maybe like what /etc/init.d/rc allows with 'S' and
'K' names ?)
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 |
-
A computer engineer's looking for a job !
-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: How to detach debug symbols from libraries
Fabrizio Polacco writes: > Yann Dirson wrote: > > Problem: it's really a mmap image (thus works only for executables, > > not libs), and includes the libs symbols: > > > > But the real problem is that the sizes are ... unmanageable > the shared lib is half the size of the static one, while the .syms file > is double! > -rw-r--r-- 12242044 Dec 13 19:20 libdb2.a > -rwxr-xr-x 11129332 Dec 13 19:18 libdb2.so > -rw-r--r-- 15246976 Dec 15 13:26 libdb2.so.syms Does gdb reads in the libs yours depends on ? This might explain that... > So I loose all interest in using .syms files instead of unstripped > static libs. OK. Did you try objcopy(1) ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: options for menu packages
Avery Pennarun writes: > I see a couple of problems with this. First, "-i 2 -p 10" makes a bit of a > silly looking configuration file. Secondly, placing any of the above > commands in your "menu" entry seems wrong to me -- if the user runs pppload > from the command line, he doesn't get the same settings as starting it from > the menu! I second this. In fact, when suggesting we should have a conffile, I didn't think of a menu-specific conffile; it was more a suggestion of improvement to the app itself. As suggested by Avery, a shell wrapper would be a usable solution, but this may introduce work on upgrade when/if the binary handles a conffile itself. I'd think a plain-C (or whatever language pppload is written in) conffile handling would be better, if you have time to do this, and if the upstream author accepts it (better see that before starting such work ;) But I must admit the current solution works OK for me, and is a very low-cost one ! Regards, -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | - A computer engineer's looking for a job ! - -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: debian-kbd needs M4 hacker
Marco d'Itri writes: > The debian-kbd list needs some help from an experienced M4 guru. > I wrote the macros to generate keyboard tables, but some of them do not > work. We need someone to debug them, otherwise we can't progress. > The macro set is about 150 lines. I'm not really a guru, but I had the opportunity of writing some M4 macros to work with autoconf. I may help, if you wish. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Libc6 progress for contrib and non-free (Dec 1997)
Richard Braakman writes: > non-free: xforms0.86-0.86-2 xmysql (contrib) is not listed, but depends on both libc6 and xforms0.86. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uploaded wwwoffle 2.0-1 (source i386) to chiark
Federico Di Gregorio writes: >* Added cron job to purge wwwoffle cache. Isn't it automatically handled by wwwoffled ? There is a "Purge" section in /etc/wwwoffle.conf (v1.3) that seem to indicate there's an internal mecahnism for this. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
tetex URGENT: can't use ygoth font
Hi there,
I cannot have the ygoth fonts to work correctly, and would appreciate
some very-very-quick help. Note that I don't use the latest versions
of tetex, and would be happy to download them iff they fix this
problem, but as I have a slow modem link, I'd prefer to be sure what
the way to the fix is.
Here is a test file:
\documentclass{minimal}
\usepackage{oldgerm}
\begin{document}
\textgoth{This is some text.}
\end{document}
Compilation works fine. But dvips fails: it seems that mf produces
output (despite many "Strange path" warnings), but no file is created
in /var/spool/texmf/pk/ljfour/public/gothic/, which may explain why
dvips says "Font ygoth not found".
The spool dir and subdirs have mode 1777, so I think that at least
should be OK.
$ dvips font-test -o
This is dvipsk 5.58f Copyright 1986, 1994 Radical Eye Software
' TeX output 1997.12.30:1356' -> font-test.ps
kpathsea: Running MakeTeXPK ygoth 600 600 1+0/600 ljfour
MakeTeXPK: Running mf \mode:=ljfour; mag:=1+0/600; scrollmode; input ygoth
This is METAFONT, Version 2.718 (C version 6.1)
[...]
Font metrics written on ygoth.tfm.
Output written on ygoth.600gf (124 characters, 30140 bytes).
Transcript written on ygoth.log.
MakeTeXPK: `mf \mode:=ljfour; mag:=1+0/600; scrollmode; input ygoth' failed.
kpathsea: Appending font creation commands to missfont.log.
dvips: Font ygoth not found, characters will be left blank.
dvips: Checksum mismatch in font
/var/spool/texmf/pk/ljfour/public/cm/cmr10.600pk
. [1]
Here are the versions of tetex I'm using:
base: 0.4pl8-4
bin: 0.4pl8-3
extra: 0.4pl8-2
BTW, I didn't find a way to access the changelogs from the packages
WWW pages. It would be nice to add that, if I didn't miss them.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 |
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: tetex URGENT: can't use ygoth font
Yann Dirson writes: > I cannot have the ygoth fonts to work correctly, and would appreciate > some very-very-quick help. OK, thanks to all for your quick answers, and especially to Olaf for the fix. For those interested by the fix, here it is: Manually apply thefollowing diff to both MakeTexPK and MakeTexTFM: -echo "$0: Running $cmd" -$cmd &2; exit 1; } +echo "$progname: Running $cmd" +$cmd $$.errs 2>/dev/null + grep '^! Strange path' $$.errs >$$.strange 2>/dev/null + if cmp $$.errs $$.strange >/dev/null 2>&1 \ +&& test -s $$.strange >/dev/null 2>&1; then +echo "$progname: warning: \`$cmd' caused strange path errors." >&2 + else +echo "$progname: \`$cmd' failed." >&2 +exit 1; + fi +} Regards, -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I LOST mail between 21 Dec and 24 Dec.
Hi all of you, I had a mail problem with my ISP between the 21th and the 24th of december, which ended in >300 mails lost. If some of you emailed me any message during this period, there are good chances I didn't get it, and you should probably resend it. Thanks, -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Dependencies (Was: timezone/timezones problems)
> On 30 Dec 1997, [EMAIL PROTECTED] (Mark W. Eichin) wrote: > > > So, timezone (7.48-3) is installed, and "required", so dpkg won't > > remove it. timezones (2.06-1) is available, and "replaces/conflicts" > > timezone, but dpkg (1.4.0.19) won't replace it, even with > > auto-deconfigure. Is there a non-"force" way to handle this? > Robert D. Hilliard writes: > This is Bug#16260. Is this really a bug in timezones ? It seems quite similar to the problem I have myself (as the maintainer - never heard of anyone else speaking on this) while upgrading e2fsprogs to 1.10-9. I thought it might have been a bug in dpkg's dependency mechanism; I guess I reported that, but can't find out a copy in my folders, neither can I find it from the headers in "Unanswered pbs"... Does someone have an idea about that ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Dependencies
Kai Henningsen writes: > Plus, dpkg isn't thorough enough with dependencies. This is what leads to > dselect install-configure-remove-install-configure-remove cycles, and > sometimes to installs breaking the system - dpkg doesn't take into account > how dependencies etc. change during package installation. Yes, that's how I interpret the problem with e2fsprogs. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
My Epson Stylus (color 600) config
I thought the small trick I've installed on my box would be of
interest. Maybe not as such, because the few bytes spared from
printcap are replaced by an additionnal script, but as an idea of
future directions for magicfilter.
It makes use of a lprng special feature, and uses the uniprint driver;
I use aladdin-gs, and didn't test it with GNU gs. It simply works
with a single printcap entry using many names (one per
resolution/actual filter), by making lprng pass the printer name as a
command-line arg to a script, which then calls the appropriate magic
filter.
My magicfliters are not different from the one James posted.
This could be improved. Eg, you'll notice that the default resolution
is hardcoded in the filter script ("stclow").
What I think could be done would be to add some more powerful
parametrization to magicfilter. What's needed here is a case-like
structure on the printer-name. It will prevent to have many filters
differing only by the resolution used.
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/>
printcap
Description: Binary data
stc600-filter
Description: Binary data
Re: Debian 2.0 release requirements
Alex Yukhimets writes: > if something > bad happened and you created a file(s) with some non-ascii charachters, > "ls" will trash the console while "ls | less" will show you everything > and let you delete it. ?? Why on earth do you need less for that ? Doesn't "LANG=C /bin/ls -b" do the right job for that ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Offering package tkman (non-free)
The tkman package needs a maintainer who knows TCL/TK programming (I don't have these skills, and only took it because it was orphaned and out of date). It seems to me lots of things could be done on this program to integrate it better in the Debian system, but I couldn't convince the upstream author of the usefulness of any of my suggestions, so I guess this will have to be done by the Debian maintainer of the package. I'll gladly offer my tkman mail folder, containing most of my ideas, to the new maintainer. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ksymoops packaged ? System.map issues ...
Bernd Eckenfels writes: > If you have installed a current MAP File for the kernel (which is done > automatically by the kernel installer package), syslogd/klogd will be able > to read this and will display all Ptr references in lines from the kernel > with the resolved symbol. It doesn't contain the *modules* symbols. > This is a good start for debugging, have u ever > looked into /var/log/messages? > > Apr 6 21:19:28 lina syslogd 1.3-3#25: restart. > Apr 6 21:19:28 lina kernel: klogd 1.3-3, log source = /proc/kmsg started. > Apr 6 21:19:29 lina kernel: Cannot find map file. > Apr 6 21:19:29 lina kernel: Error seeking in /dev/kmem > Apr 6 21:19:29 lina kernel: Error adding kernel module table entry. > > -> no support for translation, because the /System.map file was not found. What kernel version do you use ? Do you use kernel flavours ? > >From klogd(8) > > # As a convenience klogd will attempt to resolve kernel > # numeric addresses to their symbolic forms if a kernel sym- > # bol table is available at execution time. A symbol table > # may be specified by using the -k switch on the command > # line. If a symbol file is not explicitly specified the > # following filenames will be tried: > # > # /boot/System.map > # /System.map > # /usr/src/linux/System.map The manpage is out of date. It also looks for "/boot/System.map-$(uname -r)". -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package pre-selections tool
James R. Van Zandt writes: > >I guess you don't count the "router/firewall" as being part of "all > >the above". I'd suggest it would be put below "standard" (in a > >"specific setups" section ?), as it is confusing as such. > > Actually I did think that the "router/firewall" packages would be a > subset of "workstation" packages. However, I am no expert in > firewalls, and am not surprised to learn different. I'm no expert either, so this only reflects my own expectations. I just think that a firewall is only useful to do the interface between a local net and the Wild World of the Internet. I know even less about routers, but I assume they just act as an interface between several networks as well - anyway, there is a kernel option "optimize as router, not host" that's sufficient to tell not every machine is a router. Same regarding all firewalling options in the kernel. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb + tar + bzip2 suggestion
Joel Klecker writes: > However, I have run across a patch that adds an option that does use magic > numbers to guess which compression program to use. The URL was posted on > gnu.misc.discuss some months ago, but it is unfortunately not on dejanews. For things like that, I have developped a utility function which, among other things, identifies by magic most compressed formats (ie. .Z, .gz, .bz2, .lzo - I didn't add .bz, but that would be tricky), can additionnaly do a magic-identification on the compressed data, and is safe regarding non-seekable files. It can be found in the console-tools package (see slink - still in Incoming for now), as function findfile() in libctutils (/usr/include/lct/utils.h). Note that I stillconsider this to be in alpha stage - it has to be made more modular. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bzip2 for source packages?
James Troup writes: > Michael Alan Dorman <[EMAIL PROTECTED]> writes: > > > Might I suggest that using it for source packaging would be > > appropriate, though? > > By recompressing things in bzip2, you lose the ability to use pristine > upstream source (since the vast majority of source stills comes in > .tar.gz form). If I'm not mistaken, the main reason for pristine sources is to be able to md5-check the source archive. Please correct me if I'm wrong. Then it could be possible to list in .dsc the md5, size, and filename for the .tar file instead of the compressed-tar file's. This would allow arbitrary (as long as supported by dpkg-source) compression tools to be used. Let's say .bz2 files on ftp sites, and .gz files on CD's ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mirror of Incoming
There's one here: ftp://ftp.lh.umu.se/pub/linux/debian-Incoming Maybe some list of such mirrors could be added to the Developper's Corner ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for xemacs20 user wishing to help
Hi there, I've uploaded some days ago a NMR of tm (Tools for MIME). However, as I'm quite short of bandwidth, I only have emacs19 and emacs20 installed, and could not get from xemacs20 the list of files to byte-compile. I'd be grateful to an xemacs20 user (with bbdb and mailcrypt installed if possible) who would like to run some elisp code for me, and send me back the list of those files. Thanks by advance, -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: dpkg and handling of the Unconfigured state
Hi there, Currently, the "unconfigured state" for a Debian package is AFAIK only reflected by its state in dpkg's status files. This leads to programs that are installed in the system, thus can be lauchned by some user, even if their run cannot complete, either for an obvious reason like a missing shared lib, or for any other reason that will have justified the dependency which caused the package to be left unconfigured. Running a program in such a package may lead to unpredictable results, though in the most simple case the user just gets an error from the dynamic linker. A solution I see to this situation would be to have all executable permissions unset when a package is unpacked, and then set as specified in the package when the package has been configured. It seems to me that all cases of dependencies would be fulfilled with such a mechanism: a package would only get its X bits set when all packages it depends on would be configured (ie, when it applies, with their own X bits set). Note that this would advocate for essential packages to be configured immediately after being unpacked, or the pakcaging system may break. Or maybe essential packages may be given special treatment in this case, in that they would not be subject to these manipulations. This proposal only concerns executables. Maybe other things can be done, eg. for shared libs, but I'm no expert here. Any comments on this ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: dpkg and handling of the Unconfigured state
Jason Gunthorpe writes: > Well, I have not observed that dpkg is capable of placing guarentees on > the dependency state during the *rm scripts. Alot of packages make use of > their dependents during their removal which leads the the problem that you > can no longer upgrade without configuring alot of stuff as it is unpacked. Ah. That may be another problem, which probably comes from the fact that dpkg is not able to do multiple install/configure cycles in one run. Once that is fixed, I think the problem you mention will go away. Right ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and Window Mangers
Branden Robinson writes: > The long-term plan is: > > 1) ship an empty /etc/X11/window-managers with xbase > 2) mark it as a conffile > 3) separate twm into its own package > 4) write /usr/sbin/register-window-manager I don't think shipping an empty file, and marking it as a conffile, would be interesting. If this file is going to be modified only by the registering interface, then this should not be necessary. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Languages for Description (Was: language for changelog)
While we're talking about language issues and people not speaking english: if we want Debian to be one day a valid choice for a lambda user in a random country, we *will* have to work out some mechanism that allows translated Descriptions: fields. [I guess this issue does not really belong to deb-policy, so warn your CC: - I only added it in mine so that people who raised an interest in such issues in the previous thread read it] -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)
Raul Miller writes: > Is there any reason we couldn't do a delayed debian-hamm-alpha release? I was also thinking about that. As i386 seems to be the "leading arch" (sorry for others, no offense intended), we could IMHO release it first (maybe together with m68k ?), and then release hamm/alpha or hamm/whatever later on, maybe even if slink/i386 is near release. -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nice stuff to package: Open C++
Open C++ is a toolkit providing a meta-programming-level above C++. It has a Xerox copyright which seems to make it DFSG-free. Home page (with online ref. manual): http://www.softlab.is.tsukuba.ac.jp/~chiba/openc++.html It would probably be nice to get this one into slink... -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Wishing to maintain package 'dpkg-ftp'
It seems that this package hasn't evolved for quite a long time. As there are many bug-reports, and as I worked out fixes for some of them, I suppose its maintainer has no time for it, and I'm wishing to maintain it. If I get no response within a week, I'll take for granted that there's no opposition to that, and start releasing fixes. Is there any reason not to do so ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
e2fsprogs_1.07-1 still in 'experimental' !
"Package": master.debian.org Version 1.07-1 in experimental of e2fsprogs has been superceeded by 1.10-2 in unstable. I think it should be removed. (experimental shadows unstable on my system; I think this is normal...) -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: a "Debian System Method" for dpkg
Request for comments: a "Debian System Method" for dpkg Because of its owner having forgotten the debian-CD in a train, I recently had to install a debian system on a PC. We still had the installation floppies we had used for another machine on the same ethernet, and had access to that machine, which had a dpkg-repack. So I repacked the needed packages, moved repacked netstd to the new system with a floppy :-( and the others with FTP, and installed them by hand. No need to say I forgot some dependencies, and had to repeat these steps several times with missing packages... That left me some time to think about that: * an automated version of what I was doing would have been interested, but here, the situation was an exceptional one... * anyway, for a network of debian machines, we could arrange to have only one machine installing/upgrading by FTP, and the others installing/upgrading from that one without it having to waste disk space with all already installed deb files. * a full repackaging might not be necessary, as it is time-consuming on "slow" machines (I'm speaking here about a P75 !) for large packages (multi-megabytes ones), but it should at least partially be done. * packages descriptions (those from Packages files) should be made available from one machine to another (I don't think they are kept as-is after install, so they would have to be rebuild, at least partially). * I see 2 different solutions: - NFS-mount the source machine, and execute all on the target machine. That's only realistic if NFS maps root on target to root on source, and that might not be always the case. - dialog between the 2 machines: this makes the source machine execute programs (build description, repack), so maybe a daemon process would be interesting, for security reasons. * conffiles would have to be handled correctly: maybe default conffiles should be always kept (*.dpkg-dist), and repack should be able to recognize them (with md5 ?). etc., probably... -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: a "debian-daemon" project
Request for comments: a "debian-daemon" project Using FTP for a while to keep my system up-to-date, I see several things that, I think, cannot be done easily: * Data transfer minimization (with rsync-like algorithm) where that could be applied. That does not include, eg, compiled binaries, but would fit well for sources packages in tar format (gzipped version could still be used for full downloads), Packages files (same comment), probably most packages in binary-all (if we can have a non-compressed tarfile inside the deb file); * Getting changes between installed and available versions, to allow users to download a new version only when they have use of it; ...and probably more that I don't remember right now; please be free to add to this list... That could probably be done by extending the FTP protocol (or another one, like FSP, but I don't know much about that one) to support rsync algorithm. Further more, such a daemon could be made to fully monitor the distribution-site: the site-mainainer would just "send" (maybe locally :-) the new files to the daemon, which would automagically ensure site coherence, including keeping Packages (and other) files up-to-date, removing old versions from experimental when a newer has come into unstable (noone told be I was wrong here, so I persist ;-), maybe automatically find out between what versions the rsync algorithm would be profitable, etc. -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
Mark Eichin writes: > Granted, a *real* solution would be some way to point things off to > other disks and have dpkg "know" about it so it handles upgrades > cleanly. We've talked about this some but haven't gotten very far. Maybe a variation on dpkg-divert would fit well ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
Joey Hess writes: > With this scheme, you arn't running a shell script when you unpack the > package. You can figure out how to look at the tar file or shar archive or > whatever format the upstream source is kept in, without running any special > shell script. The only difference between this and how dpkg-source operates > now is that the actual unpacking of the upstream tarball/whatever (NOT the > debian source package) and applying of the patches is pushed back into > debian/rules, where it can be handled by a shell script. But you need not > run this shell script until you decide to build the package -- which makes > it just as safe as things stand now. I'm not su sure: it seems you will still have to execute something to just *browse* to sources. Am I wrong ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
James Troup writes: > (Especially when people do stuff like release a new Debian revision > where the only change is the maintainer's email address.) Maybe we should discuss a policy about such changes. Eg, using -2.1 as debian-version when you just make changes to version -2 that "don't affect" whatever will be installed. I think some people do that, but maybe it should be written somewherer... -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Sysvinit and System.map (Was: dangling symlink System.map)
Santiago Vila Doncel writes: > I have just installed a fresh system from scratch using the latest boot > floppies. At the end, I had a dangling symlink: > > System.map -> boot/System.map- > > pointing to nowhere. No idea how this happened. Don't know either. But it's been some time I wonder why this link isn't updated on boot to point to "boot/System.map-`uname -r`", or suppress the link and issue a warning if the latter is absent. This would ensure correctness, I think. Is there a good reason not to do so ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Getting current keymap
On Fri, Sep 08, 2000 at 07:19:58PM +0200, Miros/law `Jubal' Baran wrote: > 6.09.2000 pisze Renaud Guérin ([EMAIL PROTECTED]): > > > Is there something obvious I missed or is it really unfeasible ? > > I looked at it and... (didn't do that before, because I used my own > keymap, which doesn't need to include anything) and yes, setting keymap > before mounting /usr is rather not the best example of package > design... Setting the keymap as soon as possible was a design choice done before I ever headr about Debian, I think. Whether it is still valid is an open issue, as the reasons to do that were not kept anywhere I know of. Probably this should be discussed here and if noone objects changed ASAP, so that any problems get caught quickly. > The whole console-tools font/keymap configuring scheme should be IMO > completely redesigned (and re-thinked before)... giving f.ex. the > possibility to add font/keymap packages and configure font/keymap > without direct playing with /etc/console-tools/config... I had started this before potato release, and started using debconf. However I did that in a rather complicated way which needs to be rewritten, which I have started to do - I did not put much time here however. Basically, /etc/console-tools/config should end up being generated by the postinst from debconf-entered information. -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Cheaper, more Powerful, more Stable ! http://ydirson.free.fr/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
On Tue, Sep 12, 2000 at 10:46:34AM +0200, Torsten Landschoff wrote: > On Fri, Sep 08, 2000 at 07:39:04PM +0200, Yann Dirson wrote: > > > Probably this should be discussed here and if noone objects changed ASAP, > > so that any problems get caught quickly. > > Don't change that. Beginners would be very confused if the keytable is not > working as expected. Not everybody can work with a US keyboard table if the > need arises. In which cases is the user able to get to the shell before all rcS.d/ scripts are run ? I can only think of 2: * init=/bin/sh or similar - keymap doesn't get set anyway * user interrupts the boot process with ^C Or do I miss something - maybe I should re-read the scripts :) > Debian should try to get more user friendly instead of getting uglier > I think. Yes. that's the point :) -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Cheaper, more Powerful, more Stable ! http://ydirson.free.fr/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting current keymap
On Wed, Sep 13, 2000 at 10:47:09AM +0200, Torsten Landschoff wrote: > 3) S30checkfs.sh fails and bails out into a shell (using sulogin). > > Currently the keyboard mapping is loaded in S05keymaps-lct.sh and I think > that's a good thing. Thanks, good point. I'll put this rationale into console-data's README.Debian. Best regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Cheaper, more Powerful, more Stable ! http://ydirson.free.fr/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: console-tools vs kbd
On Sun, Dec 31, 2000 at 05:54:56PM +, Sam Vilain wrote: > Hi there, > > I'm using a non-standard keyboard that sends odd scancodes. I wrote a > startup script that does a whole heap of "setkeycodes" commands, but I've > found that the version of "setkeycodes" in the console-tools package does not > work with kernel version 2.2+. The one with the "kbd" package works fine, > but "kbd" seems to be a somewhat deprecated package. There is a known bug of setkeycodes in console-tools ignoring the last pair of args. If it is not fixed in your version of the package (hm, did I already upload a fixed one ?), just adding 2 dummy parameters at the end of the command-line should do the trick. HTH, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Cheaper, more Powerful, more Stable ! http://ydirson.free.fr/ | Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Matt wrote: > The ideal solution would be to be able to share tarballs between source > packages. Then, all of the kernel-image packages could be built as if they > had a complete kernel source tree as their source package (which simplifies > things a lot), and yet we would only need one such tarball in the archive. > Of course, I have little idea how much work this would be to implement, > except that it would touch a lot of different tools. The way I understand it was intended to work would be to have one single kernel-source-X-Y-Z package somewhat like what we have today, and having the various kernel-image-whatever build-depend on this kernel-source and any necessary kernel-patch packages. If this understanding is correct, I admit I don't see why the practice has diverged from this idea. -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Matt wrote: > It would be a significant gain if kernel modules could always be built > against kernel-headers, without requiring full kernel-source. Since recently there are also kernel-build packages, which appear to be made precisely for that. I take it to mean the kernel-headers packages have proven deficient in some way, but I probably missed many things - I am even under the impression their construction is not even done by make-kpkg itself. Could someone elaborate on that ? (Herbert ? Manoj ?) Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Herbert wrote: > * The kernel-source binary contains all bug fixes as is. Guido raised > a good point that if we separated the patches from the kernel-source, then > users may miss out on the bug fixes. This is especially important in light > of the current speed of upstream releases. > > * The pristine kernel-source is available in the binary archive. Many people > have asked for this in the past and this makes it available in the form of > a source tar ball plus a patch. On the other hand, I would find it somewhat non-intuitive that the pristine source would only be available as the result of the application of a patch - and I tend to see that as an indication that it'd be more logical the other way round, with a pristine tarball and a real diff. We could get around Guido's point mentionned above by having a list of default patches to apply, which would by default contain the debian patch. Additionally, with things done this way, we're not even forced to update the whole kernel-source-2.4.20 seven times or more, we just have to update kernel-source-debian-2.4.20, which I believe would be good for the health of our network pipes. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Arnd wrote: > Ok, but I still would love to see single patches instead of one big > patch containing all the common stuff. You can't really avoid > situations where you want a patch on all architectures except one or > two. This may be either because a patch breaks on one architecture > (which should be of course be fixed, but you might not want to > rebuild all kernels and modules on all other architectures because of > it), or because the same fix is contained both in the debian collection > and in the patch set published by the upstream arch kernel maintainer. > > I'm not sure if dh-kpatches already solves this problem, but it should > be possible to add. If you mean, whether it can handle something like "Architecture: !ia64, !hppa", well, not yet, although it could be done. But that would mean stopping the use of make-kpkg-level architecture support, just like it does not use make-kpkg-level kernel-version support. Although that may not look like a big deal, that seems to show that at some time a redesign of the interface between make-kpkg and the patches themselves would be a good idea. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Matt wrote: > The part you seem to have missed is the distinction between a source package > and a binary package in what I wrote above. Not completely, although the time between reading and answering did not help me to be 100% clear with this :) > I do not think this is a practical idea to work toward at this time, > however. Yes, a new generation of source packages is needed, but if we could settle the kernel-packaging issue without this, that would at least help to get it running for sarge... Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Arnd wrote: > Actually, I was thinking of a different concept with a 'Replaces: tag, Hm. As I understand it, it would be more something like a "Provides:" declaration, it seems. Such a feature does not seem useless to me at first glance (we already see aglomerations of patches, like FOLK, which coule have make use of this), but I'm not sure it would be something we can work with. Let's look at your example: | Patch-name: Debian base patch | Patch-id: debian | Architecture: all | Kernel-version: 2.4.20 | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ... | | Patch-name: Pre-patch 2.4.21-pre7 | Patch-id: patch-2.4.21-pre7 | Architecture: all | Kernel-version: 2.4.20 | Provides: ptrace, ethernetpadding Here I suppose the pre-patch is supposed to be applied first, and then the application of the debian patch would only trigger application of those dependant patches not provided by the pre-patch. That's only fine _if_ the replaced patches are similar enough so that any patch in the debian set, that would depend on those, can still apply atop the new one. That is, if there are several revisions of a given fix, we'll have to use versionned Provides: and Depends:, or we're doomed. Not that it's impossible, but I'm not sure it's exactly trivial to implement... | Patch-name: AMD64 CVS snapshot | Patch-id: amd64-20030417 | Architecture: i386, amd64 | Kernel-version: 2.4.20 | Depends: debian, patch-2.4.21-pre7, simicsfs | Provides: aic7xxx Here I suppose you should have swapped debian and patch-2.4.21-pre7, or that simply wouldn't apply. > Do you think that make-kpkg and dh-kpatches could/should be merged, > making the dh-kpatches information evaluated by make-kpkg if available, > or do we need changes beyond that? They cannot be completely merged, since they work on complementary stages of the kernel build. OTOH, gradually the kernel-patch-scripts package is gradually going to factorise things that currently get duplicated in all kernel-patch packages, and since this part of dh-kpatches will work in the same stage as make-kpkg does, it may make sense at some point to have a look at something like a merge of this part into make-kpkg. But since this is all about things yet to be written, we'll see later. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
On Tue, May 27, 2003 at 07:37:42AM +0200, Sven Luther wrote: > On Tue, May 27, 2003 at 07:23:27AM +1000, Herbert Xu wrote: > > On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote: > > > > > > We could get around Guido's point mentionned above by having a list of > > > default patches to apply, which would by default contain the debian > > > patch. > > > > Yes, but then the problem is that unsuspecting users could be > > building kernels using the kernel-source package thinking that > > it contained all the security fixes. > > Have it depend on a kernel-source-security-fixes or something > such ? That's more or less what I'd think of as well. We can start with an empty security patch, and have this one grow as needed. This way, apt will show people they have an outdated security patch - which, BTW, may be more of an incentive to upgrade than just an outdated kernel-source package. That does not mean the user will rebuild his kernel at once with the new patch, but well, I don't think we can do much more here :) > And have make-kpkg issue a big warning if it detects that the > sources were not patched ? That could be easy to do. Just have the security patch create a debian/APPLIED_security stamp, and have make-kpkg look at that... Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Sven wrote: > Why don't we use a scheme similar to what xfree86 use for its patches. > Sure we would need to adapt it as the patches are distributed, but we > could well do it. As I understand it, the xfree86 package uses (some derivative of) dbs, in which the package maintainer has to order the patches by hand, instead of declaring explicit dependencies (much like sysvinit and others do, and like the patch-ordering facility in make-kpkg). If the above is correct, I'd see that as a step backwards. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Arnd wrote: > > Let's look at your example: > > | Patch-name: Debian base patch > > | Patch-id: debian > > | Architecture: all > > | Kernel-version: 2.4.20 > > | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ... > > | > > | Patch-name: Pre-patch 2.4.21-pre7 > > | Patch-id: patch-2.4.21-pre7 > > | Architecture: all > > | Kernel-version: 2.4.20 > > | Provides: ptrace, ethernetpadding > > > > Here I suppose the pre-patch is supposed to be applied first, and then > > the application of the debian patch would only trigger application of > > those dependant patches not provided by the pre-patch. [...] > In my example, if the isdnbonding patch has to be applied after > ethernetpadding, it would have to say so in its description. > patch-2.4.21-pre7 can contain the same patch and should > consequently be applied at the same time (e.g. after > binfmtmisc, but before isdnbonding). OK, let's assume a moment that isdnbonding declares a dependency on ethernetpadding: Let's apply the debian patch first, since that's what you suggested later. This patch application will trigger, among others, the (pre-)application of isdnbonding, which itself will trigger the (pre-)application of ethernetpadding. Now the "Provides" logic will have to cause the application of patch-2.4.21-pre7 instead. That seems to settle reasonably. But now suppose that a new version of the ptrace patch is issued. Either we just rely on the current version of the debian patch, and the new ptrace one won't even be considered by the mechanism here described, if you ask for the application of patch-2.4.21-pre7. Or we have to issue a new revision of the debian patch, either depending on a new ptrace2 patch, declaring a conflict with old ptrace (in which case we have to handle conflicts as well), or with a versionned depends (which has to be implemented as well) on the new version of ptrace. Basically, this means bring a full dpkg/apt-like dependency model into patch application. This overall sounds to my ears a bit like overkill... > The debian patch set should generally come first, except for the parts > in it that depend on patches 'provided' by some other patch. The maintainer > of patch-2.4.21-pre7 would have to make sure it applies on top of or mixed > with the debian patch set. I don't know what you mean with "mixed with". It is already some work when we have to provide, in addition to the upstream version, a version of the patch(es) that applies to the (current) debian kernel (some people may have noted that dh-kpatches supports declaring such patches since recently). I hope you're not suggesting all mixes of sub-patches of the debian patch should be supported - this idea would have no chance to survive long :) Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Maintaining kernel source in sarge
Herbert wrote: > Yes that isn't easy to check apart from the fact that if there isn't > an arch update after a security update to kernel-source, then that arch > is probably vulnerable. If you've got an idea on how this can improved, > please let us know. A possibility would be to define a versionning scheme on the arch-dep kernel-patches. You issue version 2.4.20-8, and others release a new version as 2.4.20-8, and then possibly further -8.1 and such, and don't bump to -9 before you do. That steps into the NMU numbering-space, but I suppose we can expect NMUs on arch kernel-patches to be quite rare anyway. And we could give a NMU numbering-space with 2 dots, by making the 1st revision of an arch patch to be -8.0 at first. Does it make sense ? -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Very uneven distribution of packages per maintainer
Adam wrote: > So doing bts work is worthless? :) Hey, someone once wrote similar scripts to count how many bugreports were reported by anyone ! /me rejoices recalling he was ranked 3rd by the number of open bugs :) Well, never mind :) -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
What is the default gcc version ?
Despite the build-essential list and gcc-defaults package pointing to gcc 3.3, at least 6 archs still used 3.2 this week (alpha ia64 powerpc m68k mips mipsel) and buildds on s390 and hppa still do not print the toolchain versions, so I can't tell for those 2 ones. That's half of our archs looking out of sync with the "policy" or whatever dictates the gcc version to use. I suppose there may be good reasons for those to avoid 3.3 (in which case that should be reflected in build-essential and gcc-defaults), or the buildd's should be upgraded. Can anyone please shed some light on this issue ? [please CC me on followup] Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Bug#474254: ITP: tagua -- Board-game frontend for playing chess variants and other games
Package: wnpp Severity: wishlist Owner: Yann Dirson <[EMAIL PROTECTED]> * Package name: tagua Version : 1.0~alpha2 Upstream Author : Paolo Capriotti <[EMAIL PROTECTED]> and others * URL : http://tagua-project.org/ * License : GPL Programming Lang: C++, lua Description : Board-game frontend for playing chess variants and other games Tagua is a frontend for a variety of board games. Currently supported games include chess, shogi and a couple of variants of those games. . Tagua is based on a powerful plugin system that allows many games to share the same graphical framework, game history handling, interoperability with AI engines and connectivity to network servers. . It currently has support for xboard-compatible chess engines, and xshogi-compatible shogi engines, as well as network play on chess ICS servers. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (90, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23.8-smp (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=french (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421745: RFA: bigloo -- A practical Scheme compiler
Package: wnpp Severity: normal My primary focus is on other things these days, and this package would benefit from someone using it more than I do, so this is the formal request for adoption for the bigloo package. Some of the work to do on the package: - package new upstream release - activate the .net backend - maybe switch to the system libgc - ensure the emacs mode is correctly integrated and does not interact in unwanted ways with standard modes (maybe split the -ude package ?) - hunt for the pending arch-dependant issues (hppa, m68k) - work with upstream to make the build system more resilient The package description is: Bigloo is a Scheme system which includes a compiler generating C, java, or .NET code, and an interpreter. . Bigloo conforms to IEEE Scheme and is mostly conformant to Revised^5 Report on the Algorithmic Language Scheme with many extensions: - SRFI 0, 2, 6, 8, 9, 18, 22, 28, and support for using the reference implementations of other SRFIs. - Rgc, a lex facility. - Match, a pattern-matching compiler. - Foreign languages interface. - Module language. - Extension package system. - An LALR facility. - An Object system. - Some DSSSL support features. - Unicode characters and strings. - Process, Pipe and Socket support. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (90, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.19.1-smp (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=french (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of kernel patch packages
[this and the following mails are resent versions, my mails did not
make it to the list due to some config problem - sorry for any dups
this may cause]
Since April 2009, kernel-package has no use any more for the
{kernel,linux}-patch-* packages (AFAIK the current recommended way of
patching a kernel is using git). My understanding was that those
packages should then be simply removed from the archive. However,
there are still a couple of kernel patch packages in squeeze and sid,
and some of them got recent updates.
So the question is, is it time to request removal of those packages,
or is there any remaining reason not to do so that I missed ?
[CC'd maintainers of the relevant packages]
Best regards,
--
Yann
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100323223506.ga11...@nan92-1-81-57-214-146.fbx.proxad.net
Re: Status of kernel patch packages
On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote: > On Sat, 20 Mar 2010 15:14:59 +0100 > Yann Dirson wrote: > > So the question is, is it time to request removal of those packages, > > or is there any remaining reason not to do so that I missed ? > > As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with > mainline, but it's not fully featured one yet. At least, I want to > provide it with squeeze. > > and hope kernel-package would enable patch support again... ;) I won't speak for Manoj here, but I feel we should think about other ways to provide those patches. One way could be simply to provide ensure those patches in some git tree, that users can easily fetch and merge before running make-kpkg. But I'm not aware of a git tree holding the debian kernels - SVN is still listed as the VCS for the linux-2.6 package (which, BTW, continues to surprise me). But at least we could have some convention about where to make available git trees for patch stacks - something on git.debian.org surely, which could be quite efficient with the "forks" feature of gitweb activated (which does not seems to be the case aleady). Then maybe some simple helper scripts could make it a snap to fetch all patch stacks and start a merge. Maybe we could at some point also be able to publish merges of conflicting patch stacks in a similarly convenient way. Such a resource may even be interesting to many people out of Debian. Well, that's just random week-end thoughts - you know, world domination and the like :) Best regards, -- Yann -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323223533.ga11...@nan92-1-81-57-214-146.fbx.proxad.net
Re: Status of kernel patch packages
On Sun, Mar 21, 2010 at 11:57:01AM +0100, Yann Dirson wrote: > On Sat, Mar 20, 2010 at 05:39:00PM +0100, Jonas Smedegaard wrote: > > On Sat, Mar 20, 2010 at 05:28:33PM +0100, Yann Dirson wrote: > > >On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote: > > >>On Sat, 20 Mar 2010 15:14:59 +0100 > > >>Yann Dirson wrote: > > >>> So the question is, is it time to request removal of those > > > >>packages, or is there any remaining reason not to do so that I > > > >>missed ? > > >> > > >> As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged > > >>with mainline, but it's not fully featured one yet. At least, I > > >>want to provide it with squeeze. > > >> > > >> and hope kernel-package would enable patch support again... ;) > > > > > >I won't speak for Manoj here, but I feel we should think about > > >other ways to provide those patches. > > > > > >One way could be simply to provide ensure those patches in some > > >git tree, that users can easily fetch and merge before running > > >make-kpkg. > > > > Lots of possibilities arise if we do not constrain ourselves to the > > Debian ideal of a fully self-contained distribution usable while > > offline. > > > > I happen to like that ideal, also for kernel patches. > > I don't think there is a contradiction - eg. it could make sense to > ship a kernel repository in a package, and similarly for kernel > patches referencing the former as a (local) remote. Let's maybe stay focussed on the initial problem: we *had* a way to handle kernel patches as part of a self-contained distribution, but there is no support for this any more. Moreover that support we had was not 100% satisfactory (eg. bad handling of conflicting patches needing manual merge - although that was something I wanted to address in the never-finished dh-kpatches 0.100). My idea is to rethink the whole thing using today's tools - namely, git. Anyway, to get back to the initial problem of the current linux-patch packages, we currently still have patches in the distro, which were packaged for a mechanism that is not to be shipped in squeeze (and referencing that obsolete mechanism in their /usr/share/doc/), and this in itself is a problem of quality of the overal distro, right ? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323223705.ga11...@nan92-1-81-57-214-146.fbx.proxad.net
Re: Some observations regardig the progress towards Debian 3.1
On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote: > There are some good suggestions in your proposal, e.g. you suggest to > check whether the build dependencies are fulfilled. The lack of checking > for build dependencies in the current testing scripts often leads to > packages in testing you can't build inside testing. Sure, and that can probably be added to testing scripts right now, isn't it ? > But you have to be aware that your proposal only works for the cases > where the programs actually compile and work with older versions of > libraries, the big tasks like getting KDE 3, GNOME 2 or a more recent > Mozilla into testing aren't affected by your suggestion. Yes. We could think about having a fast low-cost buildd (ie. i386) initiating the build that will eventually migrate, and build arch-all debs. Only if that succeeds will other buildds start their work. If that initial build fails, then the unstable version has to be flagged on-hold, and attempted again when one of its builddeps has been promoted. But that would not handle the "and work" part of your statement. For this we'd need to be able to declare testsuites to be run (this has been discussed recently, IIRC, although I missed the thread). But more importantly, if a program deos not "compile and work with older versions", then it's a case of insufficiently-narrowed build-dep, and we'll have the same type of breakage that we have today with insufficiently-narrowed deps. Could anyone using "testing" (how much people use testing ?) share his feelings about the frequency of such breakages, and how it evolved since testing exists ? That could give a hint whether this is a showstopper or not. But that last point raises another issue: does anyone really use testing ? Would anyone use pre-testing after all ? And if we can make testing usable enough so that people do use it, what incentive would there be to use pre-testing ? > There might be new problems e.g. with inter-library dpendencies for > libraries without versioned symbols if your proposal would be > implemented. Hm ? I'm not sure I understand what the problem you mention is. > > There _are_ many things to think about, but it may be worth to > > investigate it, and see how we could handle the potential problems we > > can think of. > >... > > There's also a different discussion that should take place: > > Is testing actually worth the effort? > > Testing has it's benefits, e.g. it catches build errors and dependency > problems. So what about looking for solutions for the problems ? If we drop testing, what do we do instead ? Go back to evolving-unstable -> frozen -> stable ? > After three years of testing, it seems that some of the promises like > having testing always in a releasable state were never fulfilled, in > fact testing was sometimes in a worse state than unstable. I suppose many of use have a number of problems to mention. Could we just (attempt to) list them all, and see if they can be fixed easily ? Or if they require some in-depth restructuring ? I'll start with: - build-deps are ignored, causing unbuildable stuff => handle build-deps in exactly the same way deps are - insufficiently-narrowed deps, causing stuff to migrate where it should not => this looks like a real non-trivial problem to me. Ideas anyone ? - non-buggy packages are held forever, sometime because of very distant packages blocking them indirectly => my pre-testing proposal was written to address precisely this, but as mentionned above, it's not perfect either > testing with its lack of security fixes, aprox. 500 RC bugs and daily > changing packages is not usable for production systems. What's the problem with daily changing packages ? By nature, only different packages can change each day. That could make it a good compromise between stable and unstable, eg. for people in need for up-to-date desktops. But precisely, one of the problems for those people, is that _some_ packages _do_not_ change rapidly enough... Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Some observations regardig the progress towards Debian 3.1
Adrian wrote: > Your proposal wouldn't have been able to shorten the move of KDE 3 into > testing by one single day. Yes, my comment was misplaced wrt what you said, this problem still has to be addressed. My proposal, however, is more targetted to packages which would build with, say, KDE2, but are held into unstable because here they are build with KDE3. KDE may not be a good example. libgc is a much better example, although the number of packages held here is quite low compared to KDE. > testsuites must be written, and testsuites for GUI programs are even > more work. Fortunately several of the packages we ship already have one. And for the bunch of non-gui programs, we could surely add some minimal testing, say to ensure it does not segfault on trivial use cases. Just like what we already do for manpages. GUI programs are another story, but that's not a reason not to do it for non-GUI ones. > > > There might be new problems e.g. with inter-library dpendencies for > > > libraries without versioned symbols if your proposal would be > > > implemented. > > > > Hm ? I'm not sure I understand what the problem you mention is. > > An example: > > unstable: > > Package: libfoo0 > Depends: libbar1 > > Package: mypackage > Depends: libfoo0, libbar1 > > testing: > > Package: libbar0 s/testing/pre-testing/ > IOW: > The program in mypackage is in this situation linked with two different > so-versions of libbar at the same time. That's a good point. In my mind the libfoo0 package just rebuilt would only show up in pre-testing. We need to keep the original package in unstable, while increasing its version at the same time. That could be done either by a rebuild, or, less costly, by a simple unpack/edit-changelog/repack. In that case, if we had libfoo0_1.0-1 in pre-testing, and libfoo0_1.0-2 in unstable, we'd end up with libfoo0_1.0-2.0.1 in pre-testing, and libfoo0_1.0-2.0.2 in unstable, whether the latter was rebuilt or just repacked. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Re: Some observations regardig the progress towards Debian 3.1
On Wed, Nov 19, 2003 at 02:03:08PM +, Wookey wrote: > Doing my builds on a testing machine, then uploading to > unstable can mean I introduce packages compiled against the wrong library > versions. Source-only uploads would solve this and I could do test-compiles > on some debian machine. Off topic - you can have an unstable chroot on your testing machine for this, eg. with pbuilder. > > - insufficiently-narrowed deps, causing stuff to migrate where it > > should not > > => this looks like a real non-trivial problem to me. Ideas anyone ? > > Obviously it can be tricky for a maintainer to get right as they can't > necessarily try all (any!) of the possibilities but it should be aspired-to. > On the other hand, in my experience build-deps are sometimes > unecessaily-narrowed and require new versions of things for no particular > reason I can determine. I suspect the shlibdeps automation contributes to > this? Hm, the shlibdeps automation should not have an influence on build-deps, which belong to *source* packages only. One thing I see about this, however, is that sometimes a rebuild with more recent libs is required to get rid of some bug. And since there's no guaranty that a buildd has all latest versions (see http://people.debian.org/~dirson/buildinfo/ for a demo), I (and probably others) tend to add versionned builddeps as >=, whereas it should probably be an unversionned build-dep, together with a version range in build-conflicts. There may also be the case where one cannot exactly determine from changelogs (debian _and_ upstream) what version of a builddep is needed, and make a safe bet. Regards, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Looking for a builder/uploader to fix RC bug on gcompris
The gcompris package is *big* (15MB), and I won't be able to upload a binary version before monday. 1.0.3-1 does not build from source. I've uploaded signed .dsc + diff for 1.0.3-2 in [EMAIL PROTECTED], upstream source already in sid. I someone could please build and upload it quickly, it will be great - otherwise I'll do that monday, but every day counts for woody... TIA, -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#157729: ITP: gatos-drm-source -- DRM modules source from the GATOS project, with support for recent ATI chips
Package: wnpp Version: N/A; reported 2002-08-19 Severity: wishlist * Package name: gatos-drm-source Version : 1.2.0-14 Upstream Author : Vladimir Dergachev * URL : http://sourceforge.net/projects/gatos * License : GPL and additional rights Description : DRM modules source from the GATOS project, with support for recent ATI chips -- Yann Dirson <[EMAIL PROTECTED]> http://www.alcove.com/ Technical support managerResponsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer ([EMAIL PROTECTED])Développeur Debian
Bug#112478: ITP: thoteditor -- customizable editor for structured documents
Package: wnpp Version: N/A; reported 2001-09-16 Severity: wishlist Package name: thoteditor Version : 2.1e Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://opera.inrialpes.fr/thot/ ftp://sunsite.unc.edu/pub/Linux/X11/xapps/editors/ License : BSD-like Description : customizable editor for structured documents Thot is based on thotlib, which has been recently extented at W3C, and is used by their Amaya browser/editor. Unfortunately the Thot editor has not been much worked on lately and some work will be required on it. Especially, I believe Thot has the potential to be used as quasi-wysiwig editor for DocBook and other types of SGML documents. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux bylbo 2.2.19+reiserfs+ide #1 Wed Jun 13 20:05:28 CEST 2001 i586 Locale: LANG=français, LC_CTYPE=français
Re: EURO and CENT signs in the console keymaps
On Tue, Jan 01, 2002 at 01:41:33PM +0100, Eduard Bloch wrote: > I tried to include the support for Euro and Cent in the console keymaps. > Cent is not a problem. It is allmost unknown and AltGR-e could be surely > used for this. But Euro is a problem - keymaps have different location > of the ?. I cannot found good and trustworthy informations on the net, > so more user feedback is required. What I have so far: > > - Most keyboards have AltGr-e as Euro > - the French keymap (relative to US layout: <]>) AFAIK the keystroke you refer to, on my old french keyboard, produces the latin1 symbol known as "currency sign", which just happen to have the same position in latin1 (\xa4) that the euro symbol has in latin15. Many people use a latin15 font with a latin1 keyboard, hence this coincidental mapping. There are french keymaps somewhere that should give better euro support I guess. There's already an entry in the BTS. -- Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ? Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: Pro:<[EMAIL PROTECTED]> | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check <http://www.debian.org/>
Bug#755957: ITP: git-reintegrate -- Git extension to manage integration branches
Package: wnpp Severity: wishlist Owner: Yann Dirson X-Debbugs-CC: Felipe Contreras * Package name: git-reintegrate Version : 0.3 Upstream Author : Felipe Contreras * URL : https://github.com/felipec/git-reintegrate * License : GPL Programming Lang: Ruby Description : Git extension to manage integration branches This tools allows to define which feature branches will be part of your integration branches, and help you update the latter as new versions of the feature branches are available. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140724203554.ga23...@home.lan
Bug#759519: ITP: shogivar -- UI to play many shogi variants against human or computer
Package: wnpp Severity: wishlist Owner: Yann Dirson * Package name: shogivar Version : 1.55a+git Upstream Author : Steve Evans, H.G.Muller * URL : http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=shogivar.git;a=shortlog;h=refs/heads/C-port * License : GPL Programming Lang: C Description : UI to play many shogi variants, with builtin computer player This is a C/Gtk port by HGM of the Shogi Variants program written in VB for windows by S.Evans in the late 90's (http://www.users.on.net/~ybosde/), whose source was published in 2011 (https://groups.yahoo.com/neo/groups/shogivar/conversations/messages/1755), and finally released under the GPL at HGM's request. This is the only free-software program with an AI for most Shogi variants. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827233145.ga17...@home.lan
Bug#770384: ITP: sjaakii -- computer player for Chess and variants, including Shogi and XiangQi
Package: wnpp Severity: wishlist Owner: Yann Dirson * Package name: sjaakii Version : beta2 Upstream Author : Evert Glebbeek * URL : http://www.eglebbk.dds.nl/program/chess-index.html * License : GPL Programming Lang: C++ Description : Sjaak II - computer player for Chess and variants, including Shogi and XiangQi This is a new XBoard-compatible engine, including variants for Chess and Shogi that are not widely available elsewhere. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120210222.ga2...@home.lan
Bug#770509: ITP: uci2wb -- XBoard protocol adapter for chess/shogi/xianqi engines speaking USI/UCCI/UCI-XQ
Package: wnpp Severity: wishlist Owner: Yann Dirson * Package name: uci2wb Version : 2.0 Upstream Author : H.G. Muller * URL : http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=uci2wb.git;a=summary * License : GPL Programming Lang: C Description : XBoard protocol adapter for chess/shogi/xianqi engines speaking USI/UCCI/UCI-XQ This is a protocol adapter allowing to play against eg. GPS Shogi (package gpsshogi) and Elephant Eye (package eeye) using XBoard and other CECP-compatible GUI programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121204918.gw2...@home.lan
Re: Uploaded mpsql 2.0-1 (source i386) to erlangen
Michael Meskes writes: > mpsql (2.0-1) unstable; urgency=low > . >* Initial Release. >* Based on version 2.0b1. Hm, assuming the "b1" means it's beta stuff, I think it would be better to keep it in the Debian version. Changing the version number is confusing. Yes, I now it's a pain when it gets out of beta. I know of 4 solutions: * pushing for implementation in dpkg of things like alpha/beta stuff (IIRC there wasn't enough voices last time there was a talk about this) * heavily using epochs * add a string like "final" to the version when out of beta (I'll use this for fweb) * consider alpha/beta to be based on previous version. I use this for e2fsprogs 1.12-WIP, which I numbered 1.10-1.12-WIP- Note that the 1st one is not incompatible at all with other ones ;) Regards, -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
An idea for the BTS (Was: Weeding out slink bug reports)
Richard Braakman writes:
> Dennis L. Clark wrote:
> > Can anyone think of an automated way to weed out bug reports on versions
> > which haven't been released into hamm from the release-critical list? A
> > quick fix would be to modify the priority of the bug report, but that
> > would be The Wrong Thing.
>
> Automating this would be wrong, I think. The "Version" header in the
> bug report says what version the bug was found in, not necessarily
> what version first had the bug.
Sure, but it would be nice to have some sort of a mechanism to help us
to deal with bugs and dists.
I think that we should keep the state of each bug-report regarding
each dist (stable/frozen/unstable/experimental).
Maybe we could do that with additionnal attributes associated with
each report, eg. "{bo,hamm,slink}-status", which could take their
values in the set current of severities. The still missing "Fixed"
severity would be used to tell a dist is clear wrt this report.
A bug will then be allowed to be closed only when all dists list
"Fixed".
Any comments ?
--
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What version of glibc in Hamm?
Dale Scheetz writes: > Second: this was supposidly the last pre-release before the final version, > and I wanted it to get some testing. > > I will be coming out with a "final" Debian version in the next week or > two, depending on how much Ulrich stonewalls the upstream release. Hm... it will be great as long as there are no interface changes between current version in hamm and the final version you want to put there. I was told by Ted T'so that Ulrich told he doesn't care too much about these interface changes, which is BTW a reason for glibc to get into the LSB. Will this upgrade not imply that we recompile and test the whole of the dist, to make it sure hamm is self-compilable ? If not, every bugfix upload will possibly break something because of a possible glibc change... -- Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg and alpha/beta versioning (Was: Uploaded mpsql 2.0-1)
Gregory S. Stark writes: > this problem keeps coming up. i was thinking it would be handy to have a > character that is defined to sort before 0 and before the empty string. > tilde seems like the best choice to me, so something like: > > krb4-0.9.9~980514 > fltk-0.9.9~980527 > mpsql-2.0~b1 > > which i think is probably clearer than what i actually did: > > krb4-0.9.8.980514 > fltk-0.9.8.980527 This is a simple idea. IIRC, as the ~ char is not not allowed for now in version numbers, it could work. I remember of another proposal of extension of version syntax which was proposed (probably on deb-dev), which IIRC was to use an epoch-like syntax like 0.1:1.2-3, which did not contaminate all future versions with the epoch (which was, as I understand it, one of the arguments epoch's "enemies" have). I don't remember the (IIRC a bit hairy) exact semantics, but maybe it's worth studying further. Another problem we'll have will be what version-string to present the user to make it understand it's alpha/beta/whatever. Either extensions (tilde and dotted-epoch) are non-trivial as such, and should only be used IMHO as an internal (ie. for dpkg and developpers, and not for users) representation. If we're at last going to discuss these issues, I'm volunteering to coordinate the discussion and post summaries of the discussion's progress. -- Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: packaging kernel modules
It does not seem that we have currently any conventions regarding the packaging of kernel modules. I just tried the new alsadriver from slink, and, for the same reason I could not use the packaged joystick driver, this one too is useless to me. Here are the main criticisms I have regarding how modules packaging is currently done: 1) It appears that quite a number of drivers depend on some kernel features (eg, for alsa, PCI support), which may be compiled in for the default kernel, but which can be left out of a locally-compiled kernel. This seem to be the cause for my problems, and I guess other people may have the same problems. 2) These packages only provide compiled modules for some special kernel version. Eg, alsa install its modules for 2.0.33; joystick used to do it for 1 version I don't remember, and after a bug report, finally included the driver for 2 kernel versions, which even did not solve my problem, for the above-mentionned reason. 3) When for any reason using a kernel flavour (using the patch in kernel-package), any pre-compiled module is also useless, as the module dir is not the same (eg, I use a kernel with version 2.0.33-std, with modules under /lib/modules/2.0.33-std/; I cannot use standard mechanims to reliably access alsa modules installed under /lib/modules/2.0.33/) kernel-package, which seem to be the tool to build a kernel the Right Way on a Debian system, provides a framework to also build the relevant modules from /usr/src/modules/, which can IMHO be used to solve these problems. I think the various modules should be primarily packaged in source form, just as the kernel is, and installed under /usr/src/modules/. >From these source packages, the binary packages would be generated for the various binary kernel images shipped with Debian (presumably just like the binary kernel images are), and users who locally recompile their kernels will be able to recompile Debian-packaged modules from Debian-packaged source. >From current /var/lib/dpkg/available I additionnaly gathered: * It seems the pcmcia modules use such an approach, with a pcmcia-source package, and various pcmcia-modules-$(uname -r) packages. * The ultra, ibcs, ftape drivers also use the $(uname -r) string in the package name, but do not provide a source package for recompilation; most of them provide support for only one kernel version. Note that I had the idea of packaging alsa myself, but I wanted to discuss these issues first... What do others think about this problem ? -- Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What version of glibc in Hamm?
Dale Scheetz writes: > > Will this upgrade not imply that we recompile and test the whole of > > the dist, to make it sure hamm is self-compilable ? If not, every > > bugfix upload will possibly break something because of a possible > > glibc change... > > You may be confusing 2.0.7 with 2.1.X, which is getting many changes. I'm afraid not. Some time ago, I was still using 2.0.6 for my uploads, 'cause I don't like this idea of a pre-release in hamm, and was waiting for a final version to come. I was then reported a bug because e2fsprogs did not compile with 2.0.7pre1 ! This turned out to be a change in include files, for which Ulrich assumed that user-level programs should (usually) not include files from . This type of things makes me think we have a high probability of getting into trouble once more... > The 2.0.7 CVS tree is still accepting bug fix patches, so the only > difference between 2.0.7pre3 and 2.0.7 will be that more of the critical > bugs on glibc will be fixed. Even those programs that show bugs with the > current glibc will probably not need recompiling to gain the fixes in the > shared libraries. Maybe, but 2.0.7pre3 is not what we have in hamm. It's pre1. I don't see it as a good idea to switch from pre1 to final while in the deep freeze. > [on Debian] the upgrade from 2.0.6 to 2.0.7 goes very smoothly. Nice to hear that, anyway. -- Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ftp server layout
Michael Meskes writes: > Could anyone please tell me why mysql (including the server) is located > under devel? > > Postgres is under misc which is not so good IMO either. How about adding a > new subdir database or somesuch? Seconded. This lack has already been pointed out to without success... -- Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
