Re: Sending a bug report with reportbug fails
Here is more info. .reportbugrc is standard generated stuff without any modifications. [EMAIL PROTECTED]:~$ cat .reportbugrc # reportbug preferences file # character encoding: UTF-8 # Version of reportbug this preferences file was written by reportbug_version 3.39 # default operating mode: one of: novice, standard, advanced, expert mode standard # default user interface ui text # offline setting - comment out to be online #offline # name and email setting (if non-default) # realname Joona Kiiski email [EMAIL PROTECTED] # Disable fallback mode by commenting out the following: no-cc header X-Debbugs-CC: [EMAIL PROTECTED] smtphost bugs.debian.org # You can add other settings after this line. See # /etc/reportbug.conf for a full listing of options. [EMAIL PROTECTED]:~$ host bugs.debian.org bugs.debian.org has address 140.211.166.43 bugs.debian.org mail is handled by 0 bugs.debian.org. By the way, is there any way to test reportbug without actually reporting a bug. (test packet foo?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sending a bug report with reportbug fails
I configured reportbug with defaults (I don't use local mailserver for delivery and reportbug uses bugs.debian.org as SMTP host). However when I try to file a bug report, sending fails with message: SMTP send failure: (113, 'No route to host'). My firewall should permit all outgoing traffic so that shouldn't be a problem. Same problem occured today and two days ago. Any ideas what's going on? Is something down? Should I file a bug report? Againt what? P.S. I'm using just installed system (Installed etch which I had to upgrade to lenny because of missing screen control driver). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Buying debian compatible laptop.
Hello everyone, I've been using debian a couple of years (still a newbie for most of you hackers, though), but never installed it in laptop. Soon I'm buying a new laptop and want to make sure it works smoothly with debian. I assume the biggest problem is the screen controller. I tried to take a look at debian's and X.org's documentation, but didn't find a clear answer which screen controllers work cleanly with debian (and X.org) and which not. In the past: * ATI's drivers were a big problem (is that still the case?) * Nvidia drivers worked (at least after installing closed source drivers manually) (is that still the case?) * I've heard that Intel GMA should just work (is that the case?) Are there any other possible critical hardware incompatibilities (fx. with sound system, dvd-drives, ethernet cards etc.) I should know about Any advice is welcome, Thanks, Joona Kiiski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Aptitude question (related to markauto and unmarkauto)
I've collected a list of packages (about 50-100 packages) which I want to be installed in my debian system. Is there a command by using which I could tell apptitude to unmarkauto all those packages and at the same time markauto all the rest installed packages. aptitude markauto ~i aptitude markauto $list is something I'm looking for, but it has a nice side effect first removing everything and then putting everything back. Is there a way to combine those commands? (Tried to read man and docs, but didn't find answer) Joona Kiiski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to find all configuration files I've edited?
Hi, is there command or simple shell script available to find all configuration files in /etc-directory which I've edited. Joona Kiiski
Question about apt and pinning
Hi, I've a little question about apt-pinning. I'm running debian testing and when running 'apt-get dist-upgrade' apt tells me that it wants to remove packet 'xmaxima'. This is quite logical, since currently xmaxima is out of the testing. To prevent this I wrote in /etc/apt/preferences file: Package: xmaxima Pin: version * Pin-Priority: 1200 Still when running 'apt-get dist-upgrade' apt tells me that it wants to remove xmaxima. Then I thought: maybe it's because apt can't find xmaxima-packet at all. And after some consideration I wrote a new apt_preferences file and made necessary changes to sources.list. /etc/apt/preferences: Package: * Pin: release a=testing Pin-Priority: 700 Package: * Pin: release a=stable Pin-Priority: 100 Package: * Pin: release a=unstable Pin-Priority: 1 Package: xmaxima Pin: version * Pin-Priority: 1200 Still when running 'apt-get update apt-get dist-upgrade' I get that apt wants to remove xmaxima though it's surely present in both stable and unstable distribution. Question: Am I doing something wrong? APT HOWTO section 3.10 states that if packet has a priority 1000 it should _never_ be replaced by apt. Is there any way to force apt not to remove packet when doing dist-upgrade? P.S. Of course it's possible to run 'apt-get dist-upgrade apt-get install xmaxima/unstable', but wasn't the whole idea behind apt-pinning to avoid this kind of mess?
Question about apt-pinning
Hi, I've a little question about apt-pinning. I'm running debian testing and when running 'apt-get dist-upgrade' apt tells me that it wants to remove packet 'xmaxima'. This is quite logical, since currently xmaxima is out of the testing. To prevent this I wrote in /etc/apt/preferences file: Package: xmaxima Pin: version * Pin-Priority: 1200 Still when running 'apt-get dist-upgrade' apt tells me that it wants to remove xmaxima. Then I thought: maybe it's because apt can't find xmaxima-packet at all. And after some consideration I wrote a new apt_preferences file and made necessary changes to sources.list. /etc/apt/preferences: Package: * Pin: release a=testing Pin-Priority: 700 Package: * Pin: release a=stable Pin-Priority: 100 Package: * Pin: release a=unstable Pin-Priority: 1 Package: xmaxima Pin: version * Pin-Priority: 1200 Still when running 'apt-get update apt-get dist-upgrade' I get that apt wants to remove xmaxima though it's surely present in both stable and unstable distribution. Question: Am I doing something wrong? APT HOWTO section 3.10 states that if packet has a priority 1000 it should _never_ be replaced by apt. Is there any way to force apt not to remove packet when doing dist-upgrade? P.S. Of course it's possible to run 'apt-get dist-upgrade apt-get install xmaxima/unstable', but wasn't the whole idea behind apt-pinning to avoid this kind of mess?
Many packages missing from testing
Hi! Now for about two weeks there have been many packages out of testing. I'm must wondering what's the point? Those missing packages prevent me from upgrading because there are many among those which I desperatily need and I don't want to start hacking apt. Wouldn't it be better to have an unstable version of packages in testing than no version at all! Okay, you are pros, I'm just a newbie and there must be a good reason for this, this situation is just irritating. Maybe you could consider having four versions of debian in transition phase, like: stable, testing, testing-new, unstable. And when 99.5% packages would have entered testing-new it could replace testing. Just an idea, maybe it would just make things too complicated for developers and maintainers. -- Joona Kiiski [EMAIL PROTECTED]
Re: Many packages missing from testing
Certainly not. If you want unstable packages, then use *unstable*. If you want to help test the next Debian release, then use *testing*. If you want something that will always work, then use *stable*. Yes, I've tried them all. * Unstable was a bit too unstable for my taste. * Stable is fine, but I don't really enjoy using only old software. Often there comes new interesting software in testing, which really is stable enough for me and installing it in stable is hard (download+check dependencies+compile+install) and could easily lead to bad problems (library incompatibilities etc.). * So that's why my choice is and will be testing. 98% of the time it fits my bill perfectly. And sometimes (I hope) I can file an useful bug report which can help the development of debian. It's just sad that rarely testing gets 'broken' as badly as it's now, but if it can't be avoided then it can't be avoided and that's it. I can live with it: just postpone 'dist-upgrade' long enough or change to unstable for a while. My purpose was not to complain. I have some coding experience (not much but some) and I can only imagine what kind of mess so large library transition could be with all those new bugs and problems hiding around. I really appriciate that great job you volunteer for, really. I just wanted to share my view to this subject (and I'm quite sure there are hundreds of other testing users who think similar way as I do), but as I wrote earlier in this message if this subject has already been dicided by pros and 'breaking' testing once in a while cannot be avoided, then let it be that way. Thank you for your answers, -- Joona Kiiski [EMAIL PROTECTED]
