Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
Package: general The average user will not notice his firmware is not updating any more. Some users, if they do $ apt-show-versions |grep 'No available version in archive' will see firmware-amd-graphics:all 20221214-3 installed: No available version in archive firmware-brcm80211:all 20221214-3 installed: No available version in archive... And if they check /var/lib/apt/lists/*_debian_dists_unstable_non-free_i18n_Translation-en.diff_Index will notice something funny happened... 137480 T-2023-01-30-2019.16-F-2023-01-14-1406.12 137194 T-2023-01-30-2019.16-F-2023-01-14-2004.08 137161 T-2023-01-30-2019.16-F-2023-01-16-0203.33 137036 T-2023-01-30-2019.16-F-2023-01-16-2003.44 73251 T-2023-01-30-2019.16-F-2023-01-18-2013.57 73217 T-2023-01-30-2019.16-F-2023-01-19-2008.34 72676 T-2023-01-30-2019.16-F-2023-01-20-2016.02 So he must do Google Search. https://www.google.com/search?q=debian+firmware+non-free which leads to https://wiki.debian.org/Firmware which says ...a new repository component non-free-firmware... So that means he needs to add it to /etc/apt/sources.list.d/ Ah ha! Yes, he should be regularly subscribed to debian-user, but that's too much. Or https://lists.debian.org/debian-announce/, but that's too many boring messages too. Yes, he uses apt-listchanges, but that won't tell him this. So I'm saying that Debian needs a mechanism to have his computer tell him to do this. Maybe the next time he uses apt*, somehow the system should tell him...
Re: Debian-wide firmware prober
Z> isenkram-cli OK, but it seems to work differently that what I was thinking.
Debian-wide firmware prober
Hey everybody, wouldn't it be nice if there was a prober, like lshw, that probed all the firmware one needed? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982402 It would say: " You need the following Debian firmware packages firmware-X firmware-Y firmware-Z Remember, a proper system needs proper firmware. Not too much, but also not too little. "
Bug#934413: .debs are old fashioned. e.g., Google Play makes smaller updates
Package: general Just the other day I noticed Google Play seems to make smaller updates than when installing an initial package. https://bugzilla.mozilla.org/show_bug.cgi?id=1572812 So maybe instead of bulky .debs, Debian could do similar. Hmmm, http://debdelta.debian.net/ https://wiki.ubuntu.com/UbuntuDebdeltaSupport https://askubuntu.com/questions/916846/why-isnt-debdelta-used-by-default-in-ubuntu Well all I know is Google Play succeeded.
Bug#901003: There is no standard way of removing transitional / dummy packages
Package: general There is no standard way of removing transitional / dummy packages. One has to grep for the words transitional / dummy in their descriptions to find them. They should all have a standard Tag:. And the Debian documentation should mention what apt command will remove them.
more files in /usr/share/doc could possibly be symlinked
Perhaps more duplicate files in /usr/share/doc could be symlinked to save space in some cases, depending on their dependencies... $ cd /usr/share/doc ls -ogi */changelog.gz|sort -k 4nr|head 25166091 -rw-r--r-- 1 2606373 07-24 01:11 krb5-locales/changelog.gz 25302407 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-bin/changelog.gz 25302415 -rw-r--r-- 1 1944189 07-31 23:47 libvirt0/changelog.gz 25565662 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-clients/changelog.gz 25565667 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-daemon/changelog.gz 25565671 -rw-r--r-- 1 1944189 07-31 23:47 libvirt-daemon-system/changelog.gz 25297489 -rw-r--r-- 1 1674007 07-17 15:04 xserver-common/changelog.gz 25300435 -rw-r--r-- 1 1674007 07-17 15:04 xserver-xorg-core/changelog.gz 25035737 -rw-r--r-- 1 1120163 06-24 11:01 libglib2.0-0/changelog.gz 25297072 -rw-r--r-- 1 1120163 06-24 11:01 libglib2.0-data/changelog.gz -- 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/87zjfnfens@jidanni.org
bootlogd fills up entire disk eventually
severity 725120 critical version 725120 2.88dsf-55 forcemerge 725120 743001 forcemerge 725120 724712 thanks The logs finally got so big, never getting rotated, that they filled up the disk, rendering the ENTIRE SYSTEM unusable! -- 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/87wqcyr4ab@jidanni.org
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]
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]
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]
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#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: Moving GFDL documentation to non-free
W The usual package name is original package name-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]
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]
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]
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]
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]
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]
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]
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'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]
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]
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#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
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: 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]
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 2errors_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: 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]
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: 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]
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]
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]
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]
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]
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.
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: xdm: init script's execution can be terminated prematurely if invoke-rc.d run from child process of xdm
Maybe remove the pid file before killing, not after? If it resists our best attempts at killing. including -9, that would be a different bug, and leaving a pid file would be useless anyway? Just a guess.
Re: xdm: init script's execution can be terminated prematurely if invoke-rc.d run from child process of xdm
I recall prepending a nohup: [EMAIL PROTECTED] nohup invoke-rc.d xdm stop solved the problem. So maybe a nohup or trap inside /etc/init.d/xdm would be what you want. The only problem left then would be cleaning up the nohup.out created. This could also be done for other /etc/init.d/?dm's.
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.
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: 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.
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.
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.
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
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...
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.
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: /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.
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.
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.
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.
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.
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?
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: 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.
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: 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?
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?
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.
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: 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
Re: can touch(1) readonly files
I see, if I wanted chmod 444 to stop me from touch(1)ing my files, then I would have to give up $ chmod 0 x; ls -l x -- 1 jidanni jidanni 0 2003-05-14 07:38 x listing my files. Ok, over and out.
Re: can touch(1) readonly files
But how can I protect _myself_ from _myself_? I seem to recall in past UNIXes things weren't this bad. $ id uid=1000(jidanni) gid=1000(jidanni) ... $ chmod -w -R ee $ find ee|xargs touch -d 'next year' $ find ee|xargs ls -ld dr-xr-xr-x3 jidanni jidanni 1024 2004-05-13 16:43 ee -r--r--r--1 jidanni jidanni 0 2004-05-13 16:43 ee/ff dr-xr-xr-x2 jidanni jidanni 1024 2004-05-13 16:43 ee/gg I mean I can understand why access times still should be changed, but where is the logic in allowing modification times to be changed? Again, I ask, as a regular user, why can't I protect _myself_ from _myself_ changing file modification times? I wonder just how many of the times in the inode are now gullible. $ uname -a Linux debian 2.4.20-k7 #1 Tue Jan 14 00:29:06 EST 2003 i686 unknown unknown GNU/Linux -- http://jidanni.org/ Taiwan(04)25854780
Bug#170472: info: top Info pages of different packages wildly differ
Package: info Version: 4.1-2 Severity: normal Gentlemen, the top Info pages of different packages wildly differ: e.g. $ info m4 has a nice header GNU m4 but $ info gawk has a lower level header 'General introduction', while $ info yorick has a menu without a header, while $ info emacs says the emacs editor, even better than GNU m4 which doesn't mention if it is an editor or a language, etc. Therefore folks should make top Info nodes with proper headers. How about a debian Info pages policy. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux debian 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 Versions of packages info depends on: ii libc62.2.5-6 GNU C Library: Shared libraries an ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand
Bug#159385: general: install a package but don't have it's magic funcionality on by default
Package: general Version: N/A; reported 2002-09-03 Severity: minor First examine a bug report I sent regarding a typical package, bl: My idea of inviting bl onto my computer was that it would be there when i need it, but not on by default. as there is no easy way of configuring it not to start on login, therefore i am removing it. That's the problem with debian, for me. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux debian 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5
