Re: Josselin Mouette and Planet Debian
On Thu, Dec 18, 2008 at 08:28:21PM +0100, Romain Beauxis wrote: > And if the jokes don't make you laugh, just ignore them. Which of course would be easier to do if the jokes were not told in the first place. There's a time and place for everything, it's a shame that a few seem to think that this list is one of them. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DebConf10 to take place in New York City, USA
On Thursday 26 February 2009 08:08:50 Mike Hommey wrote: > On Wed, Feb 25, 2009 at 02:31:24PM -0500, Jimmy Kaplowitz wrote: > > Further, we're definitely going to be giving people invitation > > letters and other advice to make sure they present themselves in > > the best (accurate) light they can to the visa or border officials, > > as well as separate exaggeration from fact with regard to border > > search and other privacy concerns so that people can make rational > > decisions based on reality instead of sensationalism. > > Sensationalism like > http://www.schneier.com/blog/archives/2008/08/us_government_p.html > http://www.schneier.com/blog/archives/2008/05/crossing_border.html > ? Mr. Hommey, I doubt Mr. Kaplowitz has the power to do anything much about the issues you use someone elses blog to bring into the conversation, no doubt you have more clout to shape the french governments policies. I would like to share this with you though. Ten years ago I married an English lady and moved to the UK. I didn't bring my computers with me as i planned to buy some when I settled, I did however bring disks, linux cd's, etc. Immigration here insisted on knowing where my computers were so that that they could inspect them...whether I had shipped them ahead or they were coming later. It took hours and hours. I found the whole matter very comical on one one hand and very sad on the other. This was some ten years ago and pre 9/11. My point is, in case you missed it, is that the United States is not the only country in the world who has such policies in place. If you doubt my point, stick your laptop in a backback and come over to the UK. I've used Debian for about ten years now, always been proud to say I used it. In the course of the past few years though, the bickering on the lists (particularly the political cheap shot like you just took) have really worn on me. As I said, I'm just a normal user. Nobody important, I mainly just read the list, help out at my local lug with Debian installs and recommend Debian to everyone that asks about linux. Your post though is pretty much the straw that broke the camels back. I want to read and talk about linux and Debian. Until DD's like you learn to leave the political sht at the door and just discuss issues relevant to Debian, I'm off to another distrobution. And don't worry, I won't let the door hit me in the ass on the way out. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687714: general: when trying to mount usb devices get not authorised error
Package: general Severity: normal Dear Maintainer, -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120915113745.4601.37373.reportbug@Woodlawn.WORKGROUP
ZFS in Buster
Dear Debian developers, ZFS 0.8 has been released with lots of improvements, notably encryption. Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0 that prevents ZFS from using SIMD. The result is that ZFS won't be usable in Buster. See the following issue https://github.com/zfsonlinux/zfs/issues/8793 NixOS reverted that particular commit: https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop Debian is the "Universal Operating System" and gives the user the option to choose. It provides "vim and emacs", "Gnome and KDE", "Linux, Hurd, KfreeBSD, etc.". I think that Debian should also provide the option to use ZFS with encryption. Would it be possible to provide an alternative patched linux kernel that works with ZFS? The ZFS developers proposed the Linux developers to rewrite the whole ZFS code and use GPL, but surprisingly the linux developers didn't accept. See below: https://github.com/zfsonlinux/zfs/issues/8314 Best, Daniel
Re: ZFS in Buster
Hi Ian and Jonathan, On Tue, May 28, 2019 at 10:26 PM Ian Jackson wrote: > > I think this would be both unwise legally (without seeking additional > legal advice) and rather rude to the kernel upstream whose code is > then being reused without permission - indeed, contrary to their > explicitly stated intent. > > We alread sought legal advice, with resulted in the halfway-house that > we can ship ZFS in contrib. Thanks a lot for you quick response and explanation. Best, Daniel
Re: ZFS in Buster
Hi Jonathan, On Tue, May 28, 2019 at 8:50 PM Jonathan Carter wrote: > On 2019/05/28 18:43, Dan wrote: > > ZFS 0.8 has been released with lots of improvements, notably encryption. > > Yep, it's an exciting feature. > > > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0 > > that prevents ZFS from using SIMD. The result is that ZFS won't be > > usable in Buster. See the following issue > > https://github.com/zfsonlinux/zfs/issues/8793 > > Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on > buster. My message was not accurate. I think that the commit has been introduced in in 4.19.38 (released 2019-05-02). I think that Debian Buster uses 4.19.37 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.38 The commit also affects ZFS 0.7 because SIMD is used for checksum operations. There might be a performance penalty in ZFS only if Debian Buster upgrades to 4.19.38. Best, Daniel
Re: ZFS in Buster
Hi Mo and Theodore, On Sun, Jun 2, 2019 at 4:04 AM Theodore Ts'o wrote: > Also, it's not accurate that "linux developers didn't accept". Ryan > sent a query to Linus, and Linus didn't respond. I don't know if he > sent a single message, or whether he retried a couple of times. A > failure to respond is not the same as a rejection. There are plenty > of reasons why Linus might not have responded. Without a long-term agreement between the Linux Kernel and the OpenZFS project the whole community will suffer. Opensource is about finding paths to collaborate. Now lustre is based on ZFS, this kernel regression will impact the HPC community. I'm not a lawyer, but I think that OracleZFS benefits from the improvements made by OpenZFS. If there is an agreement between the Linux Kernel and the OpenZFS project to convert OpenZFS to GPL, then Oracle won't benefit any more from OpenZFS and they will be forced to release the original ZFS code as GPL. Below you can find an excerpt from the GitHub discussion. On Jan 19 , 2019 Ryan wrote: > Recent events WRT Linux 5.0 have made me reconsider user requests > to pursue mainline inclusion. Linus Torvalds told me in person in 2014 > that he requires signed off from Oracle to merge the code. > That is not happening, but it occurs to me that it should be possible to > replace all Oracle copyrighted kernel code with new code over a long > period of time (several years). This would bypass the need for Oracle’s > signed off. It would also give us the ability to switch the kernel module > to a dual CDDL/GPL. > I suspect that the Illumos community would find the GPL > (or even the LGPL) more acceptable than a BSD license. When > Illumos was started, they stated that they do not want Oracle to be > able to use their code without Oracle giving their changes back. I understand that ZoL would like to convert OpenZFS to GPL, but they will need the help and support of the Linux Kernel developers. On Mon, Jun 3, 2019 at 4:47 PM Mo Zhou wrote: > > 0.7.12-2 works with 4.19.37, but it will be badly broken when the first > point release of Buster is out. Foreseeable stable RC is grave enough: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929 > This Linux kernel regression will break lot of computers and people might loose data. Most of the users will have no clue why their computer is not working and will blame Debian and the opensource software. Best, Daniel
Bug#1074176: packages.debian.org: allow seeing files
Package: general Here we are looking at a list of files, https://packages.debian.org/experimental/amd64/gdal-bin/filelist but cannot click them to see their contents.
Re: Bug#1074176: packages.debian.org: allow seeing files
Thanks. But: The older page needs to mention the newer page, else people who end up on the older page will think that that is all they are allowed to see. In fact the older page should use the links from the newer page, to make its flat list clickable. Also both pages don't have any file dates. That is mainly why the reader came there, to see how old the files are. Sure, there is a VERSION file, but no date on it either. Anyway: so the entire website needs to use ls -og to show the dates. Yes, "dates aren't reliable", but no dates are worse. On Mon, Jun 24, 2024 at 09:47:15AM -0700, Soren Stoutner wrote: > You are probably looking for this URL: > https://sources.debian.org/src/gdal/3.9.1~rc2%2Bdfsg-1~exp1/
Bug#278940: ITP: socket++ -- lightweight convenience library to handle low level BSD sockets in C++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist * Package name: socket++ Version : 1.12.12 Upstream Author : Gnanasekaran(Sekar) Swaminathan <[EMAIL PROTECTED]>, Herbert Straub <[EMAIL PROTECTED]> * URL : http://www.linuxhacker.at/socketxx * License : Pasted below with License Statement Description : lightweight convenience library to handle low level BSD sockets in C++ Socket++ library defines a family of C++ classes that can be used more effectively than directly calling the underlying low-level system functions. One distinct advantage of the socket++ is that it has the same interface as that of the iostream so that the users can perform type-safe input output. See your local IOStream library documentation for more information on iostreams. . Development of the original socket++ died some years ago, and a new upstream has taken control. The original socket++ ended at version 1.11. Lauri Nurmi modified the source code to make Socket++ compile with recent GCC under linux. This version is fork of the code from Lauri Nurmi which was just some enhancements to make it standard conforming at version 1.11. - -- License Original Copyright Notice: Permission is granted to use at your own risk and distribute this software in source and binary forms provided the above copyright notice and this paragraph are preserved on all copies. This software is provided "as is" with no express or implied warranty. Copyright Statement: > > Got your message. Please feel free to include it in > any software and use it as you please. Let me know if > you need any help with it. and further: +++ Hi Herbert, That was not the intention. It is a free code. You can modify, copy, and distribute and use it in anyway as you see fit. Other people are maintaining it and ported it to different OSes. Other than that, not much has changed as far as I know. I haven't looked at it recently. - -Sekar - -- Side Note This ITP is being cross posted to debian-legal for the purpose of verifying that this is capable of being placed in main. Dan Weber - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (499, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8.reiser4.vserver Locale: LANG=en_US, LC_CTYPE=en_US -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBg6qkF6i3K/AxoQERAp42AKClgh7dXmH/48TeuORsCqKq6d25bwCfdAjg CcC0AqjCdXGesDg92Q20Irs= =TPT8 -END PGP SIGNATURE-
Bug#279175: ITP: goobox -- CD player and ripper for GNOME
Package: wnpp Severity: wishlist * Package name: goobox Version : 0.3.0 Upstream Author : Paolo Bacchilega <[EMAIL PROTECTED]> * URL : http://ftp.gnome.org/pub/GNOME/sources/goobox/ * License : GPL Description : CD player and ripper for GNOME Goobox is an CD player and ripper for GNOME 2 environment. It follows the "Just Works" principle so its interface is beautiful and easy-to-use. . It uses GNOME/GTK+ for its user interface, GStreamer framework for CD playing and ripping operations and neon library to search album cover images with Google. . Homepage: http://ftp.gnome.org/pub/GNOME/sources/goobox/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
add Date: field to Packages files
Say, perhaps a "Date:" field could be added to Packages files. I mean even dog food has the date stamped on it these days. Even my crumby message has a Date: field. Sure, as your eyes scan the MD5sum: field, the package's DNA is registered in your brain. But us old fashioned types would still like a Date: field. > Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz But Mom said no more searching the web for dates, so now I'm offline.
Re: add Date: field to Packages files
I challenge you to tell me the dates of the packages using just the Packages file. The best you can do is $ grep-available -F version 200 -s Version|wc -l 1207 But that still leaves $ grep-available -F version 200 -vs Version|wc -l 15127 packages that don't put the date into their version numbers. Off line with just the Packages file, you can't tell a dusty 1997 package from an up to the minute state of the art package.
list generated conffiles?
>> Shouldn't all the files in /etc/lynx-cur be listed, and as conffiles? >> $ dlocate /etc/lynx-cur/|wc -l >> 1 >> $ ls /etc/lynx-cur/|wc -l >> 21 A> I believe no, they shouldn't be listed. A> Only /etc/lynx-cur/lynx.cfg is shipped with the package A> (so conffile) but the rest are generated with postinst A> of lynx-cur-wrapper (so they are configuration files). Should I file a bug against $ man dlocate -conf list conffiles in package saying to mention in the man page the cases when conffiles might not be listed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293561: ITP: player -- music player and organizer for GNOME
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: player Version : 0.1pr1 Upstream Author : Milosz Derezynski <[EMAIL PROTECTED]> * URL : http://linux-media.net/player/ * License : GPL Description : music player and organizer for GNOME Player is a graphical music player and organizer for GNOME 2 desktop environment. It uses GTK+ for its user interface, GStreamer for playback and SQLite for working with music database. (expect packages soon on http://mentors.debian.net/, we still need libvisual to be packaged and uploaded.) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i586) Kernel: Linux 2.6.10-1-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293561: ITP: player -- music player and organizer for GNOME
On Fri, 2005-02-04 at 13:39 +, Steve McIntyre wrote: > >* Package name: player > > Description : music player and organizer for GNOME > Please use a less generic name. "player" alone means very little and > is likely to cause confusion. Yeah, I already thought about it. I'll probably name the final package something like player-gnome or player-gstreamer. Really, I'm going to talk with upstream about it. -- Dan Korostelev <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
mirror the Packages files _after_ the packages!
I know you Debian people think it's just hilarious when users try to apt-get upgrade during the period after when the Packages files arrive on the mirrors, but before the packages they describe have fully arrived. "Haw haw haw, try again later", you say, never thinking that maybe writing the Packages files last would be the right thing to do. "The problem can't persist more then a couple of hours, what's the big deal?" Well, the connection to mirror-upstream broke mid-mirror-push this time during Chinese New Years. Perhaps 10 days before the system administrator will be back in the office to see what happened. "Haw haw haw, try another mirror. Haw haw haw." The other local mirrors have the same problem, and their system admins are also on vacation. Foreign mirrors are on slow links. So not fixing bug 6786 (just write the [EMAIL PROTECTED] Packages file after writing the packages) causes users' apt-get upgrades to fail needlessly... down for 10 days. Great. The Debian whippersnappers don't see the danger of needlessly leaving mirrors in a broken state "for only a couple of hours a day, what's the big deal" ... well if the mirror mechanism breaks during this broken state, then "couple of hours" becomes indefinitely. I can't think of any other case in Computer Science where one updates a descriptor before updating the thing described!!! How can you defend that??? No smug remarks can defend that! "Never bothered me", yeah well wait until you are giving your next apt-get upgrade demonstration and now it's too late, you did apt-get update && apt-get upgrade instead of apt-get upgrade && apt-get update && apt-get upgrade and now you have to tell the class to "wait a couple of hours" until you can show them anything. Yeah I know, "the more I complain, the more it's not going to get done." OK, can somebody send me the section of code so I can fix it then? Err http://xx.linux.org.xx sid/main 404 Not Found Failed to fetch http://xx.linux.org.xx/debian/pool/main/x Fetched 26.6MB in 2m39s (167kB/s) E: Some files failed to download Error 100 P.S., "a couple hours" is for your fancy mirror's connections. Some mirrors far away might be in the broken state (Packages* arrived, not all packages arrived) for half a day each day! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package xxx has broken dep on yyy: normal?
Upon apt-get, is it normal to every so often see "Package xxx has broken dep on yyy"? However the next day the problem is gone. If normal, then can't whatever intermediate stage not be split across the mirror push? Somehow can consistent versions of xxx and yyy either be made sure to go out this mirror run together, or both wait for the next run? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mirror the Packages files _after_ the packages!
S> You've been told this before -- *debian-devel does not control the mirroring S> implementation used by arbitrary Debian mirrors*. Either talk to the mirror S> team and give them enough information to track this down, or -- since you S> know him well enough to be kept in the loop about his vacation schedule -- S> talk to your local mirror operator directly and get him to stop using broken S> mirroring scripts. I'm saying that bug 6786 has the potential to turn the current perhaps two hour per day down time for apt-get, aptitude, etc. into a several day long down time. D> > Failed to fetch http://xx.linux.org.xx/debian/pool/main/x S> Yeah, real helpful of you to blot out the only potentially useful bit of S> information in your post... No. The root of the problem is bug 6786. Indeed if 6786 were fixed, the mirror process could break at any time and users could still apt-get upgrade with yesterdays state instead of not being to apt-get upgrade at all (if the mirror process happen to break during the 2 hour dark period each day.) Indeed, no 2 hour dark period necessary too. Please double check 6786 to see if it is merely a local problem. Would you close it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mirror the Packages files _after_ the packages!
Jeroen> Debian could promote this two-phase mirroring a bit more Jeroen> maybe, and/or provide nice scripts, that's probably why #6786 Jeroen> is still open. I suppose Debian is promoting one-phase mirroring and two phase mirroring is "roll your own". If you want me to tell my administrator to do something, I need something succinct, like "apt-get install two-phase-mirroring". Jeroen> #6786 doesn't need to be fixed for this, the mirror admin of Jeroen> xx.linux.org.xx just needs to implement two-phase mirroring, Jeroen> something that anyone with a bit shell/rsync foo can implement on Jeroen> his/her own, and ttbomk, already a lot of mirrors actually _do_. If this two-phase-mirroring is the way to go, then there ought to be a standard package to do it. How can there be 1+ packages but no package to make sure the 1+ packages get mirrored properly? Any approved recommended debugged method would certainly have its own package, where the administrator would merely enter some configuration parameters in some /etc file. Does http://www.debian.org/mirror/ at least have the two-phase-mirroring script? Is there any official documentation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
M> Dan Jacobson [12]wondered about the broken dependencies he notices M> every now and then. Colin Watson [13]answered that this is the M> problem that the testing distribution is intended to solve. Goswin M> Brederlow [14]explained that this is caused by strictly versioned M> dependencies to binary-all packages. Well I like sid, but am not used to Package gpe-contacts has broken dep on libgpevtype0 Try to Re-Instate gpe-contacts lasting for days into weeks. Goswin's post implied that such problems should only last a day or two. How is it that such problems are allowed to persist for days into weeks? Isn't there a feedback mechanism to prevent developers making the archive "unstable" permanently unknowingly? A couple of days isn't so bad, but apparently users often have to remind developers what mess apt-get shows they have turned their dependencies into otherwise they are oblivious? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354417: general: "You have new mail" but how to read?
Package: general Severity: wishlist Often new users encounter You have new mail in /home/nordsburg/Maildir/ $ mail mail: /home/nordsburg/Maildir/: Is a directory One sees it often. At least the reminder mechanism, knowing where the mail is hidden on the system, could also give a hint in its message of at least one basic way of reading ones mail. Otherwise one can just cd ... ls ... cd ... ls ... cat. Anyway, apparently it is so easy for system administrators to turn their system into a Maildir system, leaving users in the lurch. Bash's MAILPATH's custom messages in /etc/profile perhaps is a candidate, but is it applicable to directories? And then it must get pasted into /etc/profile. $ apropos Maildir maildir: nothing appropriate. $ apropos mail|wc -l 172 $ apt-cache search maildir|wc -l 67 Then I suppose he would use dlocate -l to see which of those were installed. Anyway, by now our grandma's initial joy at "You've got mail!" will surely be her last. Anyway, it's too easy for a Debian system to end up this way. Perhaps make dependency/alternatives between Maildir enabled clients and servers? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292645: ITP: gnomeradio -- FM radio tuner for GNOME
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: gnomeradio Version : 1.5 Upstream Author : JÃrgen Scheibengruber <[EMAIL PROTECTED]> * URL : http://mfcn.ilo.de/gnomeradio/ * License : GPL Description : FM radio tuner for GNOME Gnomeradio is a FM radio tuning program for GNOME desktop environment. It uses GTK+ 2 technology for user interface and video4linux drivers for actual FM tuning, so it'll work with any FM radio tuner, supported by v4l. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i586) Kernel: Linux 2.6.10-1-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Bug#292907: ITP: libtranslate -- library for translating texts and webpages
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: libtranslate Version : 0.99 Upstream Author : Jean-Yves Lefort <[EMAIL PROTECTED]> * URL : http://www.nongnu.org/libtranslate/ * License : DFSG-compilant Description : library for translating texts and webpages libtranslate is a library for translating texts and web pages between natural languages. It's shipped with generic module supporting web-based translation sevices such as Babel Fish, Google Language Tools and SYSTRAN. (Expect packages on http://mentors.debian.net/) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i586) Kernel: Linux 2.6.10-1-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
why allow broken packages to get all the way to mirrors?
It seems there are only minimal checks, so developers can unwittingly upload broken packages. Wouldn't a nightly $ for package in all_of_debian do apt-get --print-uris install $package; done > /dev/null 2>errors_for_inspection done at Debian Headquarters 'catch' them before they are allowed to go on to the mirrors? Even if the package is only "broken until tomorrow, whereupon the upload will be complete", that too should not be allowed to propagate to the mirrors until ready. Package has broken dep on : Why isn't this same apt-get check that the user does, also get done beforehand by the archive patrol? For instance, let's say we are a food company. Why not check to see if the food is rotten before it gets to the consumer? With an apt-get dependency test done on the archive server, we can easily perform the same 'sniff test' the consumer does before he puts our products in his mouth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intersection of installed packages with orphaned packages
Stephen Quinney <[EMAIL PROTECTED]> writes: > On Fri, Apr 08, 2005 at 07:14:23PM +1000, Matthew Palmer wrote: >> On Fri, Apr 08, 2005 at 02:12:13AM -0700, Stephen Birch wrote: >> > I am interested in the intersection of packages installed on my >> > machines with the list of orphaned packages. >> >> You'd be wanting wnpp-check, in the devscripts package. Check out rc-check >> while you're at it. Both are cronable. > > I think you mean wnpp-alert and rc-alert (at least that's what they > seem to be called on my sid machine). On my systems, wnpp-alert lists packages that I don't have installed. For example: # wnpp-alert ... O 279824 perlftlib -- Perl module for the FreeType library ... # dpkg -l \*perlftlib\* No packages found matching *perlftlib*. Any idea why this might be happening? Thanks, Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intersection of installed packages with orphaned packages
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: >> On my systems, wnpp-alert lists packages that I don't have installed. >> For example: >> >> # wnpp-alert >> ... >> O 279824 perlftlib -- Perl module for the FreeType library >> ... >> # dpkg -l \*perlftlib\* >> No packages found matching *perlftlib*. > > perlftlib is a source package, producing the binary packages fttools and > libft-perl. I guess you have one of these two installed. Thanks, I suspected something like that. Wouldn't it make more sense for wnpp-alert to list the binary packages that are installed? What's the command to find out which binary packages a source package produces? Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304941: ITP: gnome-art -- install GNOME themes from art.gnome.org
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: gnome-art Version : 0.1 Upstream Author : Michael Gebhart <[EMAIL PROTECTED]> * URL : http://www.miketech.net/gnome-art/ * License : GPL Description : install GNOME themes from art.gnome.org Gnome Art is a tool for downloading and installing GNOME themes from http://art.gnome.org/ website. It provides a nice theme list with options to preview, download and install them. . Homepage: http://www.miketech.net/gnome-art/ -=- Preview packages are available on http://mentors.debian.net/. This source package also generates a gnome-splashscreen-manager package that is a splash screen selector for gnome-session. Any comments welcome. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.8-10-amd64-k8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305753: general: 38 packages still use "Origin: debian"
Package: general Severity: minor It feels odd that a handful of packages seem to use a dusty field: $ grep ^O /var/lib/dpkg/available|sort|uniq -c 3 Origin: Debian 35 Origin: debian Shall I clone this bug to them to get them to take it away? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305753: general: 38 packages still use "Origin: debian"
Agney> mass bug filling is the worst way to do this. try to send a wishlist for Agney> lintian and linda. So on the next time that these packages use them the Agney> mantainers will be alerted about this. Naw, on 220098: 39 packages unnecessarily still use "Bugs: debbugs://bugs.debian.org" I was told to do it, and it worked out OK. I would also wishlist it to lintian and linda. Thijs> Perhaps you can state in your bugreport why it is needed to fix this. What Thijs> problems does that field cause? I think they just need to delete a line somewhere. I assume Origin isn't necessary for these packages to say anymore. Anyway, "just sticks out, looks funny, feels bad"... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305753: acknowledged by developer (closing 305753)
m> You should be hearing from them with a substantive response shortly... Why was it closed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305753: general: 38 packages still use 'Origin: debian'
S> What information do you have that tells you that the Origin field S> is obsolete? No. I'm saying I feel/guess/believe "Origin: debian" is obsolete, not that "Origin:" is obsolete. I'm sure "Origin:" still has good uses. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308101: ITP: gstreamer0.8-pitfdll -- DLL/QTX loader plugin for GStreamer
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: gstreamer0.8-pitfdll Version : 0.8.1 Upstream Author : Ronald Bultje <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/pitfdll/ * License : GPL Description : DLL/QTX loader plugin for GStreamer Pitfdll is a GStreamer plugin that allows the use of binary files, such as Quicktime QTX or Directshow/DMO DLL files, for use as a playback codec in GStreamer-based media applications, such as Totem. With this plugin, people can playback proprietary file formats for which no free software implementation exists yet. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages are available for testing (was: Bug#308101: ITP: gstreamer0.8-pitfdll -- DLL/QTX loader plugin for GStreamer)
Hello people! I uploaded fist pitfdll package to http://mentors.debian.net/ Feel free to check it out and report any problems with it. The source package name is "pitfdll", the resulting binary package is "gstreamer0.8-pitfdll". And don't forget to read the README.Debian. PS Looking for sponsor for the package! :-) -- Dan Korostelev <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#310258: ITP: nautilus-open-terminal -- open terminal in any folder from Nautilus
Package: wnpp Severity: wishlist Owner: Dan Korostelev <[EMAIL PROTECTED]> * Package name: nautilus-open-terminal Version : 0.2 Upstream Author : Christian Neumair <[EMAIL PROTECTED]> * URL : http://manny.cluecoder.org/packages/nautilus-open-terminal/ * License : GPL Description : open terminal in any folder from Nautilus This is an extension for Nautilus (file manager for GNOME desktop) that provides a menu option for any local folder object to open a terminal in that folder. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
so many applications wake up so often
Using strace, I discovered many programs are constantly busy these days. No wonder one can't seem to save power. There ought to be a law... = Subject: Re: silent PC vs. emacs Newsgroup: gmane.emacs.pretest.bugs From: Dan Nicolaescu <[EMAIL PROTECTED]> ...The OLPC/Fedora people are working on eliminating application wakeups in order to save power. I cite here from one of the bug reports about this: "We're working with RH engineers on a tickless idle kernel, which has the goal of reducing power and hypervisor loads when the system is idle. This is done by removing the regular ticking clock when the system is idle, so that in theory long sleep periods are possible for the hardware (or hypervisor). The kernel portion of this works great, however when using a gnome desktop there are many however when using a gnome desktop there are many timers going off all the time for userspace, so many that the actual savings are not so great (about 250 events per second)." Given that so many applications wake up so often, what emacs does might not be measurable at this point, but it might make a difference in the future. (If anyone is interested in more details, the bug tracking this activity is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204906 ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388586: /etc/profile contains PATH=/usr/bin/X11...
Package: general Severity: minor $ reportbug -f /etc/profile Finding package for '/etc/profile'... No packages match. No package specified; stopping. 1. No way to tell how /etc/profile got on my system. 2. All I know is it contains PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games" and /usr/bin/X11 is merged so should be deleted. -- System Information: Debian Release: testing/unstable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Simpleminded members better than abusive members
I used to work at Bell Labs. There was a very large management training effort to correct things like abusive behavior between co-workers, etc. You might say that that was a profit making company, and Debian is not, but I am sure the values still apply. http://bugs.debian.org/390564 was my suggestion, based on http://bugs.debian.org/389892 Abusive members give the message that no interaction is welcome. Bug reports and fixes will be few. Development stifled. A wall built. Simpleminded co-workers do not hurt the organization as much as abusive co-workers. You might want to have related workshops at the next Debian conference or seminars. The leadership team should get involved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bet there are no senior citizen developers
Bet there are also few developers over 45 years old. Probably 99% young, male. Bet there is no web page with developer age demographics. Anyway, at 45 things get fuzzy, at least for me, so I admire those older developers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pretty girl
howcome nobody talks anymore love lda Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Bug#365918: general: /tmp became 0755 durning sid upgrade
Package: general Severity: minor Somewhere during an hours long apt-get dselect-upgrade, some package, I can't tell which, changed the permission of /tmp from 1777 to 755. stat(1) at best reports the time some file was moved in or out of /tmp, obscuring the time of chmod, so I can't check in dpkg.log. grepping in /var/lib/dpkg/info didn't help. -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366893: init.d stopping messages not standardized or even always logged
Package: general Severity: wishlist Looking at the myriad ways of starting messages in /var/log/boot, Starting X TrueType font server: xfstt. Starting /usr/sbin/chronyd... Starting anac(h)ronistic cron: anacron. Starting deferred execution scheduler: atd. Starting periodic command scheduler (especially that last mystery program one), got me looking at start/stop messages. Stop messages for example: We see poor convergence of start messages in /etc/init.d: $ cd /etc/init.d/ $ grep -i stopping * acpid: echo -n "Stopping Advanced Configuration and Power Interface daemon: " apache2:log_begin_msg "Stopping apache 2.0 web server..." atd:log_daemon_msg "Stopping deferred execution scheduler" "atd" bind: echo -n "Stopping domain name service: named" bootlogd: log_daemon_msg "Stopping $DESC" "$NAME" cpufreqd: log_daemon_msg "Stopping $DESC" "$NAME" cron:stop) log_begin_msg "Stopping periodic command scheduler..." cupsys: echo -n "Stopping $DESC: $NAME" cwdaemon:echo -n "Stopping $DESC: $NAME" dbus-1: echo -n "Stopping $DESC: " etc. Also even $ grep --files-without-match -i stopping [a-z]*|wc -l 66 Despite policy: When you stop or restart a daemon, you should issue a message identical to the startup message, except that `Starting' is replaced with `Stopping' or `Restarting' respectively. However, even policy's $ zgrep -i stopping policy.txt.gz echo -n "Stopping domain name service: named" isn't as systematic as echo -n "Stopping $DESC: $NAME" Therefore, policy should provide a better role model. However, I also notice that although there is a bootlogger to log all those starting messages, upon shutdown syslog or whatever is shutdown too early in the order of shutting things down, so that many of those "stopping" messages, or errors upon stopping, aren't logged at all! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving GFDL documentation to non-free
Hi. I'm just a lowly user with a bandwidth problem. Certainly was a shock to get back from town to find the documentation gone from the debs I brought back. However, I am to make one last trip to town so it's my one shot chance to download the new additional debs where that documentation now lies. I need to know the names of those additional packages though, so I can tell dpkg --set-selections. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving GFDL documentation to non-free
W> The usual package name is -doc. Just to be sure, W> you may want to check the changelogs of the packages with missing docs, W> however. $ w3m -dump http://packages.debian.org/unstable/doc/|fgrep '[non-free]' finds some. I suppose some aren't ready yet, like tar. At least it still has man pages, though no more info pages. I wish there was a more systematic way than digging thru changelogs. Something one could use in a script. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370050: general: /var/log/btmp permission should be 660
Package: general Severity: wishlist tiger says # Checking for existence of log files... --FAIL-- [logf005f] Log file /var/log/btmp permission should be 660 OK, now how do I even find out what package /var/log/btmp belongs to in order to tell them about the problem? dlocate? No. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RunDinstallHourly
Remember to make sure the Packages.gz files appear on the mirrors _after_ the packages they refer to are in place. Bug #217957. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
not starting packages at boot
Sure, one can go behind the backs of maintainers with
> http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.6
> ("Disabling daemon services")
and hope you remember what you did. But it's not as friendly as
the approaches more and more packages are taking, as seen in my /var/log/boot:
SpamAssassin Mail Filter Daemon: disabled, see /etc/default/spamassassin
hylafax is disabled, see /etc/default/hylafax
OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)
Not starting xprint: disabled in /etc/default/xprint
Not starting apache2 - edit /etc/default/apache2 and change NO_START to be 0.
We are still waiting for
281974 cupsys: allow not starting on boot
218040 fetchmail: no way to not start on boot permanently
Now that maintainers realized that one might like a package installed,
but perhaps only plans to use it unoften, it only makes sense for not
starting at boot to be offered as a friendly configuration option,
instead of needing some devious guerilla techniques to thwart the
packages starting.
Sure those tactics might work, but whatever you did isn't easy to see
as it is in /etc/default/.
That each package will have its own way of not starting in
/etc/default/ is because of disbelief that there needs a standard
mechanism to do this _that the user can encounter with
dpkg-reconfigure_, with the results stored in /etc/default/ etc. No
more monkeying with the links behind maintainers' backs, etc. Proof
that something visible upon dpkg-reconfigure is better is seen in the
more and more packages that are getting on the user friendly
bandwagon.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Perl vs Python vs ....
Ian Jackson wrote: > > We only have room for one `extra' scripting language, besides the > usual sh, awk, sed, &c, on the base disks. > > Perl is widely known. It can solve most problems. There are problems > for which it is difficult to get it to work, but these don't often > occur at installation time. > > sh is not suitable for many of the things Perl gets used for - > consider update-inetd, update-info &c. Actually, a /bin/sh script to add inetd.conf entries, and another to remove entries keyed off the service field, was unmentionably simple to code, and has proved quite reliable in (lots of) practice. > For this reason we decided that Perl would be on our base disks, and > that packages could use it (well, the subset that's on the base disks) > in their preinst/postrm. Packages which want something else must > Depend on it and may only use it in their postinst/prerm. There's clearly a place for a stronger scripting language, despite the argument posed above. It's just very sad that it should be perl. perl really fits into many people's stereotypes of "unix as inherently cryptic monster", very neatly. > There is no point having a religious war over this; this decision was > taken a long time ago and can't be changed now, even if we wanted to. This is rhetoric. It could be changed and you know it. What I mean to say is, I really dislike "can't" when what's meant is "won't". I daresay that a linux distribution (or the Hurd, or *BSD, or...) that doesn't fall into the perl trap, should have a brighter future. > Ian.
Re: Perl vs Python vs ....
Brian C. White wrote: > Dan Stromberg wrote: > > There's clearly a place for a stronger scripting language, despite the > > argument posed above. It's just very sad that it should be perl. perl > > really fits into many people's stereotypes of "unix as inherently > > cryptic monster", very neatly. > > I'm sure C and Assembler fit "cryptic" too. Just think how much further > advanced the computer industry would be if neither of those had ever been > invented. > > (that's sarcasm, by the way) And how much further would the industry be, if C had been typesafe (or if some other, typesafe language had been used)? The expertise in language design existed at the time, but C didn't have it. And yet, C was adopted as a major standard - because the people who knew better, didn't bother to speak up. That's not to say that a lot hasn't been accomplished in C - obviously. But we could have done a lot more, if such a simple thing hadn't been put off until ANSI. Also, the code I maintained on my first job, probably would've been a LOT cleaner - many of you are probably in the same boat. I really hated roaming around fixing somebody else's stray pointer references. In fact, I'm pretty sure I recall either K or R, saying that lint should have been just another pass of cc, instead of a separate program. That's a very small design-decision, but it's had a _H_U_G_E impact, for more people than a wanna think about. The choice of a languages is a rather larger decision. > > > There is no point having a religious war over this; this decision was > > > taken a long time ago and can't be changed now, even if we wanted to. > > > > This is rhetoric. It could be changed and you know it. What I mean to > > say is, I really dislike "can't" when what's meant is "won't". > > I daresay that a linux distribution (or the Hurd, or *BSD, or...) that > > doesn't fall into the perl trap, should have a brighter future. > > Oh, give it up! Perl is a fine language. Its powerful and is quite easy > to write nice clean code with. It's just not _enforced_ that you write assembler is powerful, and quite easy to write nice clean code with. It was hot stuff at its inception. sendmail is powerful, and quite easy to write nice clean header munging and mail routing with. It was hot stuff at its inception. perl is powerful, and quite easy to write nice clean small-scale scripts with. It was pretty old-news, at its inception. > nice clean code. It's also very easy to garbage code, but that isn't > enforced, either. > > As for the truth of your comment... Language syntax and symantics have > little to do with a language's success; it's how easy it is to write > useful programs with. An operating system's success is due primarily > to the amount of software available for it. (Don't believe me? Look > at MS-Dos!) Yes, yes, yes, and No, no, no. A language's success is typically 95% who backs it, and 5% how good it is. With the masses, that is. However, for a group that knows what it's doing, it should be 5% who backs it, and 95% how good it is. So it -should- be for debian. The debian project is in a more than adequate position, to set a more-positive direction for the unix industry. One way to do that, is to hang onto /bin/sh until something like guile is ready. Another way to do that, is to move beyond perl to something like python or ML (metalanguage) - right now. It wouldn't take much at all. Once the inertia's there, it's hard to change it. In fact, many people will become angry with you if you do. But it's often very worthwhile to take a step back, and look at the long-term ramifications of a decision.
Re: Debian, Linux, the FSSTND, the FHS and BSD
Ian Jackson wrote: > The latest draft FHS, which they may well publish as it stands, makes > the following changes with which I have very strong disagreements: > * The mail spool, /var/spool/mail, is moved to /var/mail. This is a positive thing. Both SVR4 and BSD 4.4 put it here. I think any contemporary unix should. > * /var/lib is renamed to /var/state (yes, all of it). > * /var/lib/games is moved to /var/games. > * A new directory /usr/libexec is created to hold command binaries > used only internally by programs - these are to be moved from > /usr/lib and in some cases /usr/sbin. Oddly there is no > corresponding /libexec directory. I don't really care about these. They're the sort of thing that dances around from one unix to the next anyway. > The two good changes that I see are (and they are not minor): > * /usr/share exists and is defined. > * /opt exists and is defined. These are nice. > [1] When the original FSSTND was created I argued in favour of > /libexec and /usr/libexec, but lost that debate. I'm less convinced > now than I was then, but my main reason for opposing it now is that it > is too late to change. Nah - we've always got to be careful about "it's too late now" syndrome. To think otherwise, is to plot a path to obsolescence. They oughta add /libexec, tho. Symlinks help, especially if you keep developers informed that usage Of those symlinks is deprecated.
Re: Bug#3961: 14 character file name limit in zoo
Martin Schulze wrote: > As zoo comes from DOS I'm not sure if it would be a good idea to > support long filenames. zoo comes from Rahul Dhesi, and was designed from the ground up to be cross-platform, albeit particularly for use with CBIP. The 14 character limitation is probably a rudiment of linux's roots in minix-386.
Re: libpaper 1.0 on master
Shouldn't the "paper size" be an attribute of a print queue, and not an attribute of a machine? Yves Arrouye wrote: > > Please do not use 0.* versions anymore. > > The next release (1.0-1) will have a paperconfig paper configuration > script instead of having /etc/papersize as a conffile. > > Yves. > > -BEGIN PGP SIGNED MESSAGE- > > Date: 13 Aug 96 17:16 UT > Format: 1.6 > Distribution: unstable > Urgency: Low > Maintainer: Yves Arrouye <[EMAIL PROTECTED]> > Source: libpaper > Version: 1.0-1 > Binary: libpaper > Architecture: i386 source > Description: > libpaper: Library for handling paper characteristics > Changes: > * abstract interface (struct paper hidden) so that future changes > can be made safely. > * stores dimensions as double, still in PS points. > Files: > 6b55151261dc94a835e7581fa4c894dc 55776 text - libpaper_1.0-1.tar.gz > 7d7feddde35dcf7f83a6096097ebc997 25340 text optional > libpaper_1.0-1_i386.deb > > -BEGIN PGP SIGNATURE- > Version: 2.6.2i > > iQCVAwUBMhC4aQjpU7xgQoo9AQHK0gP/bD6Pd7Ab3VvzfXI+ikvJ9g/UMZrjaaSJ > CZt7f1m3DDZAoKlwhiZGzZGoJzKFkWaqwlMl6tis7hZjOWOXjFeWeGMpxQl/nhpO > j+SUKANSXAj/p2iCoryTm2dC1+RuAo6lkxu298wlCMPyJb6V2ts8XhhPaxejE2ST > fLxdzD2Rp0w= > =vXPH > -END PGP SIGNATURE-
Re: CC's on this mailing list
Mr Stuart Lamble wrote: > All very nice, but it dodges the major reason for people disliking duplicate > copies of messages: they pay for their PPP link (or UUCP feed, or whatever). > Identifying duplicates by their message IDs means that you have to download > both messages, unless you can do the filtering at your ISP's end of the link. > > I'm not overly concerned personally at the moment - I'm at university, and > the government pays for my feed :-) - but it's generally not good etiquette > full stop. Bandwidth prices have dropped quite healthily in recent years, and they are going to continue to do so. Rambling on about being cc'd, when the bandwidth prices are still dropping, and YOU HAVE alternatives, is silly at best. Those of you who've been going on and on about this, consuming far too much human-time (on this already excessively voluminous list) : 1) Have you switched up to a 28.8kbps modem yet, or at least a 14.4kbps modem? Yes, modems cost money, but shelling out a little for a modem now may save you heavily in bandwidth if you transfer much data - and would save you a lot more than badgering people about cc'ing. 2) Are you transferring your mail gzip'd? If not, why not? Have you bothered to look for an ISP that will help you do this? This too would save you a lot more than badgering people about cc'ing. 3) Have you bothered to look for an ISP that will do upstream filtering? Have you even bothered to ask your current ISP if they'd be willing? If you want to do all your interaction with the internet over a low bandwidth link, and you're concerned about bandwidth costs, then this SHOULD be a deciding factor in your choice of ISP. This also, would save you a lot more than badgering people about cc'ing.
Re: libpaper 1.0 on master
Storing one thing in one place is an excellent goal. Treating multiple things as tho they were one thing (EG "all printers use the same paper) can be troublesome. Ideal: keep the option of an /etc/papersize, but allow a user to override /etc/papersize if desired, thru ~/papersize or environment variables. Richard Kaszeta wrote: > > >Shouldn't the "paper size" be an attribute of a print queue, and not an > >attribute of a machine? > > Paper size effect more that just printers. Previewers and tex tools > come to mind, there may be others... > > All I know is right now I've got to tweak quite a few things on a > standard debian 1.1 system so that dvips, xdvi, genscript, and a few > other programs work well and have the same idea of a default paper > size. > > -- > Richard W Kaszeta Graduate Student/Sysadmin > [EMAIL PROTECTED]University of MN, ME Dept > http://www.menet.umn.edu/~kaszeta
Re: libpaper 1.0 on master
joost witteveen wrote: > > > > > >Shouldn't the "paper size" be an attribute of a print queue, and not an > > >attribute of a machine? > > Well, it could be argued that Yvess libppaper could look at > the current $PRINTER setting, and select the correct papersize > depending on the /etc/papersize.printer file or something. But > at the moment not very many programmes use libpaper or /etc/papersize, > so it's better to have them at least get to recognise a global > /etc/papersize than nothing. Yup, sometimes something is better than nothing. Then again, sometimes "something part way" makes it harder to get to "all the way" too. If you make it queue-specific, it might be best to add it into /etc/printcap (as opposed to /etc/papersize.queuename). There is precedent for this (with at least one printer I've set up), and it's discussed in at least one popular book about system administration (by Evi Nemeth, under the name "printcap extensions"). BTW, this book lies thru it's teeth about Solaris 2.x, Parsing /etc/printcap is a simple matter - 20 lines of /bin/sh, or pgetent in the lpd source. An external library, such as libpaper.*, is precisely the right place to put such a thing. AS long as it has a good'n'general interface, the long-term nice-scenario get here eventually. > > Paper size effect more that just printers. Previewers and tex tools > > come to mind, there may be others... > > > > All I know is right now I've got to tweak quite a few things on a > > standard debian 1.1 system so that dvips, xdvi, genscript, and a few > > other programs work well and have the same idea of a default paper > > size. > > Well, after you've done the tweaking, maybe it's worth the little > extra efford of mailing the patches to the maintainer/bug-system > and wait to see them included in the next release? > If you don't want to do that, could you send your patches to me, > so that try to handle it?
Re: what happened to x11amp
Hi Kenneth, Where have you been? X11amp is now xmms. The package has been changed accordingly. On Fri, Oct 01, 1999 at 06:57:08PM -0700, Kenneth Scharf wrote: > I went to look for the sources to X11 amp on > ftp.debian.org and they are missing. I remember > downloading the source packages a few months ago, but > now a package search on debian.org shows them missing. > What happened? > > -- Dan Nguyen | It is with true love as it is with ghosts; [EMAIL PROTECTED] | everyone talks of it, but few have seen it. [EMAIL PROTECTED]| -Maxime De La Rochefoucauld 25 2F 99 19 6C C9 19 D6 1B 9F F1 E0 E9 10 4C 16
ITP: eog
Hello, I will be packaging eog (Eye of Gnome). Package: eog Priority: optional Section: graphics Version: 0.2-1 Description: The Eye of Gnome graphics viewer and cataloging program Gnome is the "GNU Network Object Model Enviroment" . The Eye of Gnome, an image viewer program. It is meant to be a fast and functional image viewer as well as an image cataloging program. -dan -- Dan Nguyen | It is with true love as it is with ghosts; [EMAIL PROTECTED] | everyone talks of it, but few have seen it. [EMAIL PROTECTED]| -Maxime De La Rochefoucauld 25 2F 99 19 6C C9 19 D6 1B 9F F1 E0 E9 10 4C 16 pgpLqJqxm83RY.pgp Description: PGP signature
Re: ITP: eog
On Mon, Mar 20, 2000 at 12:12:45AM -0600, Adam Heath wrote: > On Mon, 20 Mar 2000, Dan Nguyen wrote: > > > Hello, > > > > I will be packaging eog (Eye of Gnome). > > > > Package: eog > > Priority: optional > > Section: graphics > > Version: 0.2-1 > > Description: The Eye of Gnome graphics viewer and cataloging program > > Gnome is the "GNU Network Object Model Enviroment" > > . > > The Eye of Gnome, an image viewer program. It is meant to be a fast > > and functional image viewer as well as an image cataloging program. > > Bzzt. Not a description. > Yes... sorry. That's what I get for working late... Here's try 2. Description: Eye of Gnome graphics viewer program eog or the Eye of Gnome is a graphics viewer for GNOME which uses the gdk-pixbuf library. It can deal with large images, and zoom and scroll with constant memory usage. The goal is a standard graphics viewer for future releases of Gnome. -- Dan Nguyen | It is with true love as it is with ghosts; [EMAIL PROTECTED] | everyone talks of it, but few have seen it. [EMAIL PROTECTED]| -Maxime De La Rochefoucauld 25 2F 99 19 6C C9 19 D6 1B 9F F1 E0 E9 10 4C 16
ITP: gnome-db
gnome-db (http://www.gnome.org/gnome-db) is "a framework for creating database applications. It provides a common API with pluggable back ends to different database sources as well as various specialized widgets for handling many database tasks." It's also part of gnome office (http://www.gnome.org/gnome-office). It's licensed under the GPL. While I'm not a developer, Ed Boraas ([EMAIL PROTECTED]) has graciously volunteered to sponsor this package. Please let me know if this conflicts with anyone's efforts. - Dan White
Re: ITP: gnome-db
Wichert Akkerman wrote: > Previously Dan White wrote: > > gnome-db (http://www.gnome.org/gnome-db) is "a framework for creating > > database applications. It provides a common API with pluggable back ends > > to different database sources as well as various specialized widgets for > > handling many database tasks." It's also part of gnome office > > (http://www.gnome.org/gnome-office). > > This sounds a bit like gconf as well, have you compared them? It appears that gconf and gnome-db have similar functionality, where gconf is geared towards providing a plugable backend to the configuration API. gnome-db looks to be aiming more toward visual database applications. Something like the Borland database explorer. http://www2.linuxjournal.com/lj-issues/issue70/3754.html "Another noticeable improvement coming to GNOME is GConf, a new configuration API and backend. This will add the features not provided by the simplistic configuration API in GNOME 1.0. It will make it easy to plug in different backends for the actual storage, so that you can change how and where the data is actually stored without touching the applications themselves." - Dan
Re: Potato now stable
On Wed, Aug 16, 2000 at 08:46:38AM +0200, Bas Zoetekouw wrote: > Thus spake Colin Walters ([EMAIL PROTECTED]): > > > I noticed the other day that recent versions of RedHat use something > > called "Kudzu" (sp?) to do this. When I took out the network card, it > > warned me that some hardware was missing, and offered to change some > > things to compensate. > > > Has anyone has looked into porting this to Debian? > > Currently, in Debian it is being used by sndconfig. It was written > specifically for Redhat though and does some things (like editing > /etc/conf.modules, linking devices in /dev/) which are probably not > desirable in Debian. The detection part can probably be used, though. > > Mandrake, too, includes a hardware detection libarary (libdetect). > Some time ago, Dan Helfman <[EMAIL PROTECTED]> (Cc'ed him), was busy > packaging it. Dan, have you had any luck yet adapting it to Debian? Yup, libdetect required very little in the way of modification and works fairly well on Debian. Harddrake (formerly "Lothar") is the GUI and console interface for libdetect. It handles autodetection and configuration. Harddrake did require some modifications to work with Debian's modutils, and those patches have now been integrated into the upstream source. > When a hardware detection library is available, I think I'm going to > rewrite sndconfig specifically for Debian instead of editing the Redhat > package. Maybe a more general program, which can detect and configure > various kinds of hardware, should be created though. You might try playing with Harddrake to see if it suits Debian's needs for this sort of thing. It has both Gtk and Newt interfaces. And by the way, Harddrake also has a "kudzu mode" that can be called from boot scripts. I haven't tried it out yet, but it's intended to do much the same thing as Redhat's kudzu. > > -- > Kind regards, > +---+ > | Bas Zoetekouw | Si l'on sait exactement ce | > || que l'on va faire, a quoi| > | [EMAIL PROTECTED] | bon le faire?| > | [EMAIL PROTECTED] | Pablo Picasso | > +---+ -- Dan Helfman UCLA Linux Users Group: http://www.linux.ucla.edu My GnuPG key: http://torsion.org/witten/public-key.txt
Re: qmail
On Mon, Aug 21, 2000 at 01:58:07PM +0800, Niall Young wrote: > What's the official stance on qmail? Is the licence (or lack thereof?) > too restrictive (any modified versions can't be distributed without > approval)? Yeah, that'll do it. See http://www.debian.org/doc/debian-policy/ch2.html#s-pkgcopyright >I notice that qmail-src_1.03-14.deb and qmail_1.03-14.dsc are > in non-free - any reason that binary packages haven't been made (yes I > know that qmail-src comes with compile scripts)? You said it yourself: "modified versions can't be distributed without approval". Debian doesn't seek special status. It's part of Debian's policy. > Any issues or opinions > on qmail? I'll neatly try to avoid a flame war by not expressing my own opinion, but I'll point you at someone else's. http://linux.umbc.edu/lug-mailing-list/1999-04/msg00096.html > I've recently migrated from RedHat (and loving it) and while I'd prefer to > stick with what Debian officially recommends, qmail has some features that I > prefer. Anyone got any good arguments against qmail? Debian officially recommends something? That's news to me. -Dan -- "... the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course!" - RFC 1122 section 1.2.2 pgpukdKVMiezk.pgp Description: PGP signature
Re: Every spam is sacred
By the way some folks live in countries considered spam countries by other people, and they can't get a email in edgewise to the high class users. By the way how about my http://jidanni.org/comp/spam/spamdealer.html solution for the little guy, remote and without root. -- http://jidanni.org/ Taiwan(04)25854780
rsync in apt sources.list?
Re: Package Lists and Size, linux.debian.devel Cor> Some of the servers run rsync, which works well for the Packages Cor> file, but does not work for the packages themselves. OK, will putting rsync in one's sources.list as you say below just affect the Packages file fetching, or also the fetching of the packages themselves? How can I switch on only the former? Cor> Other mirrors do not run rsync since it puts extra CPU load on Cor> their server. Perhaps you could find/use a mirror with public Cor> rsync access. To do this, just replace http with rsync in your Cor> sources.list I don't see this documented. If I upgrade (apt: Installed: 0.5.4 Candidate: 0.5.5.1, Need to get 12.4MB) do I get this new feature? Is there a link to just the changelog so I can see if they added this before I spend the modem time downloading? http://packages.debian.org doesn't seem to have links to changelogs, not are they in separate files on the mirrors. Cor> There are technical solutions to precomputing the diffs used by Cor> rsync, as well as solutions for diffing .gz files. E.g. I was Cor> able to perform apt-get update, upgrade in about half the time, Cor> but nobody has put in the work required to get these nicely Cor> integrated into the current tool set, is it in apt now? Cor> set up on the servers with simple HOWTOs for mirrors. or you mean apt can do it, but not all the servers run an rsync daemon? What about http://home.tiscali.cz:8080/~cz210552/aptrsync.html is it now obsolete?
no freshness dating inside Packages.gz
There are tons of information categories in the apt Packages file. But one they forgot when making the spec was some kind of date information. For unless a maintainer somehow smuggles it in, say in the version number, $ apt-cache policy icom Installed: 19990819-3 Candidate: 20020923-2 otherwise we offline users have no idea if were looking at something that hasn't changed since the 90's, or was just updated last week, without having to connect our modems to find out. Sure, "you don't need to know the date, as you are using sid and did apt-get update, you are assured it's the latest version". Well, one doesn't need the maintainer field either etc.
Re: rsync in apt sources.list?
It seems the simplest solution is to just use
http://home.tiscali.cz:8080/~cz210552/aptrsync.html
But why does he do at the bottom
# Get anything we missed due to failed rsync's. [EMAIL PROTECTED] 24 Mar 2002.
os.system('apt-get update')
# Used to have a call to apt-cache gencaches here, but I think that's
# redundant with the apt-get update above. [EMAIL PROTECTED] 24 Mar 2002.
Doing apt-get update just seems to start downloading the Packages.gz
even though we just rsynced Packages. Is apt supposed to detect
Packages are rater fresh and not download? It just downloaded over
again for me.
And of course commenting out apt-get update means that if some of the
servers in sources.list don't run rsync, then they won't be hit.
Re: rsync in apt sources.list?
>> Doing apt-get update just seems to start downloading the Packages.gz >> even though we just rsynced Packages. Tim> It could easily be a bug. Radim> It writes HIT! message there and skip this file, because it is Radim> up-to-date by rsync. Next time I will try with http_proxy unset, because I recall with wwwoffle, a HTTP HEAD causes a GET or something. Tim> I use apt-proxy now and am happy. I will investigate if modem user me can use that to relieve the apt-get update burden needed (to e.g. just upgrade a few KB packages).
Re: rsync in apt sources.list?
>> But why at the end of http://home.tiscali.cz:8080/~cz210552/aptrsync.html :
>> # Get anything we missed due to failed rsync's. [EMAIL PROTECTED] 24 Mar
>> 2002.
>> os.system('apt-get update')
well, it seems for me this just starts apt-get getting everything all
over again, http_proxy or not. So how does apt-get know if a
/var/lib/apt/lists/*Packages file is up to date or not? It might be
unaware that we have changed a Packages file underneath its nose
because it only knows about changes that it itself did?
Packages: an average 66321 bytes per line of description
Fellas, looking in the Packages files, some big packages have little
descriptions, some little packages have big descriptions, but on the average,
11938 packages
avg size 510963
avg description 7.70431 lines
avg. bytes per description lines 66321.8
For instance, the prestigious emacs21 needs only one line, as
everybody who is anybody is supposed to know what it is all about.
Computed with
cd /var/lib/apt/lists/&& ls -S|sed q|xargs awk '\
/^Size:/{size+=$2;packages++};/Description:/,/^$/{lines++};\
END{lines-=packages;print packages,"packages\navg size",\
size/packages"\navg description",\
lines/packages, "lines\navg. bytes per description lines",\
size/lines}'
Re: Packages: an average 66321 bytes per line of description
I was hoping large package developers would write longer descriptions.
Re: Packages: an average 66321 bytes per line of description
I was hoping that maintainers of multi-megabyte packages would do the package justice by giving an adequate description. The Packages file could very well be the source for decisions on what gets chosen or not for ones system.
Re: Packages: an average 66321 bytes per line of description
>> avg. bytes per description lines 66321.8 A> Is that just a meaningless number, or is there actually a correlation A> between package size and description length? Somebody with statistics experience might go further and see if little packages have big descriptions and visa versa etc. Anyway, one liner "snob" descriptions just have to go. $ apt-cache show emacs21 Description: The GNU Emacs editor GNU Emacs is the extensible self-documenting text editor. Oops, I see, it is self-documenting.
but I want the GNU versions of packages
Gentlemen, after I installed "Debian GNU/Linux", I found I had to take extra steps to get the GNU version of a program installed, as some other leading brand alternative was in its stead. So what is the single command to apt-get install all the GNU versions of everything? Last year I discovered mawk sitting there until I banished it away with apt-get install gawk. Yesterday I realized I had been using mailx all this time while GNU's mailutils were sitting unused. Do I look in Packages.gz for Conflicts:, and then look in Description: for "this is the GNU version of..."? What other other leading brands programs are sitting on my computer when I could have been using a genuine GNU program? What genuine GNU programs should I defer, lest e.g. messages get trunc
Re: but I want the GNU versions of packages
> what's the point? Surely you want the best, not necessarily the GNU > version (which might be an incredibly bleeding-edge pre-alpha thing, > like for example mailutils was not so long ago)? OK, let's just say I like the GNU guys and would like them to know if there are any bugs in their stuff, otherwise how will it improve? And mawk: development halted years ago. Wouldn't any awk bugs I find be better reported for gawk? So, how does one find the rest of the packages on one's system that "Conflicts:" with genuine GNU alternative packages. >From the tone of your message, I bet there are lots that you fellows have pre-chosen for us new debian users. So far I have discovered mawk, and mailx. So, out with it, what are the rest?
Re: mawk is a required package but I have replaced it with gawk
> I was thinking that to have a "valid" debian system, all "required" > packages must be installed. < That's true for essential package, but required != essential. /usr/share/doc/debian/FAQ/debian-faq.en.txt.gz: 6.7. What is a _Required_, _Important_, _Standard_, _Optional_, or _Extra_ package? Each Debian package is assigned a _priority_ by the distribution maintainers, as an aid to the package management system. The priorities are: * _Required_: packages that are necessary for the proper functioning of the system. This includes all tools that are necessary to repair system defects. You must not remove these packages or your system may become totally broken and you may probably not even be able to use dpkg to put things back. I will file a bug to get essential added to this file. It is mentioned in debian-policy but not here. Anyway, can't blame some users for getting the impression that if one doesn't accept mawk, their system will be in serious shape, whereas it really should be: if one has no version of awk at all, their system will be in serious shape.
why no python, tcl, tk metapackage?
I see my sid system has collected various python 2.1 and 2.2 packages, but
no 2.3 packages. Couldn't there be a python metapackage that I could
install to always keep python at its freshest, also saving disk space
by disposing older versions?
In particular, after purging 2.1 et. al. by hand, I have all these:
$ COLUMNS=888 dpkg -l|awk '/python2.2/{print $2}'|xargs
idle-python2.2 python2.2 python2.2-dev python2.2-doc
python2.2-egenix-mxdatetime python2.2-egenix-mxtools
python2.2-examples python2.2-extclass python2.2-gadfly python2.2-gdbm
python2.2-imaging python2.2-imaging-sane python2.2-imaging-tk
python2.2-ldap python2.2-mpz python2.2-numeric python2.2-optik
python2.2-tk python2.2-xml python2.2-xmlbase
I suppose I can only pipe this list to sed 's/2.2/2.3/g'|xargs apt-get install,
there being no better way to upgrade them?
Wait, tcl seems to be in the same state, both 8.3 and 8.4 installed,
whats worse, many packages e.g. depend on tcl8.3 (>= 8.3.0), and not
tcl (>= 8.3.0). But a developer couldn't specify the latter because the
version number is hardwired into the only available package's name.
packages removed by Release Manager just reveal older versions
Regarding packages removed by Debian's Release Manager, due to Release Criticial bugs, but say, still looking great here: $ apt-cache policy deity deity: Installed: (none) Candidate: 0.8.0.6 Version Table: 0.8.0.6 0 500 cdrom://[Debian GNU/Linux SID _Sid_... there seems no mechanism at present to warn the user that he shouldn't install it, even if he has done apt-get update from the mirrors. In bug 202919 you will see I was just lucky something stopped installation. I guess I'm hoping for a warning that a package is 'out of fashion' when I try to apt-get install it.
future Date: field for Packages files
Regarding a future Date: field for each package in Packages files, * Should the field be called Date: or Time:? * Should it be like "Mon, 18 Aug 2003 22:09:30 GMT" or "1061315862"? * Should it refer to the time the developer finished wrapping the package, or the time it entered the distribution? Those questions are for you implementers to decide. I merely look forward the day when one can tell apt-show-versions --upgradeable, or grep-available, that one is only interested in versions that have been around for more (or less) than X days.
Re: /etc/mailname same as /etc/hostname
>>>>> "A" == Andreas Metzler <[EMAIL PROTECTED]> mailed me: A> On Wed, Aug 20, 2003 at 11:06:12AM +0800, Dan Jacobson wrote: >> If /etc/mailname is the same as /etc/hostname, can I remove >> /etc/mailname perhaps one day? Both say jidanni.org . A> No, they serve different purposes. Quoting policy 11.6:[...] I see. OK, I just did cd /etc && cmp hostname mailname && rm mailname && ln -s hostname mailname [I hope that's OK.]
packages mucking in /usr/local/?
Gentlemen, do $ find /usr/local -mtime -222 /usr/local/lib/libxbase-2.0.so.0 /usr/local/lib/libxbase.so /usr/local/lib/python2.2/site-packages /usr/local/lib/python2.3/site-packages /usr/local/lib/texmf/ls-R /usr/local/share/emacs/21.3 /usr/local/share/emacs/21.3/site-lisp /usr/local/share/octave/site-m... $ dlocate /usr/local Shows no culprits. Do other users spot activity in /usr/local/? I doubt it is something I compiled instead of apt-getting.
Re: packages mucking in /usr/local/?
> However, the package may create empty directories below `/usr/local' > so that the system administrator knows where to place site-specific > files. These directories should be removed on package removal if they > are empty. OK, but then those packages should list them so dlocate will show that they are intentionally placed there, no?
Re: LWN subscription for Debian developers
Bdale> ... I announced a group subscription to lwn.net for Debian Bdale> developers, sponsored by HP... Debian may be seen as supporting non-disclosure conditions / protected proprietary information / trade secrets / etc. whatever. Bdale> If you are a Debian developer and want full LWN access, go to Bdale> lwn.net and create an account for yourself (no money is Bdale> required... But the Debian developer cannot disclose the information seen with non Debian developers.
is your /usr/share/info/dir in perfect shape?
Gentlemen, the Info dir on my system is not in tip top shape, and may not be also on yours. Try this simple test for duplicate entries: $ sort /usr/share/info/dir|uniq -d|fgrep \* * patch: (diff)Invoking patch. Apply a patch to a file. * sdiff: (diff)Invoking sdiff. Merge 2 files * testsuite: (autoconf)testsuite Invocation. Running an Autotest test So some packages are using install-info imperfectly. Maybe instead of relying on perfect use of install-info by each package, perhaps just remaking /usr/share/info/dir from whatever info files are on the system might be less error prone? $ sed -n 's/:.*//p' dir|sort|uniq -d * Gnus * Info * Message * patch * sdiff * testsuite * true * tty * uname * users * who * whoami * yes for me reveals that I need to do $ install-info --remove /usr/share/info/sh-utils.info as apparently that wasn't done when those tools were moved to a different package. Same with fileutils...
some packages don't list their /etc/default/ file
Some packages don't list their /etc/default/ file as part of the package: # for i in /etc/default/*; do dpkg -S $i;done dpkg: /etc/default/alsa not found. aumix: /etc/default/aumix cdrecord: /etc/default/cdrecord libc6: /etc/default/devpts dnsmasq: /etc/default/dnsmasq dpkg: /etc/default/exim4 not found. dpkg: /etc/default/fetchmail not found. dpkg: /etc/default/hotplug not found. initrd-tools: /etc/default/initrd-tools.sh dpkg: /etc/default/iptables not found. libnss-db: /etc/default/libnss-db dpkg: /etc/default/noffle not found. dpkg: /etc/default/rcS not found. cdrecord: /etc/default/rscsi spamassassin: /etc/default/spamassassin ssh: /etc/default/ssh
developers Japanese and Chinese names' original characters
Where is a list of Asian developers' names in their original characters? The best I can do right now is e.g. grep /usr/share/edict/enamdict to guess from the romanization.
Re: developers Japanese and Chinese names' original characters
> Chinese names from different regions are romanized using > incompatible schemes, sometimes even *inconsistent* schemes. Only > mainland Chinese use a consistent scheme (Pinyin). Here in Taiwan they have placed a nut in charge of this. He will be gone after the Mar. 2004 election though. http://jidanni.org/lang/pinyin/ < I do think having a list of native DD names would be novel, at least, < but it would have to be manually maintained. Perhaps it could be put on the people.debian.org or developer lookup / search developer by region website... Or maybe add a field for the developers name in unicode if non-ascii, on the standard info webpage for each developer, that I recall seeing somewhere.
libapt-pkg-libc6.3-5-3.3
Hey there. I want to install libapt-pkg-libc6.3-5-3.3 but it says that it is virtual file. I want to install it because i want to install apt-move, so i can install dfsbuild, so i can make a live cd, just for my needs. But i cant find it any where, and i saw (see, im dainish :) ) that i should write a mail to you. Is this something you can help me with. Dan From
not starting daemons at boot: ln -s disabled
One way of having some daemons not start at boot (e.g., if we only use our printer once a year) is to remove certain /etc/rc?.d/ links. But the downsize is later, unless one keeps records, one isn't quite sure of just what tampering one has done in /etc/rc?.d/ So in /etc/default/* we can set NO_START_AT_BOOT=1 etc., at least we can see and comment what we did. However there still is a way to know what we tampered with in /etc/rc?.d/: instead of telling the user to just remove some links, have them instead ln -s to /dev/null or better: /etc/init.d/disabled perhaps, an empty file mode 555. And those link manager programs could do the same. So then one could see clearly that S20cwdaemon -> ../init.d/disabled etc. Or use DISABLED for extra clarity. Not as efficient as removing the link, but at least one can see what one did later. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: time seen at top of /var/log/boot
I'm curious about the times seen in /var/log/boot. Please do # perl -nwe 'next unless /Setting the System Clock/.. /System Clock set/; s/: S.*//;print' /var/log/boot Wed Sep 28 08:18:54 2005 Wed Sep 28 00:18:54 2005 What is the timezone of first time? No its not my BIOS time. It appears to be a timezone 4 timezones east of New Zealand, GMT+16, i.e., out of this world. How about on your machine? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: time seen at top of /var/log/boot
I still have no idea why the time at the top of /var/log/boot is so far ahead of any worldly timezone: # grep Clock /var/log/boot Sun Oct 9 07:31:32 2005: Setting the System Clock using the Hardware Clock as reference... Sat Oct 8 23:31:31 2005: System Clock set. Local time: Sat Oct 8 23:31:31 CST 2005 The final time is correct Taiwan time, but the initial time is an unworldly GMT+16. My BIOS is set with my local Taiwan time. I wonder what others # grep Clock /var/log/boot except for those whose two lines are the same time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: time seen at top of /var/log/boot
I installed two Debian sids on separate machines. They work fine. My only curiosity is what I see with grep Clock /var/log/boot. > The final time is correct Taiwan time, but the initial time is an > unworldly GMT+16. My BIOS is set with my local Taiwan time. < As Taiwan is GMT+8, it looks as if the initial time is your < system time interpreted as GMT and corrected for Taiwan timezone. Ah. Hmmm I bet Tokyo Debian users have GMT+18 then. < Do you by any chance have UTC=yes in /etc/default/rcS? UTC=no I Wonder what other east of GMT, BIOS set to local time users see with grep Clock /var/log/boot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426625: general: /etc/adjtime etc. wetbacks
Package: general Severity: wishlist Files like /etc/adjtime should either be related to some package (searchable via dlocate, etc.) or should have a note inside them saying how they got on our disk: what package brought them there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
[+dickey] On Thu, Sep 18, 2008 at 8:45 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: >>> So the obvious solution seems to me then to build ncurses twice, >>> providing both libncurses5 and libncurses6 packages. What point do I miss? >> >>The crashes that will happen when both are loaded in a >>process's address space. >> ... and they couldn't add mouse-wheel support without breaking ABI ? > > AFAICT, the issue is that there aren't enough bits in an int to express > all the button events in the same way as before. The new ABI reshuffles > the bits to make more room. > > It should be possible to make this change in a less invasive way. A possible problem case is: an app built against version X of ncurses tries to load a shared library built against version X+1 of ncurses. e.g. a CAD vendor ships a binary app linked itself against ncurses.so.5 and also via a library in the distro against ncurses.so.6. But are there any libraries in linux distros that use ncurses? As it turns out, yes. On my system, I see rather a few: gstreamer-0.10/libgstaasink.so gstreamer-0.10/libgstcacasink.so libaa.so.1.0.4 libcaca.so.0.99.13 libcaca++.so.0.99.13 libcwidget.so.3.0.0 libedit.so.2 libform.so.5.6 libformw.so.5.6 libggi.so.2.0.2 libguilereadline-v-12.so.12.3.1 libmenu.so.5.6 libmenuw.so.5.6 libpanel.so.5.6 libpanelw.so.5 libvte.so.9.2.17 libzephyr.so.3.0.0 python2.5/lib-dynload/readline.so python-support/python-vte/python2.4/gtk-2.0/vtemodule.so So if a binary app happens to link in any of those and also ncurses itself, there's a potential conflict. I don't know if there's an actual conflict, I haven't looked. I didn't see any recent discussion about abi stability http://lists.gnu.org/mailman/listinfo/bug-ncurses If there is a realistic problem case, perhaps we should also discuss it there. - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey <[EMAIL PROTECTED]> wrote: >> from the upstream POV, this would be another ABI transition. > > If there's no patch, there's nothing to discuss, then. Going forward, though, can you avoid potential issues like this by maintaining better ABI compatibility between versions? i.e. when you add a libncurses.so.7, can you make it so that all apps that linked against libncurses.so.6 still continue to work without recompilation? - Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Thu, Sep 18, 2008 at 2:03 PM, Julien Cristau <[EMAIL PROTECTED]> wrote: >> Going forward, though, can you avoid potential issues like this >> by maintaining better ABI compatibility between versions? >> i.e. when you add a libncurses.so.7, can you make it so >> that all apps that linked against libncurses.so.6 still continue >> to work without recompilation? > > This doesn't make any sense. If all apps linked against the previous > version continued to work without recompilation, it wouldn't be an > incompatible ABI change, and so wouldn't require a SONAME bump. You still need an SONAME burp if some apps linked against the newer library (say, those using new features) would fail with the older one. i.e. unless a change is both forward and backwards compatible, you can't get away without some sort of burp. (Or am I confused?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
symlinks bug: fixed upstream
With reference to: http://lists.debian.org/debian-devel/2008/08/msg00347.html mtx-changer.Adic-Scalar-24 has been fixed in the Bacula repository. Committed revision 8134. NOTE: the code wasn't part of Bacula proper. It's one of the examples we supply. http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/bacula/examples/autochangers/mtx-changer.Adic-Scalar-24?r1=2805&r2=8134 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#220289: general: make a new section: gis, for Geographic Information System packages
Package: general Severity: wishlist Debian needs a new Packages section, named gis, or perhaps geography or cartography, to prevent the mapping related packages from being scattered in sections graphics and science, and misc, etc.? as at present. Package: gpsman Section: misc Package: grass Section: science Package: shapelib Section: graphics etc.
Bug#221386: general: addresses for "section coordinators"
Package: general Severity: wishlist We know that [EMAIL PROTECTED] will get one in touch with a package maintainer. But what if one wants to ask a question about a whole "Section"? Maybe there should be a person assigned for each Section [but what about free/nonfree] E.g. I want to ask the "coordinator of debian's hamradio section" if there are any programs that can tell one what country a given call sign is from, offline.
Bug#220289: section science/geography vs. geography
Regarding science/geography etc., wouldn't plain geography be better? I see there is already a electronics, not a science/electronics. On the other hand, perhaps remodel the categories after the Usenet newsgroup name tree.
