Re: fresh potato install dpkg problem

[Jonathan Nieder]

I found it... the link is below.

ftp://ftp.iteso.mx/.1/debian/dists/potato/main/binary-i386/base/dpkg_1.6.9.deb


Note that the problem goes away on upgrade to 1.6.11...

So this information isn't really relavent anymore.

--
Jonathan Nieder
__
Get Your Private, Free Email at http://www.hotmail.com

KDE (was Re: alternatives to gnotepad+)

[Jonathan Nieder]

Also what about kedit part of KDE. It  opens more than
 one file simultaneously.


BTW, are there .debs for KDE in Debian?  I tried GNOME,
but it wasn't really my kind of desktop, and KDE looks
good.

Thanks,

Jonathan Nieder
__
Get Your Private, Free Email at http://www.hotmail.com

slsc, i.e., spreadsheet calculator using s-lang (Re: sc, i.e., spread sheet calculator using ncurses)

[Jonathan Nieder]

Hi,

Wilko Fokken wrote:

> I remember 'slsc', a text based spreadsheet, based on 'sc', but more
> advanced. Unfortunately, Debian doesn't contain it any more.
>
> At least up to Debian 3, this prog was provided.
>
> If you can find an 'slsc' source, you might be instrumental in
> bringing it back to life. You'll probably prefer it to 'sc'.

Interesting.

:
[2006-12-23] Removed 0.2.3-9 from unstable

:
I hoped to be able to tell you that I had it working, but after a
number of hours working on porting it, I came to the conclusion that
is it not possible.  One part of sc using the internals of slang
extensively, unfortunately these internals don't exist in slang2.
[...]
OK, I think you have convinced me.  It's true that there are probably
very few people that use it, and I don't use it anymore either.  

 has version 0.2.3-9, which
is one revision newer than the version from sarge.

The version at  still seems to be
0.2.3 and to require s-lang 1.  The author writes:

slsc is a spreadsheet program that is based on sc.  The main
difference is that slsc is much easier to use.  However, I am nolonger
supporting it.

Ciao,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713202828.GA31229@burratino

Re: Why compiling.

[Jonathan Nieder]

Hi,

Atıf CEYLAN wrote:

> For example, my wireless card is not supported by debian wheezy standart
> kernel. Also non-free package is not working. So I compile it from
> source code and I change some part of the code (because some part of
> code is not working with my hardware). So I must make compiling :)

If you have time to describe what breaks when you use the standard
kernel, that would be welcome.  Please use 'reportbug' with the name
of the standard kernel package as an argument if interested.  If the
kernel team comes up with a potential fix, your ability to build your
own kernel could be very useful. :)

Thanks and hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713222554.GA326@burratino

upgrade-report: errors from squeeze tar unpacking packages from testing (Re: Upgrade from stable to testing problem)

[Jonathan Nieder]

Hi Hans,

Hans-J. Ullrich wrote:

> some weeks ago I made a fresh instrallation on a notebook with debian/stable.
>
> Well, then I started a aptitiude full-upgrade, but it did not work. I found 
> out, the reason for it, was, that the installed version of tar could not 
> unpack the packages of debian/testing.

This sounds reminiscent of .

