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. T
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.
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 in
Z> isenkram-cli
OK, but it seems to work differently that what I was thinking.
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 need
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.c
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.
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
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
w
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
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 sugges
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
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 e
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 UNSUBSCRI
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,
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.
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
(e
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.
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 "unsubscri
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 messa
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
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 CS
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 ti
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_S
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 "unsubs
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]
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 t
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 PROTECT
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
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>
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
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". Trou
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 vacat
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
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 Packa
>> 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
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/b
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]
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.
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
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.
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.
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.
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 "coo
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
Sect
> 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:
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 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
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.
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
> 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 dlo
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/s
>>>>> "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 .
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?
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 mecha
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 ha
> 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?
-
> 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, o
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 m
>> 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, o
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.
I was hoping large package developers would write longer descriptions.
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
>> 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.
>> 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 rec
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 th
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
otherwis
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 fetchi
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/ Taiw
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.
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-
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
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
73 matches
Mail list logo
