Bug#1070270: riseup-vpn: client no longer works due to cert verification problem
On 5/10/24 07:26, Nilesh Patra wrote: Going for an upload to unstable followed by an s-p-u. [2]: https://people.debian.org/~nilesh/riseup-vpn-stable/ I was finally able to install 0.21.11+ds1-5+deb12u1 from the above on my bookworm test system and it fixed things and the vpn is working again! An upload to s-p-u would be great. Thanks, -- Matt Taggart m...@lackof.org
Bug#1070270: riseup-vpn: client no longer works due to cert verification problem
Package: riseup-vpn Version: 0.21.11+ds1-5+b1 Severity: grave When attempting to run the bookworm riseup-vpn package, it fails to connect to riseup's servers and gives the following output: 2024/05/01 18:21:23 Error fetching eip v3 json:https://api.black.riseup.net/3/config/eip-service.json My understanding is that this is due to the package failing to be able to verify the current LetsEncrypt cert that host is using. More details at https://0xacab.org/leap/bitmask-vpn/-/issues/768 (supposedly the current upstream snap has this fixed, but I haven't tried it) As this breaks what the package is supposed to do (at least when using riseup as provider, maybe there is a way to point it elsewhere?) I think this is grave. Also I think it might be a good candidate for being fixed in a stable release update. Thanks, -- Matt Taggart m...@lackof.org
Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency
On 10/8/19 2:06 PM, Moritz Mühlenhoff wrote: > On Mon, Sep 30, 2019 at 09:34:46AM -0700, Matt Taggart wrote: >> Hi, >> >> >> I think it's fine for check-mk to be removed from unstable, if it does >> end up in Debian again it will be repackaged and should go through NEW >> again anyway. > > Ack, I've just filed a removal bug. I suppose the version from > experimental should be removed as well? Yes. Thanks, -- Matt Taggart tagg...@debian.org
Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency
Hi, Thanks for opening this bug, this should have been discussed a while ago. check-mk in debian was originally packaged and uploaded for Debian when it was a pretty basic nagios add-on. Since then upstream has both continued to add features and automation layers above that basic functionality (OMD, BI, etc) and also at the same time made a commercial business out of selling support and added non-FOSS components. It is now very difficult to support the check-mk core functionality as it's packaged in Debian. I began packaging the 1.4.0 stable release and realized that the levels of integration of the core functionality and the higher layers were going to make it nearly impossible to untangle. For check-mk to continue in Debian we'd need to either: 1) fork the "Checkmk Raw Edition (CRE)" and work to remove the dependencies and non-FOSS integration, maintaining the fork over time and merging changes made to the core agents. 2) repackage the FOSS components, adopting all of upstream's levels of automation and integration as a monolithic package and no longer just be an add-on for other monitoring system. My own use of check-mk involved using a puppet module to automatically configure checks for new systems as they were added, by automatically editing config files. This does not work well with the "full stack" model where the administrator is expected to do things via a UI. So option #2 is not interesting to me, and option #1 sounds like a lot of work. What I need to do next is investigate icinga2's equivalent functionality and see if that's a good replacement option. I think it's fine for check-mk to be removed from unstable, if it does end up in Debian again it will be repackaged and should go through NEW again anyway. Thanks, -- Matt Taggart tagg...@debian.org
Bug#886367: intel-microcode: more meltdown/spectre info
I read that RHEL is already issuing microcode updates for RHEL7. I read it second hand at https://lists.bufferbloat.net/pipermail/cerowrt-devel/2018-January/08.html But maybe there is an official URL somewhere? I found the following pages https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/articles/3311301 But I couldn't find any reference to microcode versions. -- Matt Taggart tagg...@debian.org
Bug#886367: intel-microcode: coming updates for meltdown/spectre
Package: intel-microcode Version: 3.20171117.1 Severity: grave It's been rumored that Intel will be releasing microcode updates to (partially?) mitigate some of the effects of meltdown and spectre. It appears that the latest version on the website is still 20171117. Any news of what this will be and when it will happen? Thanks, -- Matt Taggart tagg...@debian.org
Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?
On 10/06/2017 02:28 PM, Salvatore Bonaccorso wrote: Control: notfixed -1 1.2.8p26-1 Hi! On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:check-mk package: #865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py I looked up the source for 1.2.8p26-1. The fix for CVE-2017-9781 is http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1 which does not yet seem to be applied to 1.2.8p26-1? Can you please double-check? Note, there is a second CVE now for check-mk, that one got addressed in 1.2.8p26, but it's not clear yet in which version in was introduced. Hi, You are right, the fix for CVE-2017-9781, which upstream calls "werk #4757" is _not_ in 1.2.8p26. I was confused with upstream #5208 when I wrote the changelog that closed the bug. Upstream lists the following security related fixes for 1.2.8 == #5208 http://mathias-kettner.com/check_mk_werks.php?werk_id=5208=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=673360408b90f99bd54cf936091cff08d979a057 #4902 http://mathias-kettner.com/check_mk_werks.php?werk_id=4902=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=96e39a0f024d9b2b521576c1eb71aca7fb3e818d #7661 (fixed in 1.4.0p8, supposedly fixed in 1.2.8p25?) http://mathias-kettner.com/check_mk_werks.php?werk_id=7661=yes #7631 http://mathias-kettner.com/check_mk_werks.php?werk_id=7631=yes #3970 (fixed in 1.2.8p14) http://mathias-kettner.com/check_mk_werks.php?werk_id=3970=yes #3855 (fixed in 1.2.8p11) http://mathias-kettner.com/check_mk_werks.php?werk_id=3855=yes #3743 (fixed in 1.2.8p10) http://mathias-kettner.com/check_mk_werks.php?werk_id=3743=yes Full list of changes for 1.2.8p26 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw=1.2.8=1.2.8p26=yes Full list of changes for 1.4.0p14 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw=1.4.0=1.4.0p14=yes which additionally lists #4757 (as you mentioned above, fixed in 1.4.0p6) http://mathias-kettner.com/check_mk_werks.php?werk_id=4757=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=14a5b79c6f549502244a60146ed6831dc3473f2a #7643 (only in 1.4 and newer) http://mathias-kettner.com/check_mk_werks.php?werk_id=7643=yes So I think the Debian 1.2.8p16 package is only missing #4757. I will ask upstream if they intend to fix #4757 in the 1.2.8 series. Unfortunately due to how the upstream tarball/build works, it is tricky to patch upstream files. If upstream doesn't intend to include this fix I can generate a patch to make it work. I had started working on packaging 1.4.0 as a way to fix these security bugs (and even did an upload to experimental) but I recently learned from upstream that: "The use of Check_MK without OMD environment and customization of paths is explicitly not supported anymore." ie you can't use check-mk stand-alone, you have to use OMD (and livestatus/WATO/multisite, the whole stack) and you have to use upstream's installer to upstream's paths. It's very much the "network appliance" model (or flatpak, docker image, etc) I don't know if we'll be able to make this work in Debian. (not to mention that nagios is gone and icinga1 will go away at some point) That prompted me to go back to 1.2.8 and package the latest release there in order to at least have something working without the security bugs. -- Matt Taggart tagg...@debian.org
Bug#865497: Wheezy update of check-mk?
Hi Raphael! Raphael Hertzog writes: > Hello Matt, > > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of check-mk: > https://security-tracker.debian.org/tracker/CVE-2017-9781 > > Would you like to take care of this yourself? > > The code in wheezy is different from the 1.4.x version which has been > patched upstream but I believe that a similar issue must exist since > I have seen no HTML escaping in any code showing errors. The commit message explicitly references the 1.4 branch, but I also see that the code exists in 1.2.8p16 (buster/sid). For buster/sid I will update to new 1.4 based upstream with the patch. The 1.2.6p12-1 based versions in wheezy-backports-sloppy and jessie-backports are different still, but we should push to make those go away by getting buster fixed and backporting that to w-b-s, j-b-s, and w-b. I agree that the code is pretty different in 1.1.12p7-1 (wheezy). I would appreciate help generating a patch for that that version. > That said it really depends on whether user input ends > up in the error message associated to the various exceptions > and it's hard to tell from a quick look at the code without trying. > > The traceback itself seems to be output in %s but that doesn't > prevent XSS. > > In any case, if you mant to handle this yourself, please follow the > workflow we have defined here: > https://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-...@lists.debian.org > (via a debdiff, or with an URL pointing to the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > You can also opt-out from receiving future similar emails in your > answer and then the LTS Team will take care of check-mk updates > for the LTS releases. The check-mk source package is sort of weird, it uses tarballs within the orig.tar.gz, so using a normal debian package diff, or even patching at configure time doesn't work, it has to happen after the install step runs setup.sh. I am happy for the LTS team to prepare the wheezy update and I can help with testing. I will work on uploading a fixed 1.4 version to sid in the next day. Sound OK? -- Matt Taggart tagg...@debian.org
Bug#725768: tkcvs: tk depends
Hi Tim, What is going on with #725768? (tkcvs depends issue). I recently installed a new jessie system and discovered my favorite graphical diff tool, tkdiff, missing. After tracking down that tkcvs provides it I discovered it's not in jessie :( Maybe we can get it in stretch and then I can do a jessie backport? I'd also be happy to use something not based on '90's technology, but I have yet to find anything that works as well. If people have suggestions I would love to hear them. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758883: check-mk: CVE info
I did some research on #758883:
1) CVE-2014-5338 was fixed in 1.2.5i4 with this commit
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=076468b10e660abde6c459a4aa3ce8e07722
The actions.py change should work as is.
The htmllib.py part of the patch needs some minor adjusting but should work.
2) CVE-2014-5339 was also fixed in 1.2.5i4 with this commit
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=78c0c2779393a822f62924c662b8022572a1be9c
The 1.2.2p3 version of the code is
if not html.has_var('selection'):
sel_id = file('/proc/sys/kernel/random/uuid').read().strip()
html.add_var('selection', sel_id)
return html.var('selection')
Whereas the 1.2.5i4 version uses
if not html.has_var('selection'):
sel_id = lib.gen_id()
html.add_var('selection', sel_id)
else:
sel_id = html.var('selection')
# Avoid illegal file access by introducing .. or /
if not re.match(^[-0-9a-zA-Z]+$, sel_id):
return lib.gen_id()
else:
return sel_id
lib.gen_id doesn't exist in 1.2.2p3 so the patch won't word. But maybe
the patch could be adapted to do the same check around the old way?
3) CVE-2014-5340 was also fixed in 1.2.5i4 with this commit
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=0fe2a45b299a8f5c5da332410eec2c45aac2ba1e
which uses the python ast library if it exists. ast is a standard lib
and is available on wheezy. This patch should work (might need a little
adjusting, but looks ok)
It would be best to move to a release newer than 1.2.5i4 to fix these
(and other things) but in the interest of getting check-mk back in
jessie, maybe it would make sense to patch 1.2.2p3?
Thanks,
--
Matt Taggart
tagg...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742689: check-mk: more CVE info
I am looking at the CVEs in #742689. The URL listed http://packetstormsecurity.com/files/125850/DTC-A-20140324-002.txt lists 7 problems, but claims that upstream 1.2.2p3 (in sid) fixed 5 of them. The remaining 2 are: 5) Missing CSRF (Cross-Site Request Forgery) token allows execution of arbitrary commands (CVE-2014-2330) 6) Multiple use of exec-like function calls which allow arbitrary commands (CVE-2014-2331) These CVE numbers appear to be reserved, but I can't find any details other than the brief mention in http://packetstormsecurity.com/files/125850/DTC-A-20140324-002.txt Most of the links on https://security-tracker.debian.org/tracker/CVE-2014-2330 https://security-tracker.debian.org/tracker/CVE-2014-2331 don't give any info, the RedHat link is for the full set of things and it's not clear to me if they fixed these explicitly. Maybe the brief descriptions on the packetstormsecurity will be enough for someone on the security team to determine if there is anything to be done. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547092: nrpe ssl security problem
As pointed out in a previous message to the bug, #547092 nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems is severity grave due to the security problem it introduces in the service (but not critical since the problem is limited to the nrpe service). I have adjusted it. This bug hasn't had any activity for almost a year and was mostly shouting before that. This package shouldn't be in testing/stable until this is fixed lest others (as I did) spend a bunch of effort implementing lots of nrpe based checks before realizing they just opened a security hole on all their systems... If this can't be solved, maybe we could recommend better alternatives? Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680236: debirf: fails to generate minimal image of wheezy on wheezy as a normal user
I get the same error as Lucas when trying to generate a wheezy image on wheezy as a normal user: Setting up sysvinit (2.88dsf-22.1) ... sysvinit: creating /run/initctl ln: failed to create symbolic link `/dev/initctl.new': Permission denied dpkg: error processing sysvinit (--configure): subprocess installed post-installation script returned error exit status 1 Setting up e2fsprogs (1.42.5-1) ... Errors were encountered while processing: sysvinit I am also running debirf 0.32 -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565738: drupal: shouldn't enable on all sites by default
Matt, can you please explain why you think this bug is 'grave' and not just = 'important'? To me, grave definition is: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package IMO it's a security bug, but downgrade if you disagree. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592025: fossology: 1.2.0 problems
Is this fixed by your 1.2.0-2 upload? If so, please ask for a freeze exceptio n. Mostly, I discovered one other upstream RC fix (svn 3324) that I will add to 1.2.0-3 and then I will test and hopefully close this bug and ask for an exception. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592025: fossology: 1.2.0 problems
Package: fossology Version: 1.2.0-1 Severity: serious When attempting to use 1.2.0-1 to scan a Debian source DVD image several of the agents fail to run properly and give inconsistant results. The upstream 1.2.0 release has problems. They have fixes for most of the bugs I ran into, but 1.2.0-1 is certainly unsuitable for release, so I am filing this bug. I am preparing a 1.2.0-2 release with all the fixes we know about, and then we'll run some tests on that and confirm things are working before closing this bug. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560523: spew: Intent to NMU (FTBFS: common.h:111: error: new declaration 'const char* basename(char*)')
Well, that bug has been open since 2009-12-11, so it's better to be closed by ourself in the mean time due to Debian release being very near. I heard back from upstream, he asked for a couple days to do an upstream release, which I think we can wait for. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560523: spew: Intent to NMU (FTBFS: common.h:111: error: new declaration 'const char* basename(char*)')
I've been fixing important and above bugs for release lately and noticed this one. Please let me know if this bug is already been worked on or if it's okay to NMU the package. After I forwarded this bug to upstream he committed a fix and said he was going to relase a new version, but hasn't yet. I will ping again. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559582: Bug#541854: fossology: diff for NMU version 1.1.0-1.2
I've prepared an NMU for fossology (versioned as 1.1.0-1.2) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. I also have an upload prepared, but I haven't had time to test it. I'm pretty sure you haven't tested yours either. I suppose I could upload mine untested, but I think that is generally considered bad. Please remove yours and I will try to get my testing done soon so I can upload. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574331: libnet-dns-perl: FTBFS: tests failed
It looks like the buildds are all able to build 0.66-2, but I suppose that could be because they have network access? The changelog entry mentioned fixing it, so I am going assume it's fixed and will downgrade this bug so the package can move into testing, but I will leave it open and maybe Florian or Lucas can confirm that it works on a buildd without net access and close the bug. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550653: Depends on xpdf-utils
Package: fossology-agents Severity: important Hi, xpdf might not be shipped with Squeeze. Your package currently depends on xpdf-utils. Please adapt it to xpdf-utils's successor poppler-utils. OK, change is pending. On a related note, it would be good to know what's going on with #409510. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521864: fossology contains a non-free RFC
Fixed upstream with svn #1953 (the second occurance will be fixed based on that). I am discussing with upstream if they want to do a point release that would include this. If so I could move the Debian package to that, but if that isn't going to happen in a timely manner I can do a dfsg tarball of 1.0.0. -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521864: sha1 code in fossology
On of the fossology upstream developers pointed out that the code in
ununpack/sha1.{c,h} comes from the RFC as well and doesn't have a listed
license. So we need to ask the RFC upstream. There is now an upstream
fossology.org bug for this
http://bugs.linux-foundation.org/show_bug.cgi?id=326
Note: ununpack also uses md5.{c,h} but that code is listed as being under
the public domain, so should meet the DFSG and be GPL compatible.
--
Matt Taggart
tagg...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514028: ubuntu libc6
Hi Joao, Thanks for your bug report, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514028 I think this is definitely a bug and your patch looks good. But I can't repeat the behavior on lenny/sid and it appears you are running an Ubuntu intrepid libc6. Maybe it is doing additional malloc checking or something? I will downgrade the bug for now, but maybe we can still get it fixed in lenny. Thanks, -- Matt Taggart tagg...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500734: libmagic1: magic_load no longer appends .mime
Package: libmagic1
Version: 4.26-1
Severity: serious
The libmagic(3) man page says:
magic_load() adds â.mimeâ and/or â.mgcâ to the database filename as
appropriate.
and it indeed worked that way in etch. However it is no longer working in
sid. Attached is a sample program (written by my co-worker Neal Krawetz) to
demonstrate this, build it with
gcc testmagic.c -o testmagic -lmagic
then copy a magic file to /tmp for it to use
cp /usr/share/file/magic.mime /tmp/foo.mime
and run testmagic.
It is testing two things
1.) It should work when trying to magic_load /tmp/foo with a file named
/tmp/foo.mime. If it doesn't this is a direct contradiction of the manpage
and past behaviour.
2.) It should fail when trying to magic_load /tmp/foo.mime with a file
named /tmp/foo.mime. If it doesn't this is a direct contradiction of past
behaviour. Maybe it was enhanced to do-the-right-thing and check if the
file exists before appending .mime? Even so it still breaks in the case
where someone was expecting that behavior and there are both foo and
foo.mime files present.
This bug breaks all applications that uses libmagic and depend on this
behavior, so I think it's severity serious at least (for #1, #2 is
debatable).
Thanks,
--
Matt Taggart
[EMAIL PROTECTED]
#include stdlib.h
#include stdio.h
#include unistd.h
#include magic.h
int main ()
{
magic_t MagicCookie;
MagicCookie = magic_open(MAGIC_PRESERVE_ATIME|MAGIC_MIME);
if (MagicCookie == NULL)
{
fprintf(stderr,FATAL: Failed to initialize magic cookie\n);
exit(-1);
}
if (magic_load(MagicCookie,/tmp/foo) != 0)
{
fprintf(stderr,FATAL: Failed to load magic file: foo.mime\n);
}
else
{
fprintf(stderr,GOOD: Correctly loaded magic file: foo.mime\n);
}
if (magic_load(MagicCookie,/tmp/foo.mime) != 0)
{
fprintf(stderr,GOOD: Correctly failed to load magic file: foo.mime.mime\n);
}
else
{
fprintf(stderr,FATAL: Managed to load foo.mime when should have attempted to load foo.mime.mime\n);
}
}
Bug#457828: chkrootkit: Enye LKM signal
I can confirm this bug in 0.47-1.1 and it's also in upstream 0.48. Here's
the code from chkproc
/* Check for Enye LKM */
if (kill (12345, 58) = 0)
{
printf(Enye LKM found\n);
retdir+= errno;
}
I agree it's a bad idea.
--
Matt Taggart
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399271: nmh: 64-bit warnings
:1375: warning: field precision should have type 'int', but argument 4 has type 'long int' slocal.c:1375: warning: field precision should have type 'int', but argument 6 has type 'long int' slocal.c:1375: warning: field precision should have type 'int', but argument 4 has type 'long int' slocal.c:1375: warning: field precision should have type 'int', but argument 6 has type 'long int' slocal.c:1379: warning: field precision should have type 'int', but argument 4 has type 'long int' slocal.c:1379: warning: field precision should have type 'int', but argument 4 has type 'long int' I have confirmed that the fix-64bit-issues.txt patch sent to #399271 by dean gaudet eliminates all of the above warnings. Please apply it and forward upstream. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399271: nmh: segfault fix
Hi, I just reported nmh segfaulting in #425638. After some investigation this appears to be related to #399271 after all. I applied the short h/nhm.h patch from dean gaudet (not the 64bit patch) and my segfaults went away. yay! So consider this an endorsement of the patch, please apply and forward upstream. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370186: Bug#360554: hald-addon-storage scanning scsi disks
Sjoerd Simons writes... That's strange it shouldn't poll your scsi hard disks at all. On my scsi syst em the addon only runs for my scsi cd drive, not for my scsi hard drive. Could you mail the output of lshal on your system ? I wasn't totally sure that it's hal, but it seems to be the only thing that showed up in top(1) that coincides with the clicking. I tried shutting off everything I could think of and checked obvious cases like log files being written to, etc. I asked around and someone suggested that it might be the ext3 filesystem updating a timestamp in the superblock. That seems more likely than the hal thing I guess. So consider my problem fixed. It still seems like a waste for hal to be checking so often. It's too bad it has to poll at all, but I guess there's no way around that? I also realize the frequency is so that users can be quickly prompted when a CD is inserted. It would be nice to have a way to turn this feature down or off if you don't want it. Consider this a wishlist request for that. Sorry for the false alarm. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370186: hald-addon-storage scanning scsi disks
Hi, I'd like to report some similar behavior to what is listed in #360554 and #370186. hald-addon-storage is probing my scsi hard disk drives every few seconds, which causes them to click audibly as the drive heads move all the way from where they were (parked or doing something else) to wherever the probe needs them to be. This is, a) causing the premature wearing of the drive and consumption of power b) probably hurting performance as it can interrupt streaming reads/writes c) annoying because of the constant clicking sound This seems like a bad design decision. Can something else be done to detect whatever it's probing for? If not then maybe the frequency should be decreased. (but I guess maybe it wouldn't quickly detect drive changes and pop up a window or something?) I agree with the grave severity. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375904: flash video crashes browser
Package: galeon, firefox Version: 2.0.1-3, 1.5.dfsg+1.5.0.4-1 Severity: serious If you have the flash plugin installed and go to http://gamevideos.com/video/id/4282 and click on the buttons in the flash video viewer it causes both galeon and firefox (and maybe more?) to crash. I suspect the problem is in the flash viewer, but it shouldn't cause the browser to crash. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359777: possible bug in buildd?
Filippo Giunchedi writes... consider that array-util: Build-Depends: debhelper (= 4.0.0), linux-source-2.6.15 | linux-source-2.6, libgtk1.2-dev, libglib1.2-dev, gdk-imlib1-dev, imlib11-dev, automake1.9 | automaken, autoconf but the buildd only considers linux-source-2.6.15, is that normal for sbuild? I do agree that array-util should b-d on latest linux-source, I can prepare a n easy NMU, matt? I'll try to fix it today. If for some reason I don't get to it, you can. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346826: intent to upload sponsored NMU to fix xlibs-dev bug
Justin Pryzby writes... package xmms-fmradio tag 346826 patch thanks I intend to NMU a fix for this bug sponsored by some member of the QA group; patch attached. My pbuild result of this patch was clean, and produced a binary package with expected debdiff output from the most recent version in sid. Build logs and debdiff output are attached. Please note that maintainer uploads are preferred to NMUs! If you are able to upload, then please do so. Sorry, I have been neglecting this package as I am still trying to find FM tuner hardware I can use on my system (I no longer have ISA slots for my old tuner card). I will try to upload in the next day or two, if I don't you're welcome to NMU. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330157: paer.debian.org and kernel builds
Horms writes... We have a build problem with the kernel on hppa and I was hoping to use paer.debian.org to do some test builds. If there is a better machine please let me know. paer is the correct machine. Otherwise, would it be possible to get the following build dependancies installed in the sid chroot? gcc-4.0-hppa64 module-init-tools kernel-package (= 9.005) transfig xmlto dh-kpatches (= 0.99.3) Done. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306677: libc6: /lib64 goes away on upgrade, breaks amd64
Package: libc6 Version: 2.3.2.ds1-21 Severity: critical Justification: causes amd64 systems to become completely unusable upon dist-upgrade A person I know ran into a critical bug on amd64 today. He was apt-get dist-upgrading his system things broke horribly, ... Get:171 http://debian-amd64.alioth.debian.org sid/main telnet-ssl 0.17.24+0.1-7.1 [88.1kB] Fetched 105MB in 2m42s (649kB/s) Preconfiguring packages ... (Reading database ... 24453 files and directories currently installed.) Preparing to replace base-files 3.1.1.0.0.1.pure64 (using .../base-files_3.1.2-0.0.1_amd64.deb) ... Unpacking replacement base-files ... dpkg (subprocess): failed to exec rm for cleanup: No such file or directory dpkg: error while cleaning up: subprocess rm cleanup returned error exit status 2 Could not exec dpkg! E: Sub-process /usr/bin/dpkg returned an error code (100) and after that the existing shell was still working, but nothing would run, always complaining no such file or directory. dannf was able to figure out that the /lib64 - /lib symlink got deleted. All debian binary-amd64 binaries have /lib64 in their hardcoded PI like this, $ strings /bin/ls |head -1 /lib64/ld-linux-x86-64.so.2 So that's why everything was complaining no such file or directory. We were able to replace the symlink using the PI directly, /lib/ld-linux-x86-64.so.2 ln -s /lib64 /lib and then all things were back to normal. I started looking around for how this could have happened. Both libc6 and lsb-core provide /lib64. Looking at the lsb-core changelog, lsb (2.0-2) experimental; urgency=low ... * Include /lib64 in the AMD64 package rather than running mkdir in the postinst. ... -- Chris Lawrence [EMAIL PROTECTED] Mon, 20 Sep 2004 21:38:36 -0500 So lsb-core's old mkdir method was ensuring that that symlink got created and stuck around. Once the package moved to delivering it as a normal file it can be missing during an upgrade. So I'm speculating that in this case all the packages that provide /lib64 were providing it as a package file and being upgraded in the same pass. This caused /lib64 to go away and everything to blow up. Does that sound correct? I propose that libc6 is the correct package to ensure that /lib64 gets created and exists across upgrades. Even if we do move to multiarch, /lib64 is going to need to stick around for a very long time. If at some point in the distant future we can finally get rid of it, whatever libc package we're using at that point can check for it and remove it in a package script. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292478: oops on boot with usb cdburner attached
[EMAIL PROTECTED] writes... Works fine for me booting with Kernel 2.6.8-2, IBM ThinkPad R40e type 2684, external USB Plextor PX-S2410TU using USB 1.1. What USB controller does that use? Can you provide lspci output? Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292478: More on this bug
Daniel Burrows writes... I've run into what looks like the same thing on a new Dell Latitude x300. An I'm not convinced that the two Dell related bug reports in this bug are related to the original problem that I reported, other than the fact that they are all probably bugs due to the quality of the USB layer in 2.6.8. My original problem shows up on all kernels before 2.6.10, the Dell problem is in 2.6.8 but not 2.6.7... Maybe this bug should be cloned and one of the clones retitled to something describing the Dell problem? -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299731: kernel-image-2.6-686-smp: SMP kernel causes krenele panic during boot
Aprotim Sanyal writes..., Tested on both testing and unstable. On my (old) dual-P3 system (Asus CUV4X- D), booting the SMP kernels for 2.6.8 or 2.6.10 causes a hand on boot, with the message Kernel panic: attempted to kill init! shortly after printi ng out some IDE bud information. Non-SMP kernels boot normally (though, of course, without SMP support). Adding noapic or acpi=no to the boot li ne in either LILO or GRUB makes a difference to this problem. Hmm, interesting problem I think more info is needed. Could you capture and send the boot logs of the success and failure cases using another machine and a serial cable? Having those two files to diff (I use tkdiff) is often useful in finding the problem. Here's what I do: Connect the two machines together via a null modem cable Setup an additional entry in the bootloader to use serial console with your desired settings for the serial port you're using (I add console=ttyS0,38400n8 to the cmdline for my setup). For a standard Debian grub setup I added this line # altoptions=(serial) console=ttyS0,38400n8 and ran update-grub. This creates a serial boot option for each of my installed kernels which is pretty nice. For lilo you can just create additional images adding the console option above. Run something like minicom or cu on the logging machine and configure to use the correct serial port and your desired settings Turn on logging in that program (minicom has a way to do this, for cu you might want to run within script(1) ) Reboot the machine and select the serial console boot method When done logging (after the hang or successful boot) close the logfile to ensure that and buffered lines are flushed to the log file (same command in minicom as to start logging IIRC). Send the logs to the BTS as mime attachments. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290398: Additional information on oom_killer debacle
Alex Fernandez writes... USB memory stick was mounted as ramfs, since vfat was not working. Relevant line from /etc/fstab: /dev/sda/mnt/usbkey ramfs rw,user,noauto 0 0 That's your problem then. ramfs is, like the name suggests, a filesystem that resides in memory. mount will ignore the /dev/sda you specified and just create a ramfs instance at /mnt/usbkey. Try umounting it and remounting it and you'll see that the contents disappear. If you specify ramfs without any options the default behavior is to create a ramfs with a maximum size of one half of physical memory. ramfs only consumes memory for what you're using, so when you started copying stuff in there it started to grow and apparently the rest of the system was already using more that half of the memory so once the ramfs got big enough it triggered the OOM. I think this bug can be closed, ok Alex? -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290398: Additional information on oom_killer debacle
Matt Taggart writes... Alex Fernandez writes... USB memory stick was mounted as ramfs, since vfat was not working. Relevant line from /etc/fstab: /dev/sda/mnt/usbkey ramfs rw,user,noauto 0 0 That's your problem then. ramfs is, like the name suggests, a filesystem that resides in memory. mount will ignore the /dev/sda you specified and just create a ramfs instance at /mnt/usbkey. Try umounting it and remounting it an d you'll see that the contents disappear. If you specify ramfs without any options the default behavior is to create a ramfs with a maximum size of one half of physical memory. Oops, I think I'm confusing ramfs with tmpfs here but the problem is still similar, you're using ram and not the flash device. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292478: more info on #292478: oops on boot with usb cdburner attached
I tried a few tests: 1) I have another mainboard (brand is FIC) that uses the SiS746 southbridge so I tested on it as well. I can repeat the same problem as in the original report. 2) I tried a couple other USB mass storage devices, * a memory card reader with memory card, non-bootable * a flash drive, bootable and I could not repeat the problem. Trying with a different USB cdrom drive would be interesting, but unfortunately I don't have one. When I get a chance I will test with this drive on a non-sis746 system/controller. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291500: Downgrading severity
severity 291500 normal thanks Since the package seems to build fine, I am downgrading the severity until it can be reproduced (and hopefully the package can move into testing). If future versions build properly on the arm buildd then I think this bug should be closed. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293303: lsbdev: RoM; buggy, orphaned upstream
Package: ftp.debian.org Severity: critical lsbdev provides an LSB development environment via a chroot with bind mounts. This system is complicated and buggy(4 RC bugs, 4 non-RC), it affects other packages on the system (interferes with upgrades) and has caused data loss due to misunderstandings and bugs in bind mounting. Overall it sucks and upstream has mostly abandoned this approach and has switched to a compiler wrapper system instead. I believe it is possible to re-implement this system in a way that doesn't rely on bind mounting, but until this is done upstream, this package does not belong in Debian. Please remove from testing and unstable. I'd also like to apologize for taking so long to make the decision to remove this package. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292467: comp broken (at least for external editors, maybe more)
Package: exmh
Version: 1:2.7.2-1
Severity: grave
After upgrading exmh today when I click on the Comp button I get an
Error Info dialog popup with the following contents,
can't read install(dir,bin): no such variable
while executing
exec $wish -f $install(dir,bin)/exmh-async -- [winfo name .] xterm +sb
-e vim $draft
(eval body line 1)
invoked from within
eval {exec $wish -f $install(dir,bin)/exmh-async -- [winfo name .]}
[lrange $editor($type) 1 end] {$draft }
(exmh-async* arm line 4)
invoked from within
switch -glob -- $editor($type) {
*mxedit* {
if ![info exists exmh(editInterp)] {
set exmh(editInterp) mxedit
}
if ![info exists ex...
(procedure EditStart line 20)
invoked from within
EditStart $path $edittype
(procedure EditWhatNow line 16)
invoked from within
EditWhatNow $draftID prog
(procedure Edit_Draft line 9)
invoked from within
Edit_Draft
(procedure Msg_Compose line 16)
invoked from within
Msg_Compose
invoked from within
.msgframe.mid.right.bot.comp invoke
(uplevel body line 1)
invoked from within
uplevel #0 [list $w invoke]
(procedure tk::ButtonUp line 22)
invoked from within
tk::ButtonUp .msgframe.mid.right.bot.comp
(command bound to event)
and a new compose window fails to come up. I specify xterm +sb -e vim
as my editor in preferences.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages exmh depends on:
ii metamail 2.7-46An implementation of MIME
ii mime-support 3.29-1MIME files 'mime.types' 'mailcap
ii nmh [mh] 1.1-release-3 A set of electronic mail handling
ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8
ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8
ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 -
ii tk8.4 [wish] 8.4.9-1 Tk toolkit for Tcl and X11, v8.4 -
-- no debconf information
--
Matt Taggart
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