It would be a serious bug, except the necessary version of tar had been in
squeeze for more than a year already.  What version of tar were you
using when you ran into this?  (/var/log/dpkg.log should say.)  What
error message did you get from aptitude when problems arose?  (I think
aptitude keeps this kind of information somewhere in /var/log, such as
aptitude.log or term.log, but I'm not sure.)

Thanks,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217022911.ga7...@elie.hsd1.il.comcast.net

Re: Missing package changelogs

[Jonathan Nieder]

Hi Štěpán,

Štěpán Němec wrote:

> There are lots of packages for which aptitude gives
>
> Failed to download the changelog of foobar: 404  Not Found [IP: x.x.x.x 80]
>
> (and you get the equivalent when trying to access the changelog online)

Yep.  See .

[...]
> Is there anything being done to fix this? Can I help in some way?

Not sure.  After looking over that bug report, I believe
debian-...@lists.debian.org should reach the people who would know.

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217023605.ga7...@elie.hsd1.il.comcast.net

Re: vsftpd-2.3.5.deb: Can I get the debian source of 2.3.4?

[Jonathan Nieder]

Hi Regid,

Regid Ichira wrote:

>   Referring to Package: vsftpd, Version: 2.3.5-1.
>
> 1. Can I get the debian source for 2.3.4, and possibly older?
>I think debian had some version control archive for the vsftpd
>package.

Sure, they are available from http://snapshot.debian.org/ and from
vcs.progress-linux.org.  The latter does not seem to be advertised
anywhere for reasons related to the Debian trademark and unpleasant
emails, or something.

> 2. Since I write, I'll mention the issue I am after:
>
> $ zcat /usr/share/doc/vsftpd/changelog.gz | tail -6
> - Add stronger checks for the configuration error of running with a 
> writeable
> root directory inside a chroot(). This may bite people who carelessly 
> turned
> on chroot_local_user but such is life.
>
> At this point: v2.3.5 released!
> ===
>
>   I think those stronger checks are wrong, because it prevents
> modifying (uploading, deletion, modifying) files.  Am I wrong?
> Such modifications used to work.

I think the stronger checks are right, though they could probably be
relaxed without harm in some special cases.

To elaborate a little: suppose my friend patches out these security
checks.  I have access with upload rights to the directory served over
FTP, but no shell access.  I would like shell access in order to play
a prank (maybe I will send local mail or something).

I create a directory named /bin and upload a binary named sh there.  I
also create a directory named /usr/share/locale and put some
hand-crafted locale data there.  I do something to exploit (for
example) a buffer overflow in locale handling in libc that allows me
to run the code I would like.

This avenue of attack requires that I be able to write to filenames
under /bin, /usr/share/locale, /etc, and so on that the process can be
convinced to access and more or less trust.  If my friend had only
allowed me to write to a directory named "/pub" under the directory
chroot()ed to, this attack would not have been possible.

So the intent is to prevent creating directories like /bin, /usr, and
/etc under the toplevel.  If your users already have shell access or
you are able by some other means to prevent creating such directories
then the check is probably not needed.

See /usr/share/doc/vsftpd/FAQ.gz for more details.

Hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120120063518.GA32039@burratino

Re: dpkg --compare-versions vs. ls

[Jonathan Nieder]

jida...@jidanni.org wrote:

> Is there any case where
> $ cd /var/cache/apt/archives
> $ set -- $(ls -r some_package_*)
> $ dpkg --compare-versions $1 gt $2
> isn't true?

Yes.

 * dpkg --compare-versions uses ASCII to compare letters (so B < a).
   In non-C locales, ls does not.

 * dpkg --compare-versions treats ~ specially (so
   git-core_1%3a1.6.6~rc-1_i386.deb < git-core_1%3a1.6.6-1_i386.deb).
   Even in the C locale, ls does not.

 * dpkg --compare-versions compares the numeric part of a version
   numerically (so 1.2 < 1.11).
   ls does not.

On the other hand, 'ls -v' behaves like dpkg --compare-versions in
the respects described above.  But:

 * dpkg --compare-versions treats : specially (so 3 < 1:1).
   ls -v does not.

'ls -v' and 'dpkg --compare-versions' differ in plenty of other ways,
too.

To handle epochs correctly, you really need to be unescaping the
version number part of the filename.  If your application permits the
slowdown, I think it would be simpler to use

show_version() {
dpkg-deb --showformat='${Version}' --show "$1"
}
dpkg --compare-versions $(show_version "$1") gt $(show_version "$2")

See ,
.

Hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: how are you kids compiling kernels these days?

[Jonathan Nieder]

Hi Paul,

Paul Johnson wrote:

> Now I've got a laptop with an Intel Centrino Ultimate 6300 wireless
> device and it has been very unstable when joining wireless networks. I
> complained about it in the intel wireless support page and today a
> technician answered me back with a kernel patch.
>
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2346
>
> This is a pretty serious request, I'm willing to try, but I wish
> somebody who has done this recently would share the experience.

I know two ways to do it.

One is to build from the official Debian packaging, as described at
.
That page is pretty thorough, so I'll let it cover that itself.

Another way is to build the kernel from kernel.org, like so:

 0. prerequisites

apt-get install build-essential ketchup

 1. get the kernel

mkdir linux
cd linux
ketchup 3-rc

 2. configure and test

cp /boot/config-$(uname -r) .config; # current configuration

# optional: disable debugging symbols for a smaller build tree.
# This is almost always a good choice, unless you use systemtap
# or you use perf to profile the kernel.
scripts/config --disable DEBUG_INFO

# optional: minimize configuration by only including currently
# loaded modules.  Most modules that are not loaded are drivers
# for hardware you don't have.  Make sure your wireless driver
# is loaded if you've unloaded it.
make localmodconfig

make deb-pkg; # optionally with -j for parallel build

dpkg -i ../; # as root
reboot
... test test test ...

Hopefully it reproduces the bug.  So:

 3. try the patch

cd linux
patch -p1 ; # as root
reboot
... test test test ...

Thanks for your work, and hope that helps,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120531072501.GA16461@burratino

Investigating bugs without risking damage (Re: [bash] Everything Segfaults After lib6 -7 Upgrade)

[Jonathan Nieder]

Hi David,

David Baron wrote:

> (I do not want to unnecessarily try to boot up the errant Sid /lib because of 
> possible file system damage.)

Quite understandable, but it makes life hard to be tracking down a bug
from memory only.  I would not personally expect an ld.so problem to
cause corruption, just segfaults, not that I expect that to be any
comfort.

Dear debian-user list: do you have any advice for this case?  In
particular, any hints for booting up in such a way as to be certain
the root partition remains read-only (never changing it to read/write
at all)?

Thanks much.  Please cc me on replies, since I am not subscribed.

Cheers,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110617000958.GA14695@elie

RFH: slow awk scripts wanted

[Jonathan Nieder]

Hi,

I am new to awk but quite like it, and I am considering working on
some changes to mawk that would have an impact on performance.

Problem: generally awk is already more than fast enough for me.  So
chances are, this would end up ruining it for everyone else!  Unless
you help.

If you have

 - a (fast or slow) awk script you use regularly on large sets of data

 - a scripts you wrote naïvely and then had to revise to make perform
   acceptably (the before and after would be great)

 - an awk script you use very often

 - a shell script in which awk is run in the inner loop

 - a long stream of data you regularly use awk to digest

then I would like to know about it so I can run some tests.  In other
words, I am looking for performance bugs and performance success
reports.

As active Debian users, you are the target audience.  Dedicated awk
users in awk-specific forums might have adapted their behavior to
existing implementations, producing skewed results; plus, their
scripts are already nicely archived.

Please respond privately and I will send a summary in a week or so.
If your script is of general interest, I encourage you to contribute
to a relevant thread on comp.lang.awk or a site like awk.info and
point me there instead.

If you think I’m crazy, feel free to let me know that, too.

Looking forward to your thoughts,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100421230240.ga25...@progeny.tock

Re: Chromium in Sid

[Jonathan Nieder]

Hi Steve,

Steve Fishpaste wrote:

> In my opinion we should keep up with the new releases at least weekly.
> Is this on the agenda to do?

No, I do not think it is in the plans any time soon:

 - sid is used to stage versions that could potentially be used in
   some stable release.  I can’t see a more risky branch than the beta
   channel being used for this.

 - experimental is used to test iffy packaging changes before
   releasing them to sid.  To test the tip of trunk this way would
   rule out more short-lived packaging experiments, which may be
   needed now while the packaging is changing rapidly.

However, testing and developing from the tip of the development tree
can be useful for many reasons.  You have a couple of options.

 1. Build from source.  This is in my opinion your best choice,
since if you run into problems this would make it very easy to
test out patches.

The packaging used for sid can also be used to build from the dev
channel or other versions for that matter.  If you have any
questions about this, please don’t hesitate to ask.

 2. Use Fabien Tassin’s nightly builds ppa[1] from Ubuntu.  This is
not the tip of the development tree but it is close.

Note that almost everything I said above goes for any other project
whose packaging is changing rapidly, too.  There is nothing wrong with
regularly building from source a few packages you follow closely, imho.

Hope that helps,
Jonathan

[1] https://launchpad.net/~chromium-daily/+archive/ppa


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100523092948.ga20...@progeny.tock

Re: Git sources of git-core (for SID) out-of-date?

[Jonathan Nieder]

Hi Michal,

Michal Maruska wrote:

> sid has version   1:2.47.2-0.1
> https://packages.debian.org/source/sid/git  mentions as git source:
> https://repo.or.cz/w/git/debian.git/
>
> which indeed has the relevant branch:
> https://repo.or.cz/git/debian.git/shortlog/refs/heads/debian-sid
>
> but it's not pointing to anything related to "1:2.47.2-0.1"
>
> Why is it missing the commits with the updated d/Changelog?

This is normal when someone performs a non-maintainer upload.  If they
join the maintenance team, then they would be doing work in the same
repository; but if a Debian developer who is not one of the package
maintainers is helping out by making an upload on their own (which is
much appreciated!), then their updates don't show up in the Git
repository until the next maintainer update.

In general, please feel free to contact g...@packages.debian.org if you'd
like to help out with maintenance of this package, and we'd be happy to
welcome you.  https://mentors.debian.net/ has some additional
suggestions about how packages are maintained in Debian.

Thanks and hope that helps,
Jonathan