Bug#923606: beancount: FTBFS randomly (gpg-related race condition)
severity -1 important thanks Hi Santiago, On Sat, Mar 02, 2019 at 06:03:10PM +, Santiago Vila wrote: > I tried to build this package in buster but it failed: > [...] > try: > > os.unlink(entry.name, dir_fd=topfd) > E FileNotFoundError: [Errno 2] No such file or directory: > 'S.gpg-agent.browser' [...] > The above is just how the build ends and not necessarily the most relevant > part, > so I've put a bunch of failed build logs here: > > https://people.debian.org/~sanvila/build-logs/beancount/ > > The failure happens randomly. Sometimes it happens, sometimes it does not, > but the failure rate is so high that we can't really say that the package > "builds from source and without failure". thanks for this bug report, I had no idea about this flakiness in the build. > This failure is similar to another one which I reported before in another > package: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906335 > > but I'm not really sure if that helps. > > If you need a test machine where this happens almost all the time, please > contact me > privately and I will gladly offer ssh access. Similarly to the other bug you mention, I think the incidence of this FTBFS is low... at least elsewhere w.r.t. your build environment. I've personal never witnessed this, and I'm aware of a bunch of other people who have built from scratch without issues. More to the point, reproducible building the package is working fine on at least four architectures, including the one you are testing on: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/beancount.html On that basis, I'm lowering the priority to important. Still, I think the bug should be fixed, and I will do so (most likely ignoring the rm error, as that means no cleanup is needed). But I will not necessarily do this in time for the next release. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
Package: texlive-fonts-extra
Version: 2016.20170123-3
Severity: serious
Heya, the version of texlive-fonts-extra currently in Debian/etxting causes
failure in building (with pdflatex) LaTeX files that use the "txsys" font. See
below for a minimal example, and the attached .fls and .tex files.
The error message is:
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+540/600 --dpi 540
txsys
mktexpk: don't know how to create bitmap font for txsys.
mktexpk: perhaps txsys is missing from the map file.
kpathsea: Appending font creation commands to missfont.log.
)
!pdfTeX error: pdflatex (file txsys): Font txsys at 540 not found
==> Fatal error occurred, no output PDF file produced!
I've tried both package version -3 (currently in testing) and -4 (in unstable,
waiting for unblock), and they both fail in the same way.
Suggestions on how to temporarily work-around this issue are very welcome, as
it's blocking for me.
With many thanks for your help and for maintaining TeXLive in Debian!
Cheers.
-- Package-specific info:
##
\documentclass[sigconf]{acmart}
\begin{document}
Lorem Ipsum
\begin{itemize}
\item foo
\end{itemize}
\end{document}
##
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages texlive-fonts-extra depends on:
ii fonts-cabin1.5-2
ii fonts-comfortaa2.003-1
ii fonts-croscore 20161116-1
ii fonts-crosextra-caladea20130214-1
ii fonts-crosextra-carlito20130920-1
ii fonts-dejavu-core 2.37-1
ii fonts-dejavu-extra 2.37-1
ii fonts-ebgaramond 0.016-1
ii fonts-ebgaramond-extra 0.016-1
ii fonts-font-awesome 4.7.0~dfsg-1
ii fonts-freefont-otf 20120503-6
ii fonts-freefont-ttf 20120503-6
ii fonts-gfs-artemisia1.1-5
ii fonts-gfs-complutum1.1-6
ii fonts-gfs-didot1.1-6
ii fonts-gfs-neohellenic 1.1-6
ii fonts-gfs-olga 1.1-5
ii fonts-gfs-solomos 1.1-5
ii fonts-junicode 0.7.8-2
ii fonts-lato 2.0-1
ii fonts-linuxlibertine 5.3.0-2
ii fonts-lobstertwo 2.0-2
ii fonts-noto-hinted 20161116-1
ii fonts-oflb-asana-math 000.907-6
ii fonts-roboto-hinted2:0~20160106-2
ii fonts-sil-gentium 20081126:1.03-1
ii fonts-sil-gentium-basic1.1-7
ii fonts-sil-gentiumplus 5.000-1
ii fonts-sil-gentiumplus-compact 5.000-2
ii fonts-stix 1.1.1-4
ii tex-common 6.06
ii texlive-base 2016.20170123-3
ii ttf-adf-accanthis 0.20090423-2
ii ttf-adf-gillius0.20090423-2
ii ttf-adf-universalis0.20090423-2
Versions of packages texlive-fonts-extra recommends:
ii texlive-fonts-extra-doc 2016.20170123-3
ii texlive-latex-extra 2016.20170123-3
Versions of packages texlive-fonts-extra suggests:
pn cm-super
Versions of packages tex-common depends on:
ii dpkg 1.18.22
ii ucf 3.0036
Versions of packages tex-common suggests:
ii debhelper 10.2.5
Versions of packages texlive-fonts-extra is related to:
ii tex-common6.06
ii texlive-binaries 2016.20160513.41080.dfsg-1
-- debconf information:
tex-common/check_texmf_missing:
tex-common/check_texmf_wrong:
\documentclass[sigconf]{acmart}
\begin{document}
Lorem Ipsum
\begin{itemize}
\item foo
\end{itemize}
\end{document}
PWD /tmp
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT txsys-missing-from-map-file.tex
OUTPUT txsys-missing-from-map-file.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr9.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
First of all thanks for your quick feedback, Hilmar! On Fri, Feb 24, 2017 at 11:33:48AM +0100, Hilmar Preuße wrote: > I've no clue why mktexpk is even started, as the txsys is available as type1 > font. The MWE works fine on my box. Please enter a few commands and send the > output: > > locate txsys > grep txsys /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex* > grep txsys /var/lib/texmf/fonts/map/pdftex/updmap/pdftex* zack@timira:~$ locate txsys /home/srv/src/unix-history-repo/sys/boot/i386/btx/lib/btxsys.s /home/srv/src/unix-history-repo/sys/boot/pc98/btx/lib/btxsys.s /usr/share/texlive/texmf-dist/fonts/tfm/public/newtx/txsys.tfm /usr/share/texlive/texmf-dist/fonts/type1/public/newtx/txsys.pfb zack@timira:~$ grep txsys /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex* /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex_dl14.map:txsys txsys
Bug#856020: mktexpk: don't know how to create bitmap font for txsys
On Fri, Feb 24, 2017 at 01:25:35PM +0100, Hilmar Preuße wrote: > Missed one: Could you temporarily rename that file and try again? > /home/zack/.texlive2016/texmf-var/fonts/map/pdftex/updmap/pdftex.map Moving it away fixed the issue. Thanks! Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#907165: package installation fails with "ERROR: install script from ess package failed"
Package: ess Version: 17.11-3 Severity: serious scaramouche $ sudo dpkg --configure ess Setting up ess (17.11-3) ... Install emacsen-common for emacs25 emacsen-common: Handling install of emacsen flavor emacs25 Install ess for emacs25 install/ess: Handling install for emacsen flavor emacs25 ERROR: install script from ess package failed dpkg: error processing package ess (--configure): installed ess package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: ess I've noticed the above failure while upgrading testing. I've tried removing (worked) and installing from scratch (failed in the same way as above). Previous version in testing was working fine. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) 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) LSM: AppArmor: enabled Versions of packages ess depends on: ii dpkg1.19.0.5+b1 ii emacsen-common 2.0.8 ii install-info6.5.0.dfsg.1-4 Versions of packages ess recommends: ii r-base-core 3.5.1-1+b1 Versions of packages ess suggests: pn jags pn julia pn pspp pn xlispstat -- no debconf information
Bug#907165: package installation fails with "ERROR: install script from ess package failed"
On Fri, Aug 24, 2018 at 06:40:24AM -0500, Dirk Eddelbuettel wrote: > and it is as 17.11-4 in 'experimental' (I was debating dropping it into [...] > Can you try the 'elpa-ess' and 'ess' (transition) package set, please? > >https://packages.debian.org/source/experimental/ess I can confirm that installing elpa-ess 17.11-4 for experimental worked just fine. Thanks! -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917954: fava: Incomplete debian/copyright?
On Tue, Jan 01, 2019 at 03:07:02PM +, Chris Lamb wrote: > I just ACCEPTed fava from NEW but noticed it was missing attribution > in debian/copyright for at least some code embedded in fava/static/gen/app.js. > > This is in no way exhaustive so please check over the entire package > carefully and address these on your next upload. Thanks, nice catch. I've fixed this specific occurrence (in git) and looked for others, without finding any. I'm postponing package upload, waiting for beancount (a fava dependency) to clear NEW too. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917960: Bug #917960 in beancount marked as pending
Control: tag -1 pending Hello, Bug #917960 in beancount reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/applications/beancount/commit/f53ee91b7b269acbe75e8d5b5599d7eca9dbe762 copyright: document missing copyright and license for sorttable.js Closes: #917960 (this message was generated automatically) -- Greetings https://bugs.debian.org/917960
Bug#918641: pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava
Package: python3-fava Version: 1.9-3 Severity: serious As per subject, running fava fails with the following traceback: Traceback (most recent call last): File "/usr/bin/fava", line 6, in from pkg_resources import load_entry_point File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, in @_call_aside File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, in _call_aside f(*args, **kwargs) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, in _build_master ws.require(__requires__) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava this should ideally be fixed by having cheroot ship an egg-info dir, but it's being filed against fava for now to avoid testing migration. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) 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) LSM: AppArmor: enabled Versions of packages python3-fava depends on: ii python3 3.7.1-3 ii python3-babel2.6.0+dfsg.1-1 ii python3-beancount2.1.3+hg20181225-3 ii python3-click6.7+git20180829-1 ii python3-flask1.0.2-3 ii python3-flask-babel 0.11.2-2 ii python3-jinja2 2.10-1 ii python3-markdown22.3.7-1 ii python3-ply 3.11-3 ii python3-simplejson 3.15.0-1+b1 python3-fava recommends no packages. python3-fava suggests no packages. -- no debconf information
Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil
On Sun, Aug 21, 2022 at 12:29:21PM +0200, Gregory Mounie wrote: > Upgrading to emacs-gtk 28.1 fails with byte co[m]piling elpa-evil* [...] > In toplevel form: > evil.el:133:1: Error: Wrong number of arguments: (3 . 4), 2 > ERROR: install script from elpa-evil package failed Confirmed, I'm seeing this as well and it's breaking the overall installation of emacs-28 (if you've elpa-evil installed). As a workaround, the following works: remove the "elpa-evil" Debian package, install the same package via "M-x package-install" and then "evil". That will give you evil version 1.15.0, which is compatible with Emacs 28. (But also get you out of the comfort zone of Debian packages, you've been warned!) Hope this helps, Cheers
Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error
Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20210105.00d395b+dfsg-2
Severity: serious
In Debian testing offlineimap plain authentication over SSL started to fail for
me in the following way:
$ offlineimap -c ~/.config/offlineimap/offlineimaprc -u basic --info
OfflineIMAP 7.3.0
Licensed under the GNU GPL v2 or any later version (with an OpenSSL
exception)
imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec 2020
imaplib2: 3.05
Remote repository 'Censored: type 'IMAP'
Host: mail.example.org Port: None SSL: True
Establishing connection to mail.example.org:993 (Censored)
Traceback (most recent call last):
File "/usr/bin/offlineimap", line 22, in
oi.run()
File "/usr/share/offlineimap3/offlineimap/init.py", line 88, in run
self.__serverdiagnostics(options)
File "/usr/share/offlineimap3/offlineimap/init.py", line 518, in
__serverdiagnostics
account.serverdiagnostics()
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 197, in
serverdiagnostics
self.ui.serverdiagnostics(remote_repo, 'Remote')
File "/usr/share/offlineimap3/offlineimap/ui/UIBase.py", line 450, in
serverdiagnostics
conn = repository.imapserver.acquireconnection()
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in
acquireconnection
self.__authn_helper(imapobj)
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in
__authn_helper
if func(imapobj):
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in
__authn_plain
imapobj.authenticate('PLAIN', self.__plainhandler)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in
authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in
_simple_command
return self._command_complete(self._command(name, *args), kw)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
literal = literator(data, rqb)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
ret = self.mech(self.decode(data))
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in
__plainhandler
retval = NULL.join((authz, authc, passwd))
TypeError: sequence item 2: expected str instance, bytes found
The server in question has a valid letsencrypt certificate, which I can use and
authenticate fine with other clients.
Not sure if the problem is actually in offlineimap or in imaplib2, but no
relevant bugs seems to be reported against the latter either.
Thanks for maintaining offlineimap,
Cheers
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 offlineimap depends on:
ii offlineimap3 0.0~git20210105.00d395b+dfsg-2
offlineimap recommends no packages.
offlineimap suggests no packages.
-- no debconf information
Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error
Hi Sudip, thanks for your reply, On Fri, Feb 12, 2021 at 05:00:04PM +, Sudip Mukherjee wrote: > Thanks for the report. Can you please paste your offlineimaprc file > after removing any sensitive information, and I can try to reproduce > the error in my setup. in fact, it turns out this is a duplicate of #981063, which I failed to identify initially because it didn't have the actual final error in the message. The workaround in that bug report worked for me. I've tried to merge the bugs, but it failed with an error on locking a spool file on the BTS server. (I've just tried again.) FWIW, I think #981063 should be severity serious and fixed in time for bullseye. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#844201: debsources: updater broken by recent (Sources.gz removal, maybe sha1 removal) dak changes
Package: qa.debian.org Severity: serious User: qa.debian@packages.debian.org Usertags: debsources Context is: https://lists.debian.org/debian-devel-announce/2016/11/msg5.html Here are some relevant entries from debsources.log: Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639. Errors: Download of dists/squeeze-lts/Release failed Ignoring failed Release files Ignoring missing Release file for dists/sid/main/source/Sources.gz Ignoring missing Release file for dists/sid/contrib/source/Sources.gz Ignoring missing Release file for dists/sid/non-free/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/main/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/contrib/source/Sources.gz Ignoring missing Release file for dists/squeeze-lts/non-free/source/Sources.gz Ignoring missing Release file for dists/experimental/main/source/Sources.gz Ignoring missing Release file for dists/experimental/contrib/source/Sources.gz Ignoring missing Release file for dists/experimental/non-free/source/Sources.gz /srv/debsources/bin/debsources-main: I: debsources-update... Cheers. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#964334: segfault repeatedly
Package: chromium Version: 83.0.4103.116-2 Severity: grave I've upgraded chromium to the current version in testing, and it segfaults repeatedly (and very "reliably"! :-)) after usually ~1 minute of runtime, even when not used in foreground, with a stack trace like this one: - $ chromium (chromium:1480721): Gtk-WARNING **: 21:03:45.963: Theme parsing error: gtk.css:6:20: The 'gtk-key-bindings' property has been renamed to '-gtk-key-bindings' [1480760:1480760:0705/210346.245467:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [1480764:1480779:0705/210348.465499:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018 libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscale PNG libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space not permitted on grayscale PNG libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Received signal 11 SEGV_MAPERR 7f01744946c7 #0 0x557d36628c69 (/usr/lib/chromium/chromium+0x52b3c68) #1 0x557d36587ef3 (/usr/lib/chromium/chromium+0x5212ef2) #2 0x557d366287f1 (/usr/lib/chromium/chromium+0x52b37f0) #3 0x7f1a95d8d110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) #4 0x7f1a90e78d3c (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b) #5 0x7f1a90e7af33 (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32) #6 0x7f1a90e7cbf9 __libc_malloc #7 0x557d366409be operator new() #8 0x7f1a91103a2c std::__cxx11::basic_string<>::reserve() #9 0x7f1a910f9498 std::__cxx11::basic_stringbuf<>::overflow() #10 0x7f1a9110204a std::basic_streambuf<>::xsputn() #11 0x7f1a910f4714 std::__ostream_insert<>() #12 0x557d36628d39 (/usr/lib/chromium/chromium+0x52b3d38) #13 0x557d36629054 (/usr/lib/chromium/chromium+0x52b4053) #14 0x557d3659a412 (/usr/lib/chromium/chromium+0x5225411) #15 0x557d3659c548 (/usr/lib/chromium/chromium+0x5227547) #16 0x557d34ce212a (/usr/lib/chromium/chromium+0x396d129) #17 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d) #18 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386) #19 0x557d34c9b3d9 (/usr/lib/chromium/chromium+0x39263d8) #20 0x557d34c9b61e (/usr/lib/chromium/chromium+0x392661d) #21 0x557d34ce5967 (/usr/lib/chromium/chromium+0x3970966) #22 0x557d34d114c7 (/usr/lib/chromium/chromium+0x399c4c6) #23 0x557d34d1177e (/usr/lib/chromium/chromium+0x399c77d) #24 0x557d34ce213f (/usr/lib/chromium/chromium+0x396d13e) #25 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d) #26 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386) #27 0x557d345fa7a3 (/usr/lib/chromium/chromium+0x32857a2) #28 0x557d349690bc (/usr/lib/chromium/chromium+0x35f40bb) #29 0x557d3675a45f (/usr/lib/chromium/chromium+0x53e545e) #30 0x557d36760a24 (/usr/lib/chromium/chromium+0x53eba23) #31 0x557d3675eb62 (/usr/lib/chromium/chromium+0x53e9b61) #32 0x557d3675d82d (/usr/lib/chromium/chromium+0x53e882c) #33 0x557d36756213 (/usr/lib/chromium/chromium+0x53e1212) #34 0x557d36771abb (/usr/lib/chromium/chromium+0x53fcaba) #35 0x557d36771de0 (/usr/lib/chromium/chromium+0x53fcddf) #36 0x557d36771370 (/usr/lib/chromium/chromium+0x53fc36f) #37 0x557d345e3c46 (/usr/lib/chromium/chromium+0x326ec45) #38 0x557d345e376c (/usr/lib/chromium/chromium+0x326e76b) #39 0x557d345dfeed (/usr/lib/chromium/chromium+0x326aeec) #40 0x557d345d674b (/usr/lib/chromium/chromium+0x326174a) #41 0x557d345c9044 (/usr/lib/chromium/chromium+0x3254043) #42 0x557d345c8d75 (/usr/lib/chromium/chromium+0x3253d74) #43 0x557d345e7426 (/usr/lib/chromium/chromium+0x3272425) #44 0x557d366460e0 (/usr/lib/chromium/chromium+0x52d10df) #45 0x7f1a94b42b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e) #46 0x7f1a94b4324f event_base_loop #47 0x557d3664638e (/usr/lib/chromium/chromium+0x52d138d) #48 0x557d365e65d5 (/usr/lib/chromium/chromium+0x52715d4) #49 0x557d365be670 (/usr/lib/chromium/chromium+0x524966f) #50 0x557d349043b3 (/usr/lib/chromium/chromium+0x358f3b2) #51 0x557d365fc2a9 (/usr/lib/chromium/chromium+0x52872a8) #52 0x557d36638c9e (/usr/lib/chromium/chromium+0x52c3c9d) #53 0x7f1a95d81f27 start_thread #54 0x7f1a90ef031f clone r8: 0077 r9: 0050 r10: 0004 r11: 007c r12: 7f1a7420 r13: 7f1a7430 r14: 7f1a74736850 r15: 0020 di: 0021 si: 0004 bp: 0020 bx: 7f01744946bf dx: 7f1a7480 ax: 7f1a742d4d90 cx: 7f01744946bf sp: 7f1a826d3440 ip: 7f1a90e78d3c efl: 00010202 cgf: 002b0033 erf: 0004 trp: 000e msk: cr2: 7f01744946c7 [end of stack trace] Calling _exit(1). Core file will not be generated. - Thanks a lot for maintaining chromium in Debian, Hope this helps -- System Information: Debian
Bug#964334: segfault repeatedly
I've seen this bug has been marked as "more info" (with no comment), but I'm not clear on which additional info are needed and how I can provide them. Advice on how I can help is welcome :-)
Bug#969576: nextcloud-desktop: Main window not visible/constructable
On Wed, Sep 09, 2020 at 07:24:04PM +0200, Paul van Tilburg wrote: > I have to reaffirm that I used an iterative approach to install each of > these to get rid of all warnings and have the main interface appear. > I'm afraid that all dependencies listed above seem necessary, maybe > you had the others for other reasons already? Yeah, it is entirely possible. So please test what is actually needed (e.g., in a fresh debian chroot) rather than relying on my very narrow data point. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#839190: wordpress 4.1+dfsg-1+deb8u10 regression
On Fri, Sep 30, 2016 at 10:20:30AM +0200, Yves-Alexis Perez wrote: > thanks for the report, we're aware of the regression. Can you try the attached > patch against functions.php and report back, as soon as possible? I've tried the patch, and it fixed the regression for me. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader . OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
tags 1080096 patch
thanks
On Tue, Sep 03, 2024 at 06:35:06PM +0200, fr.hame...@gmail.com wrote:
> To solve it have applied the patches given by nvidia the 21 of July
> here :
> https://forums.developer.nvidia.com/t/gpl-only-symbols-follow-pte-and-rcu-read-unlock-prevent-470-256-02-to-build-with-kernel-6-10/300052/4
I can confirm it worked for me too, thanks a lot for the pointer!
For convenience, I'm attaching the patch I used to this message (its 2
messages down from the above, but it's not directly downloadable).
It does not apply cleanly to nvidia-kernel-dkms 535.183.01-1~deb12u1 ,
but it's trivial to fix manually.
Cheers
diff -ruNb a/kernel/conftest.sh b/kernel/conftest.sh
--- a/conftest.sh2024-07-19 04:36:26.183701185 -0500
+++ b/conftest.sh2024-07-19 04:36:26.230366381 -0500
@@ -4464,20 +4464,22 @@
compile_check_conftest "$CODE" "NV_DRM_GEM_OBJECT_VMAP_HAS_MAP_ARG" "" "types"
;;
-unsafe_follow_pfn)
+follow_pfn)
#
-# Determine if unsafe_follow_pfn() is present.
+# Determine if follow_pfn() is present.
#
-# unsafe_follow_pfn() was added by commit 69bacee7f9ad
-# ("mm: Add unsafe_follow_pfn") in v5.13-rc1.
+# follow_pfn() was added by commit 3b6748e2dd69
+# ("mm: introduce follow_pfn()") in v2.6.31-rc1, and removed
+# by commit 233eb0bf3b94 ("mm: remove follow_pfn")
+# from linux-next 233eb0bf3b94.
#
CODE="
#include
-void conftest_unsafe_follow_pfn(void) {
-unsafe_follow_pfn();
+void conftest_follow_pfn(void) {
+follow_pfn();
}"
-compile_check_conftest "$CODE" "NV_UNSAFE_FOLLOW_PFN_PRESENT" "" "functions"
+compile_check_conftest "$CODE" "NV_FOLLOW_PFN_PRESENT" "" "functions"
;;
drm_plane_atomic_check_has_atomic_state_arg)
diff -ruNb a/kernel/nvidia/nvidia.Kbuild b/kernel/nvidia/nvidia.Kbuild
--- a/nvidia/nvidia.Kbuild 2022-10-12 04:29:57.0 -0500
+++ b/nvidia/nvidia.Kbuild 2024-07-19 05:17:39.148448922 -0500
@@ -164,7 +164,7 @@ NV_CONFTEST_FUNCTION_COMPILE_TESTS += cc
NV_CONFTEST_FUNCTION_COMPILE_TESTS += iterate_fd
NV_CONFTEST_FUNCTION_COMPILE_TESTS += seq_read_iter
NV_CONFTEST_FUNCTION_COMPILE_TESTS += sg_page_iter_page
-NV_CONFTEST_FUNCTION_COMPILE_TESTS += unsafe_follow_pfn
+NV_CONFTEST_FUNCTION_COMPILE_TESTS += follow_pfn
NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_get
NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_put_unlocked
NV_CONFTEST_FUNCTION_COMPILE_TESTS += set_close_on_exec
diff -ruNb a/kernel/nvidia/os-mlock.c b/kernel/nvidia/os-mlock.c
--- a/nvidia/os-mlock.c 2022-10-12 04:30:26.0 -0500
+++ b/nvidia/os-mlock.c 2024-07-19 04:36:26.230366381 -0500
@@ -18,10 +18,10 @@
unsigned long address,
unsigned long *pfn)
{
-#if defined(NV_UNSAFE_FOLLOW_PFN_PRESENT)
-return unsafe_follow_pfn(vma, address, pfn);
-#else
+#if defined(NV_FOLLOW_PFN_PRESENT)
return follow_pfn(vma, address, pfn);
+#else
+return -1;
#endif
}
Bug#1080096: fail to build with kernel 6.10.6+bpo-amd64 - implicit declaration of function ‘follow_pfn’
On Fri, Sep 06, 2024 at 05:21:36PM +0200, Andreas Beckmann wrote: > src:nvidia-graphics-drivers for bookworm-backports is in BACKPORTS-NEW. Awesome, thank you. > Just curious: Why didn't you simply rebuild the package from sid for > bookworm instead of digging for patches on the internet? I only have Debian stable APT entries on my laptop and nobody mentioned here in the bug report that it was fixed in sid, so I had no idea. FWIW, I did not dig for patches on the internet myself, I just gave a try to the workaround someone else proposed on this bug report (thank you!), as it seemed promising. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . https://upsilon.cc/zack _. ^ ._ Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o <\> Co-founder & CTO Software Heritageo o o o /\|^|/\ https://twitter.com/zacchiro . https://mastodon.xyz/@zacchiro '" V "' signature.asc Description: PGP signature
Bug#346892: patch for xlibs-dev splitting
tags 346892 + patch thanks Attached you can find a patch fixing this bug. I'm going to NMU it. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -ur orig/astrolog-5.40/debian/changelog astrolog-5.40/debian/changelog --- orig/astrolog-5.40/debian/changelog 2006-01-22 12:44:21.0 +0100 +++ astrolog-5.40/debian/changelog 2006-01-22 12:44:03.0 +0100 @@ -1,3 +1,13 @@ +astrolog (5.40-2.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- xlibs-dev splitting transition, removed build-dep on xlibs-dev in + favour of libx11-dev + (closes: #346892) + + -- Stefano Zacchiroli <[EMAIL PROTECTED]> Sun, 22 Jan 2006 12:37:38 +0100 + astrolog (5.40-2) unstable; urgency=low * Updated astrolog.cgi to reflect changes in perl and imagemagick (Closes: #92300, #92304) diff -ur orig/astrolog-5.40/debian/control astrolog-5.40/debian/control --- orig/astrolog-5.40/debian/control 2006-01-22 12:44:21.0 +0100 +++ astrolog-5.40/debian/control2006-01-22 12:43:37.0 +0100 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Tom Lear <[EMAIL PROTECTED]> Standards-Version: 3.5.6 -Build-depends: debhelper, xlibs-dev +Build-Depends: debhelper, libx11-dev Package: astrolog Architecture: any signature.asc Description: Digital signature
Bug#346874: patch for xlibs-dev splitting
tags 346874 + patch thanks Attached you can find a patch fixing this bug. I'm going to NMU it. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -ur orig/ida-2.01/debian/changelog ida-2.01/debian/changelog --- orig/ida-2.01/debian/changelog 2006-01-22 16:19:50.0 +0100 +++ ida-2.01/debian/changelog 2006-01-22 16:27:34.0 +0100 @@ -1,3 +1,17 @@ +ida (2.01-1.3) unstable; urgency=low + + * Non-maintainer upload. + * debian/control +- xlibs-dev splitting transition, removed build-dep on xlibs-dev in + favour of: libx11-dev, libxp-dev, libxext-dev, libxpm-dev, + libxt-dev, x-dev + (closes: #346874) +- bumped build-dep on libmotif-dev to (>= 2.2.3-1.3), it is the + first version of the package not depending on xlibs-dev and thus + installable + + -- Stefano Zacchiroli <[EMAIL PROTECTED]> Sun, 22 Jan 2006 12:16:51 +0100 + ida (2.01-1.2) unstable; urgency=low * Non-maintainer upload. diff -ur orig/ida-2.01/debian/control ida-2.01/debian/control --- orig/ida-2.01/debian/control2006-01-22 16:19:50.0 +0100 +++ ida-2.01/debian/control 2006-01-22 16:27:16.0 +0100 @@ -1,7 +1,7 @@ Source: ida Section: contrib/graphics Priority: extra -Build-Depends: debhelper (>= 4.0), perl, libmotif-dev (>= 2.2.2), libjpeg-dev, libtiff4-dev | libtiff-dev, libpng3-dev | libpng-dev, libungif4-dev, xbase-clients, xlibs-dev, xutils, bsdmainutils, libpcd-dev, libcurl3-dev | libcurl-dev, libexif-dev, libfontconfig1-dev, libfreetype6-dev +Build-Depends: debhelper (>= 4.0), perl, libmotif-dev (>= 2.2.3-1.3), libjpeg-dev, libtiff4-dev | libtiff-dev, libpng3-dev | libpng-dev, libungif4-dev, xbase-clients, libx11-dev, libxp-dev, libxext-dev, libxpm-dev, libxt-dev, x-dev, xutils, bsdmainutils, libpcd-dev, libcurl3-dev | libcurl-dev, libexif-dev, libfontconfig1-dev, libfreetype6-dev Maintainer: Gerd Knorr <[EMAIL PROTECTED]> Standards-Version: 3.6.1 signature.asc Description: Digital signature
Bug#340458: lablgtkmathview - FTBFS: ocamlfind: Package `gdome2' not found
On Wed, Nov 23, 2005 at 04:16:58PM +0100, Bastian Blank wrote: > > Automatic build of lablgtkmathview_0.7.2-3 on debian01 by sbuild/s390 79 > [...] > > ** Using build dependencies supplied by package: > > Build-Depends: debhelper (>> 4.0.0), ocaml-nox (>= 3.09.0), ocaml-findlib > > (>= 1.1), liblablgtk2-ocaml-dev (>= 2.6.0), libgdome2-ocaml-dev (>= > > 0.2.3-3), libgtkmathview-dev (>= 0.7.5), pkg-config > [...] > > checking for ocamlc... yes > > checking for ocamlfind... yes > > checking "for gdome2"... ocamlfind: Package `gdome2' not found The problem is in version 0.2.3-3 of libgdome2-ocaml-dev which ships a fubar content in /usr/lib/ocaml/3.09.0/gdome2/ (almost nothing). Version 0.2.3-4 (already rebuilt for s390) is ok. If it is ok for you I propose to just rebuild lablgtkmathview against that version on s390 and avoid reuploading lablgtkmathview with a more tight build depends on libgdome2-ocaml-dev. After all 0.2.3-3 will disappear due to the c++ allocator change. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#340879: extlib: FTBFS: new, more restrictive coreutils mv
On Sat, Nov 26, 2005 at 06:00:01PM +0100, Roland Stigge wrote: > building the package extlib in a clean sid build environment > (with pbuilder) on i386 results in: Thanks for the patch. Upload which fixes this problem is coming soon. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#341002: uninstallable in unstable: please port to ocaml 3.09.0
Package: libgetopt-ocaml-dev Severity: grave As per subject: libgetopt-ocaml-dev is currently not installable on debian/unstable due to the transition to ocaml 3.09. Please port it. TIA, Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341290: uninstallable in unstable: please port to ocaml 3.09
Package: libdbi-ocaml-dev Severity: grave ocamldbi is currently uninstallable in unstable, porting the package to ocaml 3.09 is needed. Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338483: keeping vim outside of testing
This bug is keeping vim 6.4 out of testing. Could you please do one of the following: 1) port the package so that it works with vim 6.4 (if possible) 2) ask for help on the pkg-vim-maintainers mailing list, we can consider maintainaing vimacs collaboratively if you're interested (and if the package still work with vim 6.4, of course) 3) ask for its removal from the unstable archive Many thanks, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: enabling external editor render plone-instance unusable
Package: zope-externaleditor
Version: 0.9.1-2
Severity: grave
I just made a fresh installazion of the plone-site package.
Then I installe zope-externaleditor and enabled external editing in the
site-wide preferences. So far so good.
As the admin user I then enabled external editor in the user preferences and
accessing the plone home (URL: http://localhost:8081/plone) now gives the
attached tracebac.
This behaviour is reproducible trying again from scratch.
Cheers.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Versions of packages zope-externaleditor depends on:
ii python2.3.5-5An interactive high-level object-o
ii zope-common 0.5.19 common settings and scripts for zo
ii zope2.8 2.8.5-1Open Source Web Application Server
zope-externaleditor recommends no packages.
-- no debconf information
An error was encountered while publishing this resource.
AttributeError
Sorry, a site error occurred.
Traceback (innermost last):
* Module ZPublisher.Publish, line 187, in publish_module_standard
* Module Products.PlacelessTranslationService.PatchStringIO, line 51, in
new_publish
* Module ZPublisher.Publish, line 144, in publish
* Module Zope2.App.startup, line 216, in zpublisher_exception_hook
* Module ZPublisher.Publish, line 113, in publish
* Module ZPublisher.mapply, line 88, in mapply
* Module ZPublisher.Publish, line 40, in call_object
* Module Shared.DC.Scripts.Bindings, line 311, in __call__
* Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
* Module Products.CMFCore.FSPageTemplate, line 195, in _exec
* Module Products.CMFCore.FSPageTemplate, line 134, in pt_render
* Module Products.PageTemplates.PageTemplate, line 104, in pt_render
* Module TAL.TALInterpreter, line 206, in __call__
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 711, in do_useMacro
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 426, in do_optTag_tal
* Module TAL.TALInterpreter, line 411, in do_optTag
* Module TAL.TALInterpreter, line 406, in no_tag
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 711, in do_useMacro
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 481, in do_setGlobal_tal
* Module Products.PageTemplates.TALES, line 221, in evaluate
URL: file:CMFPlone/skins/plone_templates/global_defines.pt
Line 3, Column 0
Expression:
Names:
{'container': ,
'context': ,
'default': ,
'here': ,
'loop': ,
'modules': ,
'nothing': None,
'options': {'args': ()},
'repeat': ,
'request': http://localhost:8081/plone/front-page/document_view>,
'root': ,
'template': ,
'traverse_subpath': [],
'user': admin}
* Module Products.PageTemplates.ZRPythonExpr, line 47, in __call__
__traceback_info__: portal.portal_actions.listFilteredActionsFor(here)
* Module Python expression
"portal.portal_actions.listFilteredActionsFor(here)", line 1, in
* Module Products.CMFPlone.ActionsTool, line 45, in listFilteredActionsFor
* Module Products.CMFPlone.ActionsTool, line 33, in _getActions
* Module Products.CMFCore.ActionProviderBase, line 107, in listActionInfos
* Module Products.CMFCore.ActionInformation, line 87, in __getitem__
* Module Products.CMFCore.ActionInformation, line 116, in _checkCondition
* Module Products.CMFCore.ActionInformation, line 236, in testCondition
* Module Products.CMFCore.Expression, line 44, in __call__
* Module Products.PageTemplates.Expressions, line 185, in __call__
* Module Products.PageTemplates.Expressions, line 180, in _eval
* Module Products.PageTemplates.Expressions, line 77, in render
* Module Products.PageTemplates.ZRPythonExpr, line 76, in call_with_ns
* Module Products.CMFCore.FSPythonScript, line 103, in
__render_with_namespace__
* Module Shared.DC.Scripts.Bindings, line 325, in __render_with_namespace__
* Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
* Module Products.CMFCore.FSPythonScript, line 163, in _exec
* Module None, line 25, in externalEditorEnabled
Line 25
AttributeError: externalEditLink_ (Also, the following error occurred while
attempting to render the standard error message, please see the event log for
full details: externalEditLink_)
Troubleshooting Suggestions
* The URL may be incorrect.
* The parameters passed to this resource may be incorrect.
* A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 09:51:08PM +0100, Fabio Tranchitella wrote: > Ciao Stefano, which version of plone are you using? $ dpkg -l plone* | grep ^ii ii plone 2.1.2-1content management system based on zope and cmf ii plone-site 2.1.2-1preconfigured zope instance containing a plone -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 10:12:22PM +0100, Fabio Tranchitella wrote: > Did you add the ExternalEditor package to the plone-site instance? > Something like: > > # dzhandle -z 2.8 add-product plone-site ExternalEditor You're right, that was indeed the problem. I'm sorry, I'm quite a zope newbie. Still, may I suggests to document the required steps in README.Debian? Just mention to do dzhandle add-product / restart-pending-instances. The actual content of the README.Debian is quite useless while the proposed one could avoid future bug reports from newbies like me. (For this reason I'm not yet closing the report with this mail) Many thanks for your help, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#352582: [Pkg-zope-developers] Bug#352582: enabling external editor render plone-instance unusable
On Sun, Feb 12, 2006 at 11:09:21PM +0100, Fabio Tranchitella wrote: > I'm not using my usual workstation and I can't check, but I suppose that > README.Debian from zope-common package already explains the way Zope > packages works in Debian. I looked at it and it's fine, but what I was suggesting is to document in the README.Debian of zope-externaleditor the steps needed to install it. It should be fine even to refer users to the README.Debian of zope-common. Anyhow, just a suggestion, feel free to close this bug report (which IMHO, is not relevant to zope-common). Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#356101: FTBFS: probably due to new make
Hi Martin, On Thu, Mar 09, 2006 at 06:09:57PM +, Martin Michlmayr wrote: > Your package fails to build from source in unstable, probably because > of the new make. gtkmathview relies only on cdbs and on its dpatch support: probably the problem resides in one of the two. I will look into it. Thanks for the report, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#356101: FTBFS: probably due to new make
On Thu, Mar 09, 2006 at 06:59:10PM +, Martin Michlmayr wrote: > Oh, it's possible that it's a cdbs problem. Unfortunately, cdbs isn't > really maintained much anymore. What? Are you kidding? A lot of packages depend on it, is it really not maintained? This will be a real problem for many of us ... > I don't know cdbs at all. Do you think you can investigate? Well, I know it only as an user, not as a cdbs developer. I will try to do my best ..., but I wont have time to work on it until the next week for sure. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356101: RC bug patches
On Fri, Mar 10, 2006 at 04:11:02AM -0800, Matt Kraai wrote: > It appears to be a bug in gtkmathview. cdbs provides the following > single-colon rule: > > unpatch: deapply-dpatches > gtkmathview contains the following double-colon rule in its > debian/rules: > > unpatch:: deapply-dpatches That line was a temporary patch (read: huge hack) related to #284231. Now that the bug is fixed in cdbs (thanks Peter!) that line can be removed. Thanks for the patch, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#378721: vim-lesstif: gvim always crashes during startup
On Wed, Jul 19, 2006 at 02:48:25PM +0400, Andrey Kiselev wrote: > > Lesstif variant of gvim does not work on my system and crashes during > > startup. There is backtrace log from the gdb: > In addition I have built vim package using libmotif from unstable > (2.2.3-1.4) and it works just fine. So it is most likely a problem with > lesstif, but it renders vim-lesstif completely unusable. Could you please compare the versions of lesstif against which yours (fixed) binary works and ours (broken) binary does not? It would be a lot helpful ... Many thanks in advance, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338098: libextlib-ocaml-dev: is not installable in unstable
On Tue, Nov 08, 2005 at 12:10:17PM +0800, Paul Wise wrote: > ocaml has been updated to a new upstream version. as a result, > libextlib-ocaml-dev needs to be updated. I see a lot of your other > packages are in the same situation. In order to ease migration into testing of the whole bunch of ocaml packages during transitions between upstream releases, packages are uploaded in a staged manner. First those who directly build depends on ocaml only, then those which depends to it at distance 2 and so on. Extlib is at distance 2, before it can be uploaded we need to rebuild those at distance one among which there is, for example, findlib on which I'm working on. Feel free to submit a patch for extlib (implementing the change we discussed on debian-ocaml-maint to ease future transitions) or switch to testing. Thanks for the report. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338932: postgresql-ocaml - FTBFS: Fatal error: the file install is not a bytecode executable file
On Sun, Nov 13, 2005 at 11:25:18PM +0100, Bastian Blank wrote: > > Automatic build of postgresql-ocaml_1.4.6-3 on debian-31 by sbuild/s390 69 > [...] > > Installing library with ocamlfind > > ocamlfind install -ldconf /dev/null -destdir > > /build/buildd/postgresql-ocaml-1.4.6/debian/libpostgresql-ocaml-dev/usr/lib/ocaml/3.09.0 > > postgresql META libpostgresql_stubs.a postgresql.cma postgresql.cmi > > postgresql.mli dllpostgresql_stubs.so > > Fatal error: the file install is not a bytecode executable file Looking at the build log I can't figure out what's going on. Could you please install postgresql-ocaml build dependencies on the sid chroot of a debian development s390 machine? Since I suspect a problem with ocaml-findlib, installing also its build dependencies may save future work ... Thanks for the report, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338935: Processed: Re: Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a bytecode executable file
On Mon, Nov 14, 2005 at 07:03:42AM -0800, Debian Bug Tracking System wrote: > Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a > bytecode executable file I'm aware of the problem, I'm waiting for an s390 admin to install findlib build dependencies to examine the problem ... -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338935: ocaml-ssl - FTBFS: Fatal error: the file install is not a bytecode executable file
On Mon, Nov 14, 2005 at 04:23:56PM +0100, Julien Cristau wrote: > this problem was introduced when findlib switched to using cdbs, and the > "if [ -x /usr/bin/ocamlopt ]; then dh_strip; else true; fi" line was > removed. I think the following patch should fix this issue: Gotcha!, many thanks for your hint. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#338932: postgresql-ocaml - FTBFS: Fatal error: the file install is not a bytecode executable file
reassign 338932 ocaml-findlib thanks The bug is related to ocaml-findlib and will be fixed with its forthcoming upload. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#339167: library package needs to be renamed (libstdc++ allocator change)
tags 339167 + confirmed pending thanks [ This bug has been reported against "gdome2-xslt" ] gdome2-xslt includes the ocaml bindings for the C library shipped. For this reason it must soon be transitioned from ocaml 3.08.3 to ocaml 3.09.0. I will rename the C++ part of the package contextually to the ocaml transition. Please avoid NMU for the C++ part in the meantime. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#339517: findlib: FTBFS on m68k (ocaml segfault)
On Wed, Nov 16, 2005 at 09:38:10PM +0100, Julien Cristau wrote: > Package: findlib > Severity: serious > Justification: no longer builds from source > > Hi, > > findlib currently fails to build on m68k with the following error: > make[2]: Entering directory `/build/buildd/findlib-1.1/src/findlib-toolbox' > ocamlc -o make_wizard -I +labltk -I ../findlib unix.cma str.cma labltk.cma \ > findlib.cma make_wizard.ml > File "make_wizard.ml", line 1288, characters 6-12: > Warning Y: unused variable update. > make[2]: *** [make_wizard] Segmentation fault > make[2]: *** Deleting file `make_wizard' > make[2]: Leaving directory `/build/buildd/findlib-1.1/src/findlib-toolbox' > > The same error already happened with 1.0.4-4, and is probably tk or > ocaml-related. Please reassign as appropriate. > (it would probably be helpful to get a backtrace from the segfault) I asked for the installation of findlib build-dep on the m68k developer machine. As soon as I have it I will produce a backtrace hoping to understand better what's going on. In the meantime if sometime has memory of similar bugs on m68k it would be wonderful (I think I remember something similar related to tk indeed, but I'm not sure ...) Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344150: vim: FTBFS on hppa
tags 344150 + pending
thanks
On Tue, Dec 20, 2005 at 01:29:26PM +0100, Matthijs Mohlmann wrote:
> Package: vim
> Version: 1:6.4-001+2
> Severity: serious
>
> Hi,
>
> vim fails to build from source on an hppa:
Mea culpa, but already fixed in the SVN version of vim. The current
related debian/changelog line is:
vim (1:6.4-004+2) UNRELEASED; urgency=low
[ Stefano Zacchiroli ]
* debian/rules: finally found the karma of target-specific variables,
hopefully the file is clearer now ...
I will detail it more, explaining that it fixes the FTBFS on hppa.
> I couldn't find out why it stops right there. I'll take look on it
> later. It stops on dh_testdir which don't know some option... but it
> builds fine on the other architectures, I'm not yet sure what causes
> this.
I think it's related to some difference in debhelper and/or make, but
there was indeed some messed up interaction among debian/rules variable
and environment variable due to a misuse of 'export' in debian/rules.
Now it should be fixed (i.e. it used to be broken on my laptop as well,
with the same error as hppa, but now is fixed).
Have a look at the SVN diff on debian/rules for moreinfo.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
signature.asc
Description: Digital signature
Bug#344368: conflicts with vim-common
On Wed, Dec 21, 2005 at 09:13:01PM -0800, Joshua Kwan wrote: > Package: vim-runtime > Version: 1:6.4-004+1 > Severity: grave > > Unpacking replacement vim-runtime ... > dpkg: error processing > /var/cache/apt/archives/vim-runtime_1%3a6.4-004+2_all.deb (--unpack): > trying to overwrite `/usr/bin/vimtutor', which is also in package vim-common > dpkg-deb: subprocess paste killed by signal (Broken pipe) > > vim-runtime should Replace vim-common. It does: Package: vim-runtime Replaces: vim-common (<< 6.4-004+2), ... are you sure you're upgrading against the latest versions? Which frontend are you using to upgrade (apt/dselect/aptitude/...)? I don't understend how you can have the reported behaviour ... Thanks for the report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344368: non-epoched versioned dependencies in debian/control
retitle 344368 non-epoched versioned dependencies in debian/control thanks On Thu, Dec 22, 2005 at 08:43:15AM +0100, Stefano Zacchiroli wrote: > > dpkg: error processing > > /var/cache/apt/archives/vim-runtime_1%3a6.4-004+2_all.deb (--unpack): > It does: > Package: vim-runtime > Replaces: vim-common (<< 6.4-004+2), ... I'm noticing only now a big bug in vim's debian/control. All Replaces/Recommends/... versioned dependencies are against the non-epoched versions (i.e. in the example above it should be "1:6.4-004+2", instead of "6.4-004+2")!!! This is the cause of the missed Replaces. We should fix it and upload soon. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344658: vim - FTBFS: cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory
On Sat, Dec 24, 2005 at 02:04:16PM +0100, Bastian Blank wrote: > Package: vim > Version: 1:6.4-006+1 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of vim_1:6.4-006+1 on debian-31 by sbuild/s390 79 > [...] > > dh_install -X.svn > > cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory > > dh_install: command returned error code 256 > > make: *** [install-stamp-vim-tiny] Error 1 Which version of make is installed in the autobuilder environment? If it is the same that is installed in the sid chroot on raptor.debian.org (3.80), then the responsible is probably make. In particular, vim's debian/rules uses 'export' target specific variables, for example: install-stamp-%: export DH_OPTIONS=-p$* Apparently they were not supported in earlier version of make. (And no, I was not aware of this non-backward compatibility, otherwise I would have set an appropriate build-depends). You can check if they are supported or not looking at 'info make' and searching for 'Target-specific Variable'. If they are supported you should see in the first screen something like: or like this: TARGET ... : export VARIABLE-ASSIGNMENT If they're not supported, could you please try to upgrade the version of make to the latest in unstable and try again the build? Alternatively, it would be enough to install it on raptor's sid chroot. I will try it. (I believe you're that chroot's maintainer ...) Thanks for the report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#344658: vim - FTBFS: cp: cannot stat `./debian/tmp/usr/bin/rview': No such file or directory
On Mon, Dec 26, 2005 at 11:01:05AM +0100, Stefano Zacchiroli wrote: > raptor.debian.org (3.80), then the responsible is probably make. In > particular, vim's debian/rules uses 'export' target specific variables, > for example: I changed debian/rules so that this feature is no longer used. The patched version of vim I have builds properly on a sarge chroot and in the sid chroot available on raptor.debian.org. Does this imply that it will build properly even on the s390 auto-builder? If you want to test it, the patched source package is available on raptor.debian.org in /home/zack. Or, alternatively, on the web at http://people.debian.org/~zack/stalla/ Please let me know if you can test it in advance or if you like us to upload this version and wait the auto-builder do its work. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#319433: FTBFS: Unable to find libmlgdome2-xslt
tags 319433 + wontfix thanks On Thu, Jul 21, 2005 at 09:55:53AM -0700, Matt Kraai wrote: > Package: editex > Version: 0.0.5-6 > Severity: serious > > editex fails to build because it cannot find libmlgdome2-xslt: editex is going to be removed from the debian archive, I requested its removal two weeks ago (see #317298), thus I wont fix this bug ever. Cheers. -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sat, Jul 30, 2005 at 07:57:36PM +0200, Kurt Roeckx wrote: > Your package is failing to build with the following error: On which architecture the package FTBFS? On buildd.debian.org all attempted built have been completed successfully ... Before forwarding the patch upstream I would like to have more info to give him. Thanks for the report and for the patch. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:25:14PM +0200, Kurt Roeckx wrote: > > On which architecture the package FTBFS? > > On buildd.debian.org all attempted built have been completed > > successfully ... > The log was from amd64, but it failed on hppa too. Yes, I discovered it this morning, since yesterday evening the build log wasn't available yet. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:25:14PM +0200, Kurt Roeckx wrote: > The log was from amd64, but it failed on hppa too. Could you please try the attached patch to see if it fixes the problem? TIA, Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- diff -u -r pcre-ocaml-5.10.0.bak/OCamlMakefile pcre-ocaml-5.10.0/OCamlMakefile --- pcre-ocaml-5.10.0.bak/OCamlMakefile 2005-07-31 12:30:25.0 +0200 +++ pcre-ocaml-5.10.0/OCamlMakefile 2005-07-31 12:30:59.0 +0200 @@ -886,6 +886,7 @@ else $(DLLSONAME): $(OBJ_LINK) $(OCAMLMKLIB) $(INCFLAGS) $(CLIBFLAGS) \ + -ccopt $(PIC_CFLAGS) \ -o $(CLIB_BASE) $(OBJ_LINK) $(CLIBS:%=-l%) \ $(OCAMLMKLIB_FLAGS) endif
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:48:41PM +0200, Kurt Roeckx wrote: > No it doesn't. You're now using -fPIC at link time while you > should do it at compile time. Thanks, I will then wait for some feedback from OCamlMakefile upstream author since -fPIC should be handled properly by it without adding -fPIC to CPPFLAGS has you suggested. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320624: pcre-ocaml: FTBFS: Not using -fPIC to make a shared library.
On Sun, Jul 31, 2005 at 12:29:11PM +0200, Stefano Zacchiroli wrote: > AFAICT the bug is in OCamlMakefile which fails to pass PIC_CFLAGS when > inovking ocamlmklib. I thus suppose that adding "-ccopt -fPIC" in the > "$(DLLSONAME)" rule would be enough. Still, since I don't know > OCamlMakefile in detail I ask your advice on this. Dear Markus, since I will be away in the next days and I don't want the pcre-ocaml debian package to be unbuildable for long I applied a quick and dirty patch to OCamlMakefile, which simply passes -fPIC to the building of all .o thru ocamlc. There should be a better way ... Kurt, could you please try it on your amd64 box? Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- #! /bin/sh /usr/share/dpatch/dpatch-run ## 31_fpic.dpatch by Stefano Zacchiroli <[EMAIL PROTECTED]> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad --exclude=CVS --exclude=.svn ./OCamlMakefile /tmp/dpep-work.483SSF/trunk/OCamlMakefile --- ./OCamlMakefile 2005-06-09 01:42:12.0 +0200 +++ /tmp/dpep-work.483SSF/trunk/OCamlMakefile 2005-07-31 22:00:28.0 +0200 @@ -1011,6 +1011,7 @@ .c.$(EXT_OBJ): $(OCAMLC) -c -cc "$(CC)" -ccopt "$(CFLAGS) \ + -fPIC \ $(CPPFLAGS) $(CPPFLAGS_WIN32) \ $(CFLAGS_WIN32) $(CINCFLAGS) $(CFLAG_O)$@ " $< signature.asc Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Tue, Aug 09, 2005 at 08:26:45PM +0200, Christian T. Steigies wrote: > I am trying to clean up my unstable chroot, for some reason a few ocaml > packages were still installed. This bug report shows two different problems: 1) ocaml-md5sums may be not available when postrm scripts are invoked 2) /var/lib/ocaml/md5sums is not a directory I fixed (1) and upload is pending. I can't understand (2). /var/lib/ocaml/md5sums/ is a directory and several ocaml related packages install stuff under that directory. I can understand if the directory is no longer there when some postrm scripts are executed (and I fixed the faulty behaviour of ocaml-md5sums in that case), but I can't understand how it comes /var/lib/ocaml/md5sums is something else than a directory. Have you toch-ed it trying to fix the postrm problem (like you did a few lines below in your report)? Thanks for the bug report. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Fri, Aug 12, 2005 at 11:09:10AM +0200, Sven Luther wrote: > > 1) ocaml-md5sums may be not available when postrm scripts are invoked > Sure, you should use it in prerm, since postrm removes it, no ? No, I can't, since when prerm is invoked .md5sums entries are still in /var/lib/ocaml/md5sums/. Still this is not a problem, invoking it on postrm only if ocaml-md5sums is available is fine since as long as it is not available .md5sums entries are useless. As soon as it will get re-installed the registry will be updated again. > It is probably not there, but why if it was not there, and some random > packages does a : > > cp stuff /var/lib/ocaml/md5sums It was there since the error reported was "not a directory" rather than "no such file or directory:". But as Christian reported he probably created that file by hand. All should be fixed now, I'm rebuilding the package right now. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332283: ocamlnet_1.1-4 (unstable): fails to build
tags 332283 + moreinfo thanks On Wed, Oct 05, 2005 at 06:55:57PM +0200, Bastian Blank wrote: > Package: ocamlnet > Version: 1.1-4 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of ocamlnet_1.1-4 on debian-31 by sbuild/s390 69 > [...] > > Build-Depends: debhelper (>> 4.0.0), ocaml-nox-3.08.3, libpcre-ocaml-dev > > (>= 5.10), libequeue-ocaml-dev, ocaml-findlib, dpatch > [...] > > Checking correctness of source dependencies... > > Toolchain package versions: libc6-dev_2.3.5-6 > > linux-kernel-headers_2.6.13+0rc3-1.1 gcc-4.0_4.0.2-1 g++-4.0_4.0.2-1 > > binutils_2.16.1cvs20050902-1 libstdc++6-4.0-dev_4.0.2-1 libstdc++6_4.0.2-1 > [...] > > make[1]: Entering directory `/build/buildd/ocamlnet-1.1/src' > > for pkg in netstring cgi pop smtp nethttpd; do /usr/bin/make -C $pkg > > install || exit; done > > make[2]: Entering directory `/build/buildd/ocamlnet-1.1/src/netstring' > > test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ > > -o netmappings_iso.pmap -pmap mappings/iso*.unimap > > test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ > > -o netmappings_jp.pmap -pmap mappings/jis*.*map > > test ! -d mappings || tools/unimap_to_ocaml/unimap_to_ocaml \ > > -o netmappings_other.pmap -pmap mappings/cp*.unimap > > mappings/adobe*.unimap mappings/koi*.unimap mappings/mac*.unimap > > mappings/windows*.unimap > > ocamlfind ocamldep -package camlp4 -syntax camlp4o *.ml *.mli >depend > > Error while loading "pa_o.cmo": file not found in path. > > Preprocessing error > > make[2]: *** [depend] Error 2 > > make[2]: Leaving directory `/build/buildd/ocamlnet-1.1/src/netstring' > > make[1]: *** [install] Error 2 > > make[1]: Leaving directory `/build/buildd/ocamlnet-1.1/src' > > make: *** [install] Error 2 pa_o.cmo is part of the "ocaml-nox" binary package, and on my (i386) box is properly installed: $ locate pa_o.cmo /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo $ dpkg -S /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo ocaml-nox: /usr/lib/ocaml/3.08.3/camlp4/pa_o.cmo Is it the same on the s390 box who tried the build? Anyhow the bug seems to be on the ocaml-nox package and not in ocamlnet which indeed builds properly on a fresh sid (i386) pbuilder environment. Many thanks for your report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#332283: ocamlnet_1.1-4 (unstable): fails to build
On Sat, Oct 08, 2005 at 09:59:03PM +0200, Bastian Blank wrote:
> > Anyhow the bug seems to be on the ocaml-nox package and not in ocamlnet
> > which indeed builds properly on a fresh sid (i386) pbuilder environment.
> s390 don't support native compiled code, maybe this is a problem.
This is likely to be the reason, since looking at the build logs the
build failed on all architectures which do not support native code
compilation.
> I did a strace and got the following:
> | execve("/usr/bin/camlp4", ["camlp4", "-nolib", "-I",
> "/home/waldi/debian/tmp/ocamlnet/ocamlnet-1.1/camlp4", "pa_o.cmo",
> "pa_op.cmo", "pr_dump.cmo", "cgi.ml"], [/* 33 vars */]) = 0
> | stat64("/home/waldi/debian/tmp/ocamlnet/ocamlnet-1.1/camlp4/pa_o.cmo",
> 0x7fb29570) = -1 ENOENT (No such file or directory)
> | write(2, "Error while loading \"pa_o.cmo\": file not found in path.\n", 56)
> = 56
> No trace of using the files in /usr/lib/ocaml/3.08.3/camlp4/.
> The build-environment is broken. Each second build it fails with
> | ocamlfind ocamlc -package "unix pcre equeue" -package camlp4 -syntax
> camlp4o -c nethttp.ml
> | File "nethttp.ml", line 1, characters 0-1:
> | Could not find the .cmi file for interface nethttp.mli.
This is strange indeed, I suspect a problem with ocaml-findlib on the
affected architecture. It is that package responsible for invoking the
compiler and preprocessor with the right parameters. How can I get an
environment in which reproduce the problem?
I tried logging on the s390 debian machine as well as the m68k one, but
even if there are dchroots for sid there are no (or I failed to find
them) pbuilders and of course I don't have the privileges to install the
needed build dependencies ...
Could you give me access to such an environment on s390?
Thanks for your feedback.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
signature.asc
Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Thu, Aug 18, 2005 at 07:56:28AM +0200, Christian T. Steigies wrote: > I tried to clean my buildd and now its broke worse than ever: > > Preparing to replace ocaml-nox 3.08.3-6 (using > .../ocaml-nox_3.08.3-7_m68k.deb) ... > ERROR: emacsen-common being used before being configured. Well, this is not related to ocaml-md5sums any longer, but to emacs. Julien, or someone else with emacs knowledge, could you please look at this issue? -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: Bug#312618: reopen
reopen 322210 merge 312618 322210 thanks On Thu, Aug 18, 2005 at 03:03:37PM +0200, Robert Millan wrote: > > Preparing to replace ocaml-nox 3.08.3-3 (using > .../ocaml-nox_3.08.3-7_i386.deb) ... > ERROR: emacsen-common being used before being configured. > ERROR: This is likely a bug in the ocaml-nox package, which needs to > ERROR: add one of the appropriate dependencies. > ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz > ERROR: for details. > dpkg: warning - old pre-removal script returned error exit status 2 > dpkg - trying script from the new package instead ... > ERROR: emacsen-common being used before being configured. > ERROR: This is likely a bug in the ocaml-nox package, which needs to > ERROR: add one of the appropriate dependencies. > ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz > ERROR: for details. > dpkg: error processing /var/cache/apt/archives/ocaml-nox_3.08.3-7_i386.deb > (--unpack): > subprocess new pre-removal script returned error exit status 2 -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#322210: [m68k] ocaml-nox: can not be removed
On Thu, Aug 18, 2005 at 09:53:00PM +0200, Christian T. Steigies wrote: > > Well, this is not related to ocaml-md5sums any longer, but to emacs. > > That is true, but your prerm script uses emacs, so your package has to > (pre)depend on emacs or something. I pointed out that the bug is not related to ocaml-md5sums just because the bug was originally related to that. Now, as you've problably seen, I've reopened the bug and merged it with the emacs related bug. That said your bug is proper, serious, and need to be fixed. Still, I know almost nothing about emacs and I thus asked for help on debian-ocaml-maint to people with more emacs policy knowledge. > Or are you actually part of the conspiracy trying to demote m68k to > second class citizens? ;-) Worst than that: our conspiracy is to have all architectures which do not support ocaml native code compilation demoted to SCC :-))) -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#300848: doesn't work anymore: fatal error
On Tue, Mar 22, 2005 at 10:34:58AM +0100, Enrico Zini wrote: > > $ polygen > > Fatal error: cannot load shared library dllunix > > Reason: dllunix.so: cannot open shared object file: No such file or > > directory > I didn't do anything! I swear! I trust you :) > It looks like a side effect of some change in some Ocaml runtime. Zack, > can you give me any clue? Actually we are in these days in the process of migrating from ocaml 3.08.2 to ocaml 3.08.3, and the first uploaded version of ocaml 3.08.3 is broken wrt dynamic loading of shared objects (like dllunix.so). _If_ polygen depends only on the ocaml runtime then you could solve the problem either getting ocaml 3.08.3-2 (actually in incoming and rebuilding) or by patching /usr/lib/ocaml/3.08.3/ld.conf so that it contains the following: /usr/local/lib/ocaml/3.08.3/stublibs /usr/lib/ocaml/3.08.3/stublibs instead of /usr/local/lib/ocaml/3.08/stublibs /usr/lib/ocaml/3.08/stublibs For references have a look at the thread starting here: http://lists.debian.org/debian-ocaml-maint/2005/03/msg00095.html > In the meantime, you should reinstall the graphic SCSI mouse to connect > a periferic. But pay attention: you either cannot boot an attachment, > or never have to cancel the connector to overclock a pointer over a > jumper over a pointer. I also suggest reinstalling the USB tea cup heater. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301141: liblablgtk2-ocaml: Fails to install because of wrong dependency on ocaml-base-3.08
On Thu, Mar 24, 2005 at 09:10:57AM +0100, Ralf Treinen wrote: > Well, it still is a bug in unstable, even if we (the ocaml maintainers) > know that it is only transitory. I have already tagged the bug report as > "pending" and the RM has tagged it as "sid" , but I don't think it should > be closed until a new liblablgtk2-ocaml is uploaded which is > installable with ocaml-* from unstable. Well, according to the upload log lablgtk2 has already been uploaded and is installable. So it is appropriate to close this bug report. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#300848: This is still present in sarge
On Tue, Apr 05, 2005 at 04:43:54PM +0200, Enrico Zini wrote: > > This bug is currently present in sarge. No, it is not. Versions of polygen in sarge works correctly with the ocaml version in sarge (just tried on an up-to-date testing machine). > > More exactly, there are at least two cases where this bug can cause > > breakage: Thus, if I understand correctly, you're saying that this _can_ be a bug if one of the two happens, am I wrong? If not, this bug should not be open in the BTS. > > 1. If someone using testing upgrades to the unstable ocaml If she do it via apt-pinning this is not an issue for the BTS: you get packages from unstable, you call for trouble. If not, how should she get the unstable ocaml? > > 2. if the ocaml transition makes it into testing and for any reason > >polygen will not enter testing at the same time, polygen in testing > >will be broken Here there is an issue indeed. The polygen version currently in testing doesn't adhere to the debian ocaml policy which require dependency on ocaml-base-nox-, but rather depends only on ocaml-base-nox. Last polygen version uploaded by Enrico to unstable has the correct dependency. Thus, theorically, it is possible that the ocaml transition makes it into testing and polygen not. If that happens, then polygen will break. Still, that case is rather unlikely since all ocaml packages should enter testing at once and some of them are still being uploaded these days. Unstable's polygen can't enter testing before of them (due to the ocaml-base-nox-3.08.3 dependency), but since it has already been uploaded it will enter testing in the same run of the testing scripts as all the other ocaml packages. That said, I still see no reason to have this bug open in the BTS: at the moment we have no problem with polygen in sarge. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#304161: planets uninstallable in sid
Package: planets Version: 0.1.12-3 Severity: grave Planets is currently not installable in sid: # apt-get install planets Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: planets: Depends: ocaml-base-3.08 but it is not installable E: Broken packages Package dependencies (both Depends and Build-Depends) need to be ported to ocaml 3.08.3. Cheers. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages planets depends on: pn ocaml-base-3.08 Not found. ii tk8.4 8.4.9-1Tk toolkit for Tcl and X11, v8.4 - -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#304885: FTBFS on ia64
Package: ocamlcreal Severity: grave ocamlcreal failed to build from sources on ia64: http://buildd.debian.org/fetch.php?&pkg=ocamlcreal&ver=0.4-6&arch=ia64&stamp=1113341294&file=log&as=raw at a first look it did not run configure before building the package and thus did not discover that ocamlc.opt was not available. I have no idea on why this happened only on ia64, maybe there is some issues with the toolchain. Still, the problem has to be faced since ocamlcreal is blocking the 3.08.3 transition. Could you please have a look at it? If the solution requires a new upload please upload with urgency (at least) medium. TIA, Cheers. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11-powerpc Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Bug#467422: tries to overwrite file owned by liblua5.1-posix-dev
Package: liblua5.1-posix1 Version: 5.1.2-2 Severity: serious During today's upgrade of unstable: dpkg: dependency problems prevent configuration of liblua5.1-posix-dev: liblua5.1-posix-dev depends on liblua5.1-posix1 (= 5.1.2-2); however: Package liblua5.1-posix1 is not installed. dpkg: error processing liblua5.1-posix-dev (--configure): dependency problems - leaving unconfigured Cheers PS for the maintainer and the Italian cabal: e non so nemmeno perché ho installato 'sto cavolo di pacchetto :-) Che bagaglio -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liblua5.1-posix1 depends on: ii libc6 2.7-8 GNU C Library: Shared libraries liblua5.1-posix1 recommends no packages.
Bug#429736: world readable passwords in /var/cache/debconf/config.dat
Package: zope-debhelper Version: 0.3.9 Severity: grave Tags: security The maintainer scripts generated by zope-debhelper leave passwords in /var/cache/debconf/config.dat. Passwords are therefor world readable by any user of the system. Tagging this bug a security since this is a local privilege escalation: users can access instances as the administrator user. As an example this is what I can read in the above mentioned file right now: Name: zenoss/admin-automatic-password Template: zope-common/admin-automatic-password Value: Owners: zenoss Flags: seen Variables: instance = zenoss password = ec298e16 user = admin zver = 2.9 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zope-debhelper depends on: ii debhelper 5.0.50 helper programs for debian/rules ii perl 5.8.8-7Larry Wall's Practical Extraction zope-debhelper recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419892: cduce_0.4.1-1+b1(ia64/unstable): FTBFS: SEGV runing ./cduce
On Fri, Jul 27, 2007 at 07:21:29PM +0200, Julien Cristau wrote: > > Severity: serious > > There was an error while trying to autobuild your package: > > > make[2]: Leaving directory `/build/buildd/cduce-0.4.1' > > > ./cduce -I web/ --compile web/xhtml.cd > > > make[1]: *** [web/xhtml.cdo] Segmentation fault > > > make[1]: Leaving directory `/build/buildd/cduce-0.4.1' > > > make: *** [build-stamp] Error 2 > > > > A full build log can be found at: > > http://buildd.debian.org/build.php?arch=ia64&pkg=cduce&ver=0.4.1-1+b1 > > Has anyone tried to find out what's going on here (or workaround it)? > It looks like cduce is being built with ocamlopt, which has a code > generation bug on ia64, so hopefully building cduce with ocamlc would > fix it. Thomas, are you still around? It seems the cduce package need some care ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#452104: Pleare rebuild against liblablgtk2-ocaml 2.10.0-2
On Tue, Nov 20, 2007 at 02:12:36PM +0100, Enrico Tassi wrote: > This is a mostly a reminder: please, rebuild the package against the new > version of gtk2 bindings. The lablgtk2 is already aware of this, he told me that he is going to ask for the needed binNMUs as soon as lablgtk2 has been rebuild on all archs. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#452104: fixed in unstable
Version: 0.7.8-3 Just uploaded a new version with the fixed dependencies. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#456310: network manager returns "no network device has been found" after last hal-info upgrade
Package: hal-info
Version: 20071212-1
Severity: grave
After the last upgrade of hal-info, network manager fails to find any
network device only reporting the error message mentioned in the subject
("no network device has been found") when clicking on the ex nm-applet
icon. (Note that this happens even with the network device not being
mentioned in /etc/network/interfaces as required by network-manager.)
Downgrading hal-info to the testing version (20071030-1) fixes the
problem.
I presume (though I haven't checked) that for finding the network
interfaces which are not listed in /etc/network/interfaces to be
managed, network manager does some lookup via hal, which fails due to
some hal-info breakage. Hence, I think that the other way of using
network-manager via /etc/network/interfaces suggested in
/usr/share/doc/network-manager/README.Debian (namely, to list the
desired interfaces as "auto" and with "dhcp") works, but I haven't tried
that.
My (wireless) network card is an Intel as described below by lspci:
06:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network
Connection (rev 05)
Subsystem: Intel Corporation Unknown device 2702
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
and works properly (without network-manager / hal) with the ipw2200
kernel module.
Severity grave since I bet other people with the same Intel card will
have a network shortage upon installing the current package version.
Thanks in advance,
Cheers.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
tags 457014 + confirmed thanks On Tue, Dec 18, 2007 at 11:52:11PM -0500, Daniel Schepler wrote: > /bin/sh: line 2: /usr/share/cdbs/1/class/ocamldoc-api-ref-config: Permission > denied > make: *** [build/libcryptgps-ocaml-dev] Error 126 > dpkg-buildpackage: failure: debian/rules build gave error exit status 2 > > I can also reproduce this on amd64 using ocaml packages compiled from > source. I can reproduce it here too, ocamldoc-api-ref-config is not installed as an executable script. Probably dh_fixperms is removing the +x bit. I'm rebuilding the package telling dh_fixperms to ignore such a script as a quick fix for this. A more proper long term fix would be to move ocamldoc-api-ref-config elsewhere, but I failed to find a proper place. Any suggestion? Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
On Wed, Dec 19, 2007 at 08:59:50AM +0100, Stefano Zacchiroli wrote: > > I just tried on my home box (amd64/sid), and cannot reproduce the error > > you describe on recompiling cryptgps. > mmmh, this is strange, I really don't see how can it built find for you: > the cdbs class now invokes > /usr/share/cdbs/1/class/ocamldoc-api-ref-config and that file is not > executable here: > > $ ls -l /usr/share/cdbs/1/class/ocamldoc-api-ref-config > -rw-r--r-- 1 root root 2238 2007-12-17 13:41 > /usr/share/cdbs/1/class/ocamldoc-api-ref-config > > Can you please check whether the above file is executable for you or > not? I've committed on the svn repo what I think is a fix for this (see my previous post to this bugreport). Before uploading however, I'll wait for some info from Ralf, since given his test in which the FTBFS does not manifest itself I fear there is something more to be understood ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#457014: ocaml-nox: Bad permissions on ocamldoc-api-ref-config
On Wed, Dec 19, 2007 at 08:44:32AM +0100, Ralf Treinen wrote: > I just tried on my home box (amd64/sid), and cannot reproduce the error > you describe on recompiling cryptgps. mmmh, this is strange, I really don't see how can it built find for you: the cdbs class now invokes /usr/share/cdbs/1/class/ocamldoc-api-ref-config and that file is not executable here: $ ls -l /usr/share/cdbs/1/class/ocamldoc-api-ref-config -rw-r--r-- 1 root root 2238 2007-12-17 13:41 /usr/share/cdbs/1/class/ocamldoc-api-ref-config Can you please check whether the above file is executable for you or not? TIA Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#441198: binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
Hi -releasers, can you please schedule a binNMU for the source package gtkmathview on amd64? Unfortunately I'm not entirely sure that it is the proper solution, since I did not (also after talking with upstream et al) about what was the cause of the crash, but we are quite convinced it was some toolchain breakage. Nevertheless, ATM rebuilding the package on amd64 fixes the problem, that's why I'm asking for the binNMU. Hints on what to do on other archs (i.e. binNMU also there?) are appreciated. On i386 the package works just fine, but I don't know what to expect elsewhere ... TIA, Cheers. On Fri, Sep 07, 2007 at 02:25:10PM +0100, Enrico Tassi wrote: > Package: libgtkmathview-bin > Version: 0.7.8-2 > Severity: normal > > --- Please enter the report below this line. --- > It crashes in a deterministic way, gdb bt and valgrind log follow. > I also attach the document I used to generate the crash. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446079: do nothing useful: "interface mismatch on Grammar"
Package: otags Version: 3.09.3-2 Severity: serious --- Please enter the report below this line. --- I'm using ocaml 3.10 with otags. Apparently otags is not capable of doing anything useful: $ otags *ml *mli Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. Error while loading "/usr/lib/ocaml/3.10.0/otags//tags.cma": interface mismatch on Grammar. The error message is reported once for each input file. I guess the problem is due to some camlp4 interface incompatibility, but passing "-camlp4 camlp5" did not help. Cheers. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstablepeople.debian.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends(Version) | Installed -+-=== ocaml-base-nox-3.10.0| camlp5 | 5.00-1 -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446462: /usr/bin/vim is left broken when alternative is manual and points to vim-full
On Sat, Oct 13, 2007 at 12:43:52PM -0400, James Vega wrote: > > *sigh* I don't know what made piuparts succeed before but it is > > definitely exhibiting the reported behavior now. Looks like it's time for > > another update-alternatives hack. Ok, also because I had indeed other out of bounds reports of the bug from other friends of mine. > Actually, it was a typo on my part in the preinst file. I'm preparing > a package now and will get it uploaded today. Many thanks for this! Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: missing dep on libxpm-dev (or spurious -lXpm in .la file)
Package: libt1-dev Version: 5.1.1-1 Severity: serious File: /usr/lib/libt1x.la Compiling against libt1-dev fails if libxpm-dev is not installed. Either it should be declared as a dependency of libt1-dev, or the reference to -lXpm in /usr/lib/libt1x.la file should be removed. Severity serious since this bug induces FTBFSs in other packages, which used to build just fine. As an example see the gtkmathview (source) package and #441198 (note that the bug per se is not due to libt1-dev, but in the bug log an example of the FTBFS induced by libt1-dev is reported). TIA, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libt1-dev depends on: ii libice-dev 2:1.0.4-1X11 Inter-Client Exchange library ii libsm-dev 2:1.0.3-1+b1 X11 Inter-Client Exchange library ii libt1-5 5.1.1-1 Type 1 font rasterizer library - r ii libx11-dev 2:1.0.3-7X11 client-side library (developme ii libxext-dev 1:1.0.3-2X11 miscellaneous extensions libra Versions of packages libt1-dev recommends: ii libt1-doc 5.1.1-1Type 1 font rasterizer library - d -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441198: binNMU request for gtkmathview on amd64 [Was: Re: Bug#441198: Crash on amd64]
On Mon, Oct 15, 2007 at 02:48:16AM -0700, Steve Langasek wrote: > ... also, after manually installing libxpm-dev for the build and installing > the resulting packages, I still get a segfault on amd64. So binNMUs don't > seem to be the answer here. Thanks for this investigation, I've just reported #446864 for the t1lib issue. Since upstream has just released 0.8.0 I'll wait for the above bug to be solved and then give again a try to the latest upstream. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: missing dep on libxaw7-dev
retitle 446864 missing dependency on libxaw7-dev thanks Package: libt1-dev Version: 5.1.1-1 --- Please enter the report below this line. --- In the end it seems that this bug boils down to a missing dependency from libt1-dev to libxaw7-dev. Indeed the latter package is listed as a *build* dependency but not as a dependency for the -dev package, potentially introducing unresolvable link flags. Please add the missing dep. I plan to do a delayed NMU since I really need this to be fixed and I'm (now) convinced it would introduce no harm. I hope you don't mind. Cheers. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-2-686 Debian Release: lenny/sid 500 unstablewww.debian-multimedia.org 500 unstablepeople.debian.org 500 unstableftp.it.debian.org 500 testing security.debian.org 1 experimentalftp.it.debian.org --- Package information. --- Depends (Version) | Installed ===-+- libt1-5 (= 5.1.1-1) | 5.1.1-1 libice-dev | 2:1.0.4-1 libsm-dev | 2:1.0.3-1+b1 libx11-dev | 2:1.0.3-7 libxext-dev | 1:1.0.3-2 -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#446864: here is a patch
tags 446864 + patch
thanks
Hi, please find attached the debdiff for the fixed package I'm going to
upload (delayed by 7 days).
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48) Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15) Bac: no, la demo scema\/right keys at the right time
diff -u t1lib-5.1.1/debian/control t1lib-5.1.1/debian/control
--- t1lib-5.1.1/debian/control
+++ t1lib-5.1.1/debian/control
@@ -23,7 +23,7 @@
Package: libt1-dev
Section: libdevel
Architecture: any
-Depends: libt1-5 (= ${binary:Version}), libice-dev, libsm-dev, libx11-dev, libxext-dev
+Depends: libt1-5 (= ${binary:Version}), libice-dev, libsm-dev, libx11-dev, libxext-dev, libxaw7-dev
Recommends: libt1-doc
Conflicts: t1lib-dev, t1lib1-dev
Description: Type 1 font rasterizer library - development
diff -u t1lib-5.1.1/debian/changelog t1lib-5.1.1/debian/changelog
--- t1lib-5.1.1/debian/changelog
+++ t1lib-5.1.1/debian/changelog
@@ -1,3 +1,10 @@
+t1lib (5.1.1-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add dependency from libt1-dev to libxaw7-dev (Closes: #446864)
+
+ -- Stefano Zacchiroli <[EMAIL PROTECTED]> Wed, 17 Oct 2007 16:49:42 +0200
+
t1lib (5.1.1-1) unstable; urgency=low
* new upstream version (Closes: #418664)
signature.asc
Description: Digital signature
Bug#446864: Bug#447368: gtkmathview: FTBFS: /usr/bin/ld: cannot find -lXpm
forcemerge 447368 446864 thanks On Sat, Oct 20, 2007 at 03:46:58PM +0200, Lucas Nussbaum wrote: > Package: gtkmathview > version: 0.7.8-2 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20071019 qa-ftbfs > Justification: FTBFS on i386 > /usr/bin/ld: cannot find -lXpm > collect2: ld returned 1 exit status This is not a bug in gtkmathview, but rather in t1lib. See #446864 for details. I've already NMUed t1lib, but I've uploaded it to the delayed 6 days queue some days ago (don't know how the upload should be visible ATM ...). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#447303: ocaml-syck: FTBFS without ocamlopt
On Fri, Oct 19, 2007 at 11:21:55PM +0200, Julien Cristau wrote: > See > http://buildd.debian.org/fetch.cgi?pkg=ocaml-syck&arch=hppa&ver=0.1.1-1&stamp=1192820955&file=log&as=raw > *.a files aren't built on architectures lacking a native compiler, so > shouldn't be installed. Yep, thanks for the report. More precisely (and as a reminder to self), the *.a files generated by ocamlopt from ocaml sources aren't built on non native architectures. On the contrary *.a files generated by ocamlmklib to statically link glue C/OCaml code are built also on non native architectures. This glitch was actually what fooled me here. Working on this, expect a pending tag soon. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#450903: libocamlnet-ssl-ocaml: segfault on custom ssl bindings
On Mon, Nov 12, 2007 at 02:56:34AM +0100, Romain Beauxis wrote: > While playing with the ssl_client.ml example, I ended up correcting two > issues: > * ssl_client.ml must use: > let cl_ctx = Ssl.create_context Ssl.TLSv1 Ssl.Client_context in > to use the correct function from ocaml-ssl > * The example segfaulted.. Can you please provide the example, so that we can test the fix? > After some introspection, helped by Sam, we found out that the package > ships its custom ssl extra-bindings. > These are out-of-date and caused the segfault. Out-of-date respect what? Thanks for the patch, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450903: libocamlnet-ssl-ocaml: segfault on custom ssl bindings
On Thu, Jan 10, 2008 at 09:47:04AM +0100, Samuel Mimram wrote: > AFAIR some code from the C headers of ocaml-ssl was copied into > ocamlnet-ssl but unfortunately I changed these definitions later in > ocaml-ssl and the disparity between the two libs was leading to a SEGV > in ocamlnet-ssl. Ah, so you did it in the beginning, do you mind getting in touch yourself with Gerd then to rectify the status quo? I can of course do it, but removing an intermediary would be faster. Please Cc the bug report if you do so; let me know otherwise. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441494: not installable: needs to be rebuilt against ocaml 3.10
Package: libgv-ocaml Version: 2.12-4 Severity: serious "libgv-ocaml" currently can't be installed on unstable due to the transition from ocaml 3.09 to ocaml 3.10. Simply rebuilding (binNMU should be ok as well) against the current ocaml-nox version in unstable should fix the problem, can you please ask for the rebuild and/or due a sourceful upload? If you need any help on this (including NMU) feel free to ask on [EMAIL PROTECTED] TIA, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441507: Bug#441502: coq - FTBFS: /bin/sh: camlp4o: command not found
On Mon, Sep 10, 2007 at 09:48:54AM +0200, Michael Ablassmeier wrote: > Package: coq > Version: 8.1.pl1+dfsg-1 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20070905 On Mon, Sep 10, 2007 at 09:49:05AM +0200, Michael Ablassmeier wrote: > Package: ocaml-sqlite3 > Version: 0.21.0-1 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20070905 On Mon, Sep 10, 2007 at 09:49:09AM +0200, Michael Ablassmeier wrote: > Package: planets > Version: 0.1.13-1 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20070905 All these bugs are due to the fact that the "/usr/bin/camlp4o" executable is no longer shipped by "ocaml-nox", but rather by "camlp4". Hence you now need to build depend on the "camlp4" package. Please note that if you use some more advanced camlp4 bundle executable (like, for example, "/usr/bin/camlp4orf") then you will also need to build-depend on "camlp4-extra" which ships it. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#442026: FTBFS on archs without the native-compilers
On Wed, Sep 12, 2007 at 05:51:26PM +0100, Enrico Tassi wrote: > --- Please enter the report below this line. --- > The .install.in file reports: > > debian/tmp/lablgtksourceview/*.cma > usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ > debian/tmp/lablgtksourceview/*.cmi > usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ > debian/tmp/lablgtksourceview/*.cmxa > usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ > > That is wrong on archs without the native compiler. I suggest a single Agreed, but probably something changed in the semantics of debhelper (or maybe from compatibility level 4 to 5 which I've bumped), something which AFAICT is not documented in the manpage. The lines above were not changed since the first upload in Debian and the package was built properly in the past on all architectures ... > debian/tmp/lablgtksourceview/*.cm* > usr/lib/ocaml/@OCamlABI@/lablgtksourceview/ I'm fine with this fix, but probably won't be able to commit/reupload it before this week-end. Feel free to fix it and reupload the package (adding yourself as an Uploader) .. or wait until this week-end. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#442997: please rebuild with ocaml 3.10 (currently uninstallable in sid)
Package: facile Version: 1.1-5 Severity: serious Hi, facile is currently uninstallable in sid due to the transition to ocaml 3.10; actually the package is also blocking the transition (among a few others). Please rebuild it against ocaml 3.10 and upload. I intend to NMU the package anytime soon, probably uploading to the 1-day delayed queue. Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
merge 444360 443150 tags 444360 + help tags 443150 + help thanks On Fri, Sep 28, 2007 at 02:10:06AM +0200, Frank Lichtenheld wrote: > your package failed to build from source. Yep, thanks, was already reported. I'll look into this but I would appreciate help from some of the Apache guys, since apparently apxs is not invoking the compilers to build PIC code ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:48:50AM +0200, Julien Cristau wrote: > The problem seems to be that you're trying to build the > mod_netcgi_apache.so shared object while linking with -lcamlrun, but > libcamlrun only exists as a static (non-PIC) library. Aaaarggh, right! IIRC that's an upstream issue for which exists a patch (by Richard Jones maybe ...), isn't it? What about applying it in the OCaml Debian package? Thanks for the pointer, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 02:10:45PM +0100, Richard Jones wrote: > In particular I could do it if INRIA said that they would support the > change in some future release (see the exception "Patches Heading > Upstream"). But otherwise this is quite a large ABI change -- if > Fedora users started to build lots of 64 bit shared libraries linked > with -lcamlrun I could end up maintaining it separately forever. I think you misunderstood my proposal. I don't want to apply your initial fix which changes libcamlrun.a into libcamlrun.so. I want to add a libcamlrun_shared.so, so there would be no ABI change, just the added possibility to link against it. Or maybe you're concerned about having to drop in the future support for libcamlrun_shared.so, but I think the user impact of that new library would be quite low. In fact I don't think anything else that mod_caml-like projects will need it ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 01:17:00PM +0100, Richard Jones wrote: > No I don't actually. It's strange because I didn't hit this bug at > all when compiling ocamlnet for Fedora. Are you building the Apache connector? The bug manifests itself only if you're building that, and only on architecture in which PIC code is actually different than non-PIC code. > Unfortunately Fedora policy stops me from incorporating this fix: > http://caml.inria.fr/mantis/view.php?id=3866 > into our OCaml. It would have to be accepted into upstream (INRIA's) > OCaml first. Why? > But it's desperately needed, so please vote for INRIA to include it :-) Well, nobody replied to the bug report, so I don't think pinging there will be useful. The only other possible step is to raise the problem on the caml mailing list, what do you think? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#444360: ocamlnet_2.2.8.1-3(hppa/experimental): FTBFS: tries to link non-PIC static object into shared object
On Fri, Sep 28, 2007 at 09:59:45AM +0200, Stefano Zacchiroli wrote: > Aaaarggh, right! IIRC that's an upstream issue for which exists a patch > (by Richard Jones maybe ...), isn't it? What about applying it in the > OCaml Debian package? Yep, that was the case, here is a link to the corresponding entry in the caml BTS: http://caml.inria.fr/mantis/view.php?id=3866 . Apparently upstream do not care a lot about this issue, but I think the final solution hinted by Richard is the right one: leave libcarmlrun.a as it is and additionally provide a libcamlrun_shared.so which we can use where PIC code is required. Any comments / objection to add something like that to the ocaml package in Debian? Richard: do you perhaps already have a patch for this in Red Hat? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Bug#483940: setting package to libgalax-ocaml-dev galax-extra galax-doc galaxd galax, tagging 483940
# Automatically generated email from bts, devscripts version 2.10.29 # # galax (1.1-3) unstable; urgency=low # # * debian/rules: remove .depend files created during clean, as they cause #FTBFSs (permission denied) on buildds using -rsudo (Closes: #483940) # package libgalax-ocaml-dev galax-extra galax-doc galaxd galax tags 483940 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501117: timer-applet: old preset files from stable cause crashes
On Sat, Oct 04, 2008 at 11:38:31AM +0200, Philipp Kern wrote: > [0] looks like a bug that could be found when updating from etch to Hi Philipp, "[0]" looks like a dangling reference, can you please expand it? TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501423: build-dep of gossip now fixed, need to be hinted
block 501423 by 494940 thanks Hi Nobse, On Tue, Oct 07, 2008 at 08:25:12PM +0200, Norbert Tretkowski wrote: > > Are you saying that gossip should be removed from testing and therefore > > removed from the release? > No. But we now really need a fix for the loudmouth RC bug. AFAICT, the bug you were referring to from #501423 was #494940, which now is fixed. Is that correct? Hence, gossip just need a hint to enter testing, it was needing just 2 days, 4 are elapsed, but of course it is blocked by the freeze. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501423: please unblock loudmouth 1.4.2-2 / reschedule gossip 1:0.31-1
Hi, loudmouth 1.4.2-2 is needed in testing to let gossip (which is in testing already) have all its needed build-deps. See #501423. There was an additional bug blocking loudmouth, #494940, which has been fixed by Löic 5 days ago. Since then loudmouth has been rebuilt everywhere and is apparently read to transition. Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip get satisfied in lenny, and then reschedule building in testing of gossip/1:0.31-1? FWIW, I do have tried building gossip in lenny against loudmouth 1.4.2-2 and it worked fine. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501423: please unblock loudmouth 1.4.2-2
On Sun, Oct 26, 2008 at 12:18:22AM +0200, Stefano Zacchiroli wrote: > Can you please unblock loudmouth 1.4.2-2, so that build-deps of gossip > get satisfied in lenny, and then reschedule building in testing of > gossip/1:0.31-1? Checking twice, only the unblock of loudmouth/1.4.2-2 is needed, as gossip/1:0.31-1 has already been rebuilt against the same version of loudmouth I'm requesting to unblock. Hence, I restrict my request to just: "please unblock loudmouth/1.4.2-2". Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434647: NMU is coming
I'm going to NMU to unstable a fixed version of kaffe as soon the build is complete. Attached you can find the current debdiff. AFAICT Patrick's patch was missing the fix for kaffe's pre*inst*. The attached patch fixes that as well. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach diff -u kaffe-1.1.8/debian/kaffe.prerm kaffe-1.1.8/debian/kaffe.prerm --- kaffe-1.1.8/debian/kaffe.prerm +++ kaffe-1.1.8/debian/kaffe.prerm @@ -6,7 +6,6 @@ if [ "$1" != "upgrade" ] ; then for file in appletviewer jar java javac javadoc javah javakey javap jdb native2ascii rmic rmiregistry serialver ; do update-alternatives --remove $file /etc/alternatives/kaffe-system/bin/$file || true - update-alternatives --auto $file || true done fi diff -u kaffe-1.1.8/debian/kaffe.preinst kaffe-1.1.8/debian/kaffe.preinst --- kaffe-1.1.8/debian/kaffe.preinst +++ kaffe-1.1.8/debian/kaffe.preinst @@ -5,7 +5,6 @@ if [ "$1" = "upgrade" ] ; then for file in appletviewer jar java javac javadoc javah javakey javap jdb native2ascii rmic rmiregistry serialver ; do update-alternatives --remove $file /usr/lib/kaffe/bin/$file || true - update-alternatives --auto $file || true done fi diff -u kaffe-1.1.8/debian/changelog kaffe-1.1.8/debian/changelog --- kaffe-1.1.8/debian/changelog +++ kaffe-1.1.8/debian/changelog @@ -1,3 +1,12 @@ +kaffe (2:1.1.8-5.2) unstable; urgency=high + + * Non-maintainer upload. + * Avoid making kaffe the default java compiler upon configuration, +overriding local choices. Thanks to Patrick Schoenfeld for the patch. +Closes: #434647 + + -- Stefano Zacchiroli <[EMAIL PROTECTED]> Sun, 26 Oct 2008 19:25:03 +0100 + kaffe (2:1.1.8-5.1) unstable; urgency=low * Non-maintainer upload. diff -u kaffe-1.1.8/debian/jikes-kaffe.prerm kaffe-1.1.8/debian/jikes-kaffe.prerm --- kaffe-1.1.8/debian/jikes-kaffe.prerm +++ kaffe-1.1.8/debian/jikes-kaffe.prerm @@ -3,7 +3,6 @@ case "$1" in upgrade | remove) update-alternatives --remove javac /usr/bin/jikes-kaffe || true -update-alternatives --auto javac || true ;; esac
Bug#503616: libapache2-mod-ocamlnet: mod_netcgi_apache.so will not load
On Mon, Oct 27, 2008 at 01:44:01PM +0100, Stéphane Glondu wrote: > Dave Benjamin a écrit : > > I installed libapache2-mod-ocamlnet and enabled the module using "a2enmod > > netcgi_apache". Apache 2 no longer starts, printing this message instead: > > Replacing the last line of /etc/apache2/mods-enabled/netcgi_apache.load > (the one mentioning netcgi_apache.cma) to: > > NetcgiLoad netcgi_apache/netcgi_apache.cma First of all thanks for the bugreport, the risk of overlooking this serious issue for Lenny was quite high :) Then, we have two issues here: 1) The wrong path in netcgi_apache.load, pointed out (together with a fix) by Stéphane. That's easily fixable, I can upload a fixed version of ocamlnet RSN. 2) The fact that camlrun_shared.so is not in a path known by ld.so. Which is a hell of a more tricky issue. On one hand one might argue that that library should belong to /usr/lib/ (or to some other dir known by ld.so). I frankly don't think so, because it is a high unstable library, introduced only recently upstream, ... and I don't want (yet) to take over the burden of version it with SONAMEs/VERSIONs/... *If* we decide it should belong /usr/lib/, then the most straightforwards solutions are: a) symlink /usr/lib/libcamlrun_shared.so -> `ocamlc -where`/... b) entry for `ocamlc -where` in /etc/ld.so.conf.d/ Both will require an upload of OCaml, which will make two uploads in total because ocamlnet needs to be fixed anyhow. Alternatively, we can try adding an RPATH to /usr/lib/apache2/modules/mod_netcgi_apache.so pointing to `ocamlc -where`. I got a bit rusty on the rpath issue [1,2], but I do think that in this case it would be acceptable. Comments? Cheers. [1] http://wiki.debian.org/RpathIssue [2] http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
