Bug#1068068: bobcat, time_t transition lead to apparent ABI break (was: Need rebootstrapping on armel and armhf).
Dear Peter Green, you wrote:
> > Also, the bootstrapping procedure is only required when icmake isn't
> > available ...
Thanks for your bugreport: I'm about to update icmake so that the circular
dependency between bobcat and icmake is removed. Shortly after icmake's
update bobcat will also be updated.
--
Frank B. Brokken
(+31) 6 5353 2509
PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
signature.asc
Description: PGP signature
Bug#1068068: Need rebootstrapping on armel and armhf
Dear Andrey Rakhmatullin, you wrote: > > Package: icmake,libbobcat6 > Severity: serious > Tags: ftbfs > > As src:icmake B-D:libbobcat-dev, src:bobcat B-D:icmake, there seems to be zero > packaging-level support for bootstrapping, the packages are not > cross-buildable > and the upstream bootstrapping instructions are too tedious, I'm filing this > for visibility (as there are ~14 packages B-D:libbobcat-dev). Thanks for your bug report. You write: > there seems to be zero packaging-level support for bootstrapping, the > packages are not cross-buildable and the upstream bootstrapping instructions > are too tedious, So far no issues were encountered when the bootstrapping procedure as described in the README.bobatbootstrap file in icmake's src distribution is followed. If you could be a bit more specific about what you mean by 'bootstrapping instructions are too tedious' then I'm sure those instructions can be changed so that they're less tedious. Wrt the package not being cross-buildable: The https://packages.debian.org/sid/libbobcat-dev shows the following lines for armel and armhf: armel 6.04.00-1 1,604.2 kB 8,598.0 kB [list of files] armhf 6.04.00-1 1,608.4 kB 8,126.0 kB [list of files] although I also see packages for which version 6.04.00-1+b2 or 6.04.00-1+b4 is listed. So maybe for unstable some issues recently appeared? Also, the bootstrapping procedure is only required when icmake isn't avaialble yet. For the construction of the bobcat library icmake 11.01.02-1 is required, and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since bullseye (oldstable). So maybe you can also provide some info about why the bootstrapping procedure is needed/used? In any case: the dependence on icmake when constructing the full bobcat library could be avoided, but I'd rather not do that once icmake *is* available. So please advise. -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#941554: yodl: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Dear Steve Langasek, you wrote: > Package: yodl > Version: 4.02.01-2 > Severity: serious > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu eoan ubuntu-patch > > Dear maintainers, > > The texlive-generic-recommended transitional package has been dropped from > texlive-base in sid. Please update your build-dependency to > texlive-plain-generic instead. Thanks for the bug report: I'll handle that either today or tomorrow. -- Frank B. Brokken (+31) 6 5353 2509 PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#901119: yodl: FTBFS when built with dpkg-buildpackage -A
Dear Santiago Vila, you wrote: > Sorry, there was a typo in the bug report. I meant "buster" of course. Ah, muy bien. Thanks for the clarification. > The reason for this is that -A was never tried with the current > version (4.02.00-2). > > You can avoid this type of bugs to propagate to testing by uploading > in source-only form (dpkg-buildpackage -S). That way we would get > official build logs here for the arch:all autobuilder: > > https://buildd.debian.org/status/package.php?p=yodl Thx for the advice! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#901119: yodl: FTBFS when built with dpkg-buildpackage -A
Dear Santiago Vila, you wrote: > > Package: src:yodl > Version: 4.02.00-2 > Severity: serious > > Dear maintainer: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > but it failed: (etc) Dear Santiago, Thx for the bug report. I'll have a look at it asap. As a side note: As `stretch' is the current stable distribution I'm slightly curious as to what may be have caused this error. Maybe -A has never been used? Anyway, I'll check things out. Maybe it's only required to define the missing target in debian/rules :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#887731: bisonc++ FTBFS with yodl 4.02.00-2
Dear Adrian Bunk, you wrote: > > Source: bisonc++ > Version: 6.00.00-2 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bisonc++.html > > ... > ./build man > mkdir -p tmp/man tmp/manhtml > yodl2man -o ../../tmp/man/bisonc++.1 bisonc++.yo > Yodl2man 4.02.00 > Yodl: including file ../../release.yo > bisonc++.yo:30: DEFINEMACRO: `tr' multiply defined Thanks! This is comparable to what you noticed yesterday with the C++ Annotations. I'll probably have it fixed by tomorrow. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#887581: c++-annotations FTBFS with yodl 4.02.00-2
Dear Adrian Bunk, you wrote: > > Source: c++-annotations > Version: 10.9.0-1 > Severity: serious > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/c++-annotations.html > > ... > yodl2txt --no-warnings -o ../tmp/docs/txt/cplusplus.txt -l3 cplusplus > Yodl2html 4.02.00 > Yodl: including file preamble > preamble.yo:208: DEFINEMACRO: `nbsp' multiply defined Oops... Thanks: I'll fix that later today. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#871210: stealth: FTBFS: ! LaTeX Error: Lonely item--perhaps a missing list environment.
Dear Lucas Nussbaum, you wrote: > > Source: stealth > Version: 4.01.05-2 > Severity: serious > Tags: buster sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20170805 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. Hi Lucas, Thanks for your bug report. I'll check it out asap. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#823043: zsh FTBFS since yodl 3.08.00-1 in the same way that c++-annotations FTBFSed with 3.07.00-1 (was: Re: Bug#823043 closed by f.b.brok...@rug.nl (Frank B. Brokken) (Bug#823043: fixed in yodl 3
Dear Axel Beckert, you wrote: > Hi Frank, Hi Axel, You wrote: > I'm not 100% sure what's going on, but it seems to me that while > c++-annotations indeed FTBFS with 3.07.00-1 and builds fine again with > 3.08.00-1 (verified it :-), it's the opposite way round with zsh: > > It builds fine with yodl 3.07.00-1, but FTBFS with 3.08.00-1 as > follows: > > ...Zsh Yodl-to-man converter > Including file Zsh/zftpsys.yo > yodl -k -L -o ../../Doc/zshzle.1 -I../../Doc:. -w zman.yo version.yo > ../../Doc/zshzle.yo > Zsh Yodl-to-man converter > Including file Zsh/zle.yo > yodl -k -L -o ../../Doc/zshall.1 -I../../Doc -DZSHALL -w zman.yo version.yo > zsh.yo > `ZSHALL' (symbol) multiply defined > `ZSHALL' (symbol) multiply defined > `ZSHALL' (symbol) multiply defined > Error(s) in command line arguments. Terminating > ... Thanks for reporting this bug: I just downloaded the zsh source package and can reproduce the error. I'll have a look at what's going, and report back to you once I know more. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#823043: c++-annotations: FTBFS: `APATH' (symbol) multiply defined
Dear Chris Lamb, you wrote: > Source: c++-annotations > Version: 10.5.0-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > c++-annotations fails to build from source in unstable/amd64: Hi Chris, Thanks for your bug report. It looks like you encountered a real bug, and I'm still somewhat in the dark as to why it never has been observed before. Because of that (i.e., me satisfying my own curiosity) I'll need a bit more time to submit a fix, but at least I think I've located the cause of the problem. I'll probably have a fix ready by Monday or a bit earlier. One minor thing: it's not an Annotations issue, but a bug in the Yodl package. I suggest you (or Tony, or George, who receive CCs) reassign this bug to yodl, since that's where the fix is required. Thanks again, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#822519: bobcat: FTBFS: /usr/bin/yodl indicates failure
Dear Martin Michlmayr, you wrote: > > Package: bobcat > Version: 4.01.04-1 > Severity: serious > > Hi Frank, here's a build failure of bobcat. I don't know if it's a > regression in yodl or if something has to change in bobcat, but in any > case, bobcat fails to build from source in unstable (FTBFS): Thanks again! I overlooked your e-mail, but I was informed by Tony about it. It's the same issue as with bisonc++, and right now I'm preparing a fix, which should be ready within the hour. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote:
> Yeah, that's the whole point of these archive rebuilds of unstable
> that various people in Debian do -- to rebuild everything in unstable
> and to catch build failures because of something changed in unstable
> (e.g. toolchain, libraries, other tools).
Agree 100%. And the fix is on its way :-)
Thanks again!
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote:
> Looks like Tony can reproduce it. I just wanted to add briefly that
> this has nothing to do with HPE Helion. It's a normal Debian
> installation and a normal Debian sid chroot using sbuild.
Oops, guys: OK, hold your fire: the flaw is at my side: I missed that Martin
already used yodl 3.07.01, and while reading Tony's mail I noticed that Tony
*did* use the latest Yodl version. When I do that too, I also reproduced the
error. So I think the bug can safely be reassigned to yodl, and I also think
it can quickly be fixed.
Thanks for the quick reply, guys: I'll do my best to come up with the fix
equallly quick :-)
Cheers,
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
signature.asc
Description: PGP signature
Bug#822410: bisonc++: FTBFS: failure of system call / usage: ...
Dear Martin Michlmayr, you wrote: > > Package: bisonc++ > Version: 5.00.00-1 > Severity: serious > > This package fails to build in unstable: > > > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux > ... > > Yodl: including file algorithm/ruleprec.yo > > Yodl: including file algorithm/condep.yo > > Yodl: including file algorithm/reduce.yo > > usage: [-a] [-N] [-n] [-s] [-t] [-S] [-T] marker file > > See also: `man yodlverbinsert' > > Yodl: including file algorithm/mysterious.yo ... > > Fatal: system - failure of system call (status 256) > > debian/rules:41: recipe for target 'build-indep' failed > > make: *** [build-indep] Error 1 > > -- > Martin Michlmayr > Linux for HPE Helion, Hewlett Packard Enterprise Hi Martin, Thanks for the bug report. Ususally a bug report provides me with clear hints about its causes, but this time I'm at a loss. Building the manual on amd64 archs works OK, and I have no access to a HPE Helion machine, so it's hard to reproduce the bug. I'm also wondering why the bug appears when yodl processes algorithm/reduce.yo, and not earlier. E.g., the macro 'verbinsert' is called in documentation/manual/algorithm/reduce.yo, but before that in examples/rpndecl.yo:verbinsert(//DECL)(rpn/parser/grammar) examples/rpngram.yo:verbinsert(//RULES)(rpn/parser/grammar) examples/errors.yo: verbinsert(//LINE)(errorcalc/parser/grammar) and only then: algorithm/reduce.yo:verbinsert(-as4)(examples/rr1) But when used in reduce.yo another type of argument (-as4) is passed to yodlverbinsert than in the other three cases, where a //XXX marker is used (the short usage info displayed by yodlverbinsert suggests that a marker is required, but that's not actually true, cf. yodlverbinsert's man-page). There is of course a poor-man's solution: I build the documents and provide the pre-built documents with the debian package. But it would be nice to know why we get the FTBFS problem on the Helions. Maybe I could ask you to replace line 7 ofdocumentation/manual/algorithm/reduce.yo verbinsert(-as4)(examples/rr1) by VERBOSITY()(0x4) verbinsert(-as4)(examples/rr1) VERBOSITY()(NONE) and then run ./build manual in bisonc++'s base directory (where you also find a file named CLASSES) and send me the output? That might provide a little more info about what went wrong. For now, lacking access to a Helion machine, I'm afraid I have to ask you for some help Cheers, [Cc: Tony/George] -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Here is a more complete log excerpt for v228 (full log attached) > > > Dez 20 01:27:42 debian systemd[1]: -.mount: Changed dead -> mounted ... > > So the best guess is that the timing in v228 changed a little (some code > paths became faster). This would confirm Frank's findings that enabling > verbose output (which slows down boot a bit) made it less likely to hit. > > Martin has been working/debugging the tentative stuff in the past, so > maybe he has some insights here. > > We should probably also involve upstream at some point. OK, thanks for the help and (for me at least) final conclusion. For me personally the problem has been solved: for the time being I'm happy with 227, and I'm sure that the problem will soon be fixed. Thanks again for helping along! Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > > This information is available at https://www.icce.rug.nl/systemd in the > > files > > initramfs.debug and alb. > > Hm, unfortunately the journal dump is incomplete again. I have no idea why Remarkable. I made it available the way I got it, so that's apparently what there is. > > booting procedure. You're sure it can't be some timing problem? > > Well, what kind of timing problem do you have in mind? Don't know: I didn't design systemd. But if it's doing things in parallel then maybe on newer, faster, computers things might have completed, like remounting /usr rw before it's actually used. A race condition might then explain why the problem doesn't always show itself, and why chances of failure are reduced when more time is spent writing debug/verbose messages. > So far, the only thing I can say for sure looking at the initramfs log, > is that /usr has been mounted successfully in the initramfs. > > "Something" apparently causes /usr to be unmounted later on. Which part > and why that is, is not clear yet. > > Do you have any (custom) init scripts in /etc/rcS.d/ which fiddle around > with mount settings, run telinit or stuff like that? Nope. > I'm running out of ideas, tbh. Well, that's already a *lot* more than I could offer myself :-) But fortunately (for me, but hard to fix, I realize), the problem doesn't emerge all the time. If rebooting every now and then gets me a running system, then so be it. The FailureAction=reboot-force entry in systemd-remount-fs.service already has proven to be my friend :-) > If you suspect the remount service to be the cause for this, let's > output the mounts before and after > For that run > $ systemctl edit systemd-remount-fs.service When I issue that command I get the reply Warning: systemd-remount-fs.service changed on disk. Run 'systemctl daemon-reload' to reload units. I guess the warning is obvious as I edited the file /lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service to prevent the reboot action. So I did as advised and reran the command, but got an empty file in my editor, while the following message was shown after ending the editor: Editing "/etc/systemd/system/systemd-remount-fs.service.d/override.conf" canceled: temporary file is empty. > Then add > [Service] > ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt' > ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt' > > Reboot and attach the journal log again. Instead of running the systemctl command I edited the file /lib/systemd/system/local-fs.target.wants/systemd-remount-fs.service and added the lines you suggested. My next e-mail is about the contents of journal log. Thereafter I'll try to downgrade to the previous version to see what happens then. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael, The journalctl -alb output after adding: > Then add > [Service] > ExecStartPre=/bin/sh -c 'echo "before rootfs remount"; findmnt' > ExecStartPost=/bin/sh -c 'echo "after rootfs remount"; findmnt' and rebooting (until failure) is at https:/www.icce.rug.nl/systemd/alb-1650 It does contain the 'before rootfs' line, but the 'after rootfs' line isn't there: $ grep 'before rootfs' *1650 Dec 19 16:45:18 localhost.localdomain sh[430]: before rootfs remount Dec 19 16:45:20 localhost.localdomain sh[487]: before rootfs remount Dec 19 16:45:21 localhost.localdomain sh[516]: before rootfs remount Dec 19 16:45:24 localhost.localdomain sh[620]: before rootfs remount $ grep 'after rootfs' *1650 $ Next thing I'll try is to downgrade to 227-2. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael, I downgraded to the following versions of the following packages: libpam-systemd_227-2_i386.deb libudev1_227-2_i386.deb libsystemd-dev_227-2_i386.deb systemd-sysv_227-2_i386.deb libsystemd0_227-2_i386.deb systemd_227-2_i386.deb libudev-dev_227-2_i386.deb udev_227-2_i386.deb Thereafter I rebooted several times without encountering any problems. Also with reduced output (grub's option 'quiet') no problems were encountered. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Am 18.12.2015 um 15:59 schrieb Frank B. Brokken: > > Is there a way to determine that? What I do to upgrade the system is run > > 'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that > > tells me what packages and versions were updated at what moments in time? > > /var/log/dpkg.log is a low-level log. > > and then there is one for aptitude at /var/log/aptitude Thanks: I made the logs available at https://www.icce.rug.nl/systemd > ... > Btw, you mentioned that this happened after an upgrade. Which previous > version did you run which worked fine? Which other packages were > upgraded along with it? Tue, Dec 1 2015 14:07:23 +0100: the aptitude log shows an upgrade from systemd 227-2 to 228-2 dpkg log: 2015-12-01 14:08:42 upgrade systemd:i386 227-2 228-2 dpkg log: 2015-12-03 08:30:01 upgrade systemd:i386 228-2 215-17+deb8u2 Thu, Dec 3 2015 08:31:37 +0100 the aptitude log shows an upgrade from systemd 215-17+deb8u2 -> 228-2 dpkg log: 2015-12-03 08:31:40 upgrade systemd:i386 215-17+deb8u2 228-2 and then, recently, by me trying to downgrade: dpkg log: 2015-12-17 12:59:12 upgrade systemd:i386 228-2 228-2 dpkg log: 2015-12-18 16:15:37 upgrade systemd:i386 228-2 215-17+deb8u2 dpkg log: 2015-12-18 16:17:11 upgrade systemd:i386 215-17+deb8u2 228-2 Before Dec 1 no updates were recorded for systemd or udev, and until the upgrades early December everything ran fine. > If you downgrade systemd/udev, does the problem go away? As I feared, downgrading is difficult because of the many reverse dependencies. I looked at ftp://ftp.de.debian.org/debian/pool/main/s/systemd/ which is the mirror I usually use for earlier .deb files, but the one before 228-2 is 215-17, and 227-2 is only available as source archives and not AFAICS as .deb packages. I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015 03:15:15 +0100) and let you know the results. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Hi Michael,
As announced in my previous e-mail:
> I'll add the debug entry next (cf. your mail from Date: Fri, 18 Dec 2015
> 03:15:15 +0100) and let you know the results.
This information is available at https://www.icce.rug.nl/systemd in the files
initramfs.debug and alb.
Maybe useful to note: it took like four or five reboot attempts before the
booting process eventually failed. This time even more output than with using
'verbose' flashes by during the booting process, which somewhat slows down the
booting procedure. You're sure it can't be some timing problem?
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
signature.asc
Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Well, /usr is mounted by the initramfs these days. So it should already > be available when systemd is started. If that fails, this is a bug which > needs to be addressed by initramfs-tools (or one of the hook scripts). > It wasn't clear so far that /usr hasn't been mounted at all. > > Is /usr on LVM, RAID, etc? No, nothing like that. And for what it's worth: the problem only appeared after I upgraded systemd last week. The laptop has nothing special in its setup, and has been working perfectly for years, until last week when systemd was renwed. I think in my bugreport I mentioned the problem that /usr wasn't mounted. In your next reply you wrote: > I'm a bit confused by those logs. They show that sda5 have been mounted. > > Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounting > ext3 file system using the ext4 subsystem > Dec 17 15:44:29 localhost.localdomain kernel: EXT4-fs (sda5): mounted > filesystem with ordered data mode. Opts: (null) > > I figure /dev/sda5 is your /usr partition? Just to be sure, please > attach ls -la /dev/disk/by-uuid/ I seem to remember that message, in particular the Opts: (null) remark, and I think at that point /usr was mounted by me fron the systemd shell. Also, couldn't it be that initramfs *did* do the mount, but that remounting it rw, als reported in the error message is the problem? Also, to me it appears remarkable that by removing the 'quiet' from the kernel parameters, so that things go a bit slower because of the extra messages that are displayed the frequency of failing boot procedures is greatly diminished. I'm considering trying to add 'verbose' to grub's parameters to see if that produces more output and maybe further reduces the frequency, but I haven't had the time to do that yet. Something on the TODO list :-) Anyway, here's the ls -la output: total 0 drwxr-xr-x 2 root root 200 Dec 18 13:05 ./ drwxr-xr-x 5 root root 100 Dec 18 13:02 ../ lrwxrwxrwx 1 root root 10 Dec 18 13:02 04b82e8b-f871-4abb-978a-44ae44c5d1f7 -> ../../sda1 lrwxrwxrwx 1 root root 10 Dec 18 13:02 595bcdbf-6436-45a7-99d2-297a3dd85930 -> ../../sda6 lrwxrwxrwx 1 root root 10 Dec 18 13:02 693c71eb-d411-4ee0-a1b3-c577df02e01b -> ../../sda9 lrwxrwxrwx 1 root root 10 Dec 18 13:02 6bcb2a05-33c9-402b-8093-e6a35ffd7aa1 -> ../../sda8 lrwxrwxrwx 1 root root 11 Dec 18 13:05 82e52787-6072-4af9-a5e6-2d88c365e62b -> ../../loop0 lrwxrwxrwx 1 root root 10 Dec 18 13:02 c5591eff-0a6c-4310-bb11-7d5535f7da7b -> ../../sda7 lrwxrwxrwx 1 root root 10 Dec 18 13:05 e289e4ad-be1d-42a8-9b38-f4dad9473520 -> ../../dm-0 lrwxrwxrwx 1 root root 10 Dec 18 13:02 ea8202e7-4564-424c-af70-a6a640fafb65 -> ../../sda5 ~ I'll do the 'debug' addition later this weekend, like you requested. Finally, you asked: > Do you have any custom udev rules in /etc/udev/rules.d? I don't think so, looking at the time stamps nothing has been changed there for years: total 10 drwxr-xr-x 2 root root 3072 Dec 6 2014 ./ drwxr-xr-x 4 root root 1024 Dec 3 08:34 ../ -rw-r--r-- 1 root root 115 Dec 6 2014 70-automount.rules -rw-r--r-- 1 root root 3841 Dec 6 2014 70-persistent-cd.rules -rw-r--r-- 1 root root 895 Feb 26 2013 70-persistent-net.rules And I definitely didn't recently change there any files, so again: the problem appeared out of the blue since last weeks upgrade. I hope the above gives you at least some additional info. As I wrote: I'll do the 'debug' addition tomorrow. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > The verbose debug log from the initramfs and systemd can maybe tell us > more. But looking at https://www.icce.rug.nl/systemd/journalctl, the > sda5 mount happens at line 773, the first errors start at line 785 and > the remount is at line 802. > So it looks like /usr is not mounted at the time > systemd-remount-fs.service is run. Right. That's consistent with the impression I got from the error messages. *Why* that is true, however, eludes me. > > What's also curious is, that the log doesn't seem to be complete. > Usually systemd's first log line is something like > > > Dez 18 07:03:47 pluto systemd[1]: systemd 228 running in system mode. (+PAM > > +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP > > +GCRYPT +GNUTLS +ACL +X > > Dez 18 07:03:47 pluto systemd[1]: Detected architecture x86-64. > > Those early boot messages seem to be missing completely. Well, I didn't edit anything. The information I generated is passed to you the way it was made available by the various programs/commands. > Btw, you mentioned that this happened after an upgrade. Which previous > version did you run which worked fine? Which other packages were > upgraded along with it? Is there a way to determine that? What I do to upgrade the system is run 'aptitude update' and then 'aptitude upgrade'. Is there a log somewhere that tells me what packages and versions were updated at what moments in time? > If you downgrade systemd/udev, does the problem go away? I thought about doing that, but was afraid for an avalanche of forced downgrades of packages that might now depend on the most recent udev and systemd versions. But I'll give it a try asap and let you know the results. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > What happens afterwards? Are you dropped into the rescue shell? Afterwards (i.e., after the initial failure message) the system tries to continue booting, but shows lots of failure messages, eventually grinding to a halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue shell. > If not, try to enable the debug shell by adding "systemd.debug-shell" to > the kernel command line. This will give you a root shell on tty9. Unfortunately, it doesn't, since the system halts (I first removed the automatic reboot on failure). However, during the process I observed that setting systemd.debug-shell and removing the default 'quiet' specification from grub's /etc/default/grub (so, now it specifies: GRUB_CMDLINE_LINUX_DEFAULT="systemd.debug-shell" greatly reduces the chances of a failing boot. Not completely, but greatly. Still, when rebooting fails there's just the plain halt, w/o a debug shell. Since removing the quiet also produces a lot more output on the screen, might my problem not simply be some timing problem? -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808151: systemd: failed to start remount root and kernel file system
Dear Michael Biebl, you wrote: > Am 17.12.2015 um 13:46 schrieb Frank B. Brokken: > > halt. No reboot (e.g. ctrl-alt-del) is possible and there's no rescue > > shell> > What exactly do you mean with halt? The systems completely locks up so > you can't use the keyboard and switch to tty9? No, that's not what happens. I mean that doing a reboot using ctrl-alt-del isn't possible. Switching VTs is no problem, but except for VT1 nothing was being shown. But maybe I overlooked things when I sent you the previous reply: see below. > That would sound like a kernel problem. > > might my problem not simply be some timing problem? > > Can you make a screenshot or a video from the boot process with "quiet" > removed from the kernel command line. I did. Not only that, I also tried to reboot again and this time I was able to run the commands you asked before from tty9: systemctl status systemd-analyze dump journalctl -alb This time the debug shell prompt was available at tty9, although booting failed. And in line with my previous findings, systemd-analyze and journalctl weren't available, as they live in /usr/bin, and /usr hadn't been mounted. But after mounting /usr from tty9 and then using the mount command systemd-analyze and journalctl were available, so I also have the output from those commands for you. The output, and the mp4 movie I made during the booting process are a bit too large for the e-mail, but they are available for download/inspection at https://www.icce.rug.nl/systemd/ Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: PGP signature
Bug#808016: bisonc++: FTBFS: [icmake/readlog, line 5] Error: conflicting operand types for fgets
Dear Chris Lamb, you wrote: > Source: bisonc++ > Version: 4.11.00-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > bisonc++ fails to build from source in unstable/amd64: Ha! I beat you here by 1/2 day :-) Yesterday I prepared a new release, among other adapting the scripts to icmake 8.00.04 and updated the Debian files accordingly. We're now at bisonc++ 4.13.00, and the new package should be available RSN. @Tony: could you add a Closed #808016 entry to Debian's changelog, please? scripts and > > [..] > > # Add here commands to clean up after the build process. > ./build clean > [icmake/md, line 15] Warning: `sizeof' is deprecated. Use `listlen' > ... > 2 error(s) detected > debian/rules:52: recipe for target 'clean' failed > make: *** [clean] Error 1 > > [..] Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807734: bobcat: FTBFS: Error: double quote at end of string not found
Dear Chris Lamb, you wrote: > bobcat fails to build from source in unstable/amd64: > ./build clean > [./build, line 38] Error: double quote at end of string not found > [./build, line 38] Error: Syntax error at `#include' > debian/rules:34: recipe for target 'clean' failed Thanks! That's a plain old typo. But an update also including the required changes for the icmake 8.00.04 upgrade is being prepared right now. -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807746: guncat: FTBFS: "CXX multiply defined"
Dear Chris Lamb, you wrote:
> guncat fails to build from source in unstable/amd64:
> ./build clean
> [icmconf, line 21] Error: CXX multiply defined
> [icmconf, line 30] Error: LDFLAGS multiply defined
> debian/rules:49: recipe for target 'clean' failed
> make: *** [clean] Error 1
Thanks! The update adapting the icmake 8.00.04 will arrive shortly
--
Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#807672: natlog: FTBFS: [/usr/bin/icmbuild, line 166] Error: idx undefined
Dear Chris Lamb, you wrote: > natlog fails to build from source in unstable/amd64: Yes, it's a hard life But no kidding: thanks for the update. The build-problems are caused by natlog's build script not yet being updated to the latest icmake version. I'm working on that right now, and I'll raise natlog in my personal priority stack ;-) In the meantime, you could change 'sizeof' into 'listlen', as suggested: > [icmake/md, line 15] Warning: `sizeof' is deprecated. Use `listlen' > [/usr/bin/icmbuild, line 166] Error: idx undefined > [/usr/bin/icmbuild, line 166] Error: Incorrect returntype for function > 'find()' and this error is simply fixed by moving the 'int idx' definition in the for statement to right above the for statement. The following change should be all that's required: int idx;// definition moved out of the next for-statement for (idx = listlen(haystack); idx--; ) But I'll handle this bug ASAP. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Bug#790985: bobcat: library transition may be needed when GCC 5 is the default
Dear tony mancill, you wrote: Frank, George, I've pushed a new branch to alioth for this upload. The branch name is bobcat-gcc5abi. Please let know if you have any concerns, otherwise, I'll plan to upload the evening of August 11th (here in GMT-0700). No problems from my side, thanks for the assistance :-) Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: Digital signature
Bug#790985: bobcat: library transition may be needed when GCC 5 is the default
Dear Julien Cristau, you wrote: Control: severity -1 serious Control: tag -1 confirmed On Tue, Jul 7, 2015 at 20:47:28 +0200, Frank B. Brokken wrote: - Rebuild the library using g++/g++-5 from experimental. Note that most likely all C++ libraries within the build dependencies need a rebuild too. You can find the log for a rebuild in https://people.debian.org/~doko/logs/gcc5-20150701/ Search for BEGIN GCC CXX11 in the log. - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. [...] Thx for the bug report. Right now I'm abroad, and unable to do any maintenance until I'm back by the end of July. By then I'll have a close look at the points you're mentioning. Thanks again! Confirmed that public symbols are changing with the g++ 5 rebuild; a patch to rename the library package is available at https://launchpad.net/ubuntu/+source/bobcat/3.25.01-2ubuntu2 Thanks for the bug report. We're still working out how to handle this issue. The plan is to do an so bump to version 4 of the bobcat library. Some time ago (early August) Debian's experimental distro offered a g++ 5 release that indeed created a library in which the public symbols were changed. We think that bumping the so version, in line with an earlier e-mail by Matthias, effectively handlres the new symbols issue. However, by now the g++ 5 compiler no longer is available in Debian's experimental distribution, but only in Debian's stretch (testing) and sid(unstable) distros, and these compilers don't use the new naming conventions. Right now Tony and I are figuring out a strategy for handling this complication, but we're not done yet. This reaction is primarily to inform you that we're not ignoring the issue, but in fact are actively trying to find an adequate solution. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759248: ssh-cron: FTBFS - missing -lpthread
Dear Michael Tautschnig, you wrote: Package: ssh-cron Version: 0.91.02-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. ... It seems -lpthread is missing from the build command line. Hm, maybe (some) architecture dependency. Anyway, I'll fix this tomorrow. Thanks for the report! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA signature.asc Description: Digital signature
Bug#682640: Processed: tagging 682640
Dear Debian Bug Tracking System, you wrote: Processing commands for cont...@bugs.debian.org: tags 682640 + confirmed Bug #682640 [src:c++-annotations] c++-annotations: FTBFS: htmlindex causes segmentation fault Lucas Nussbaum reported: ... mv _cplusplus02.html cplusplus02.html ../../../scripts/patchhtml cplusplus01.html _cplusplus01.html mv _cplusplus01.html cplusplus01.html ../../../scripts/patchhtml cplusplus.html _cplusplus.html mv _cplusplus.html cplusplus.html touch ../../html-stamp ../../../scripts/htmlcontentspage contents.html grep '^index' cplusplus.html cplusplus??.html cplusplus.index ../../bin/htmlindex cplusplus.index cppindex.html Segmentation fault system - failure of system call (status 35584) system - failure of system call (status 35584) make: *** [build-stamp] Error 1 The segfault is most likely caused by an outdated libbobcat-dev library in debian/control, which we forgot to update. It should have been: libbobcat-dev (= 3.10.01) I just ran ./build docs on amd64, using this bobcat version, and the segfault disappeared: ... mv _cplusplus01.html cplusplus01.html ../../../scripts/patchhtml cplusplus.html _cplusplus.html mv _cplusplus.html cplusplus.html touch ../../html-stamp ../../../scripts/htmlcontentspage contents.html grep '^index' cplusplus.html cplusplus??.html cplusplus.index ../../bin/htmlindex cplusplus.index cppindex.html File cplusplus.html at 0 File cplusplus02.html at 1 File cplusplus03.html at 2 File cplusplus04.html at 3 File cplusplus05.html at 4 File cplusplus06.html at 5 File cplusplus07.html at 6 File cplusplus08.html at 7 File cplusplus09.html at 8 File cplusplus10.html at 9 File cplusplus11.html at 10 File cplusplus12.html at 11 File cplusplus13.html at 12 File cplusplus14.html at 13 File cplusplus15.html at 14 File cplusplus16.html at 15 File cplusplus17.html at 16 File cplusplus18.html at 17 File cplusplus19.html at 18 File cplusplus20.html at 19 File cplusplus21.html at 20 File cplusplus22.html at 21 File cplusplus23.html at 22 ../../bin/rmindexlines cplusplus23.html _cplusplus23.html mv _cplusplus23.html cplusplus23.html ... We'll prepare a new control file asap. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504603: libbobcat1: shlibs file fails to reflect ABI additions
Dear Aaron M. Ucko, you wrote: Package: libbobcat1 Version: 1.21.1-1 Severity: serious Justification: Policy 8.6 libbobcat1's shlibs file leads to unversioned dependencies on the library, ... In this case, though, I would suggest simply adding -V to your call to dh_makeshlibs, such that packages built against libbobcat1 always depend on at least the upstream version against which they were built. Dear Aaron, Thank you for filing this bug against Bobcat. You're of course absolutely right and I think your suggestion is a valuable one that can easily be met in future releases. Actually the bug filed against xd clarified the (dependency) bug that had crept into the dependencies list. The problem will be attacked along two main approaches: 1. paying more attention to ABI and API breakages; 2. making sure that (at least my :-) packages clearly display the bobcat version against which the package should be linked. This reply was (of course) not written to close the bug; it was primarily sent to let you and others know that I'm aware of the problem and that for now using the latest (now 1.21.1) Bobcat version with packages that depend on Bobcat should be enough to avoid problems. Current work in progress on Bobcat will probably result in version 2.01.1 from which point on more thorough attention will be paid to version dependencies. Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499421: ecasound: manpage contains garbage
Dear Junichi and Adrian, Thanks for filing the Yodl bug report. You have a valid point (and I must admit I never considered that somebody might run yodl as the same user in parallel runs...). I also think that the problem is less severe than `serious' since the yodl2whatever script provides options allowing for this situation. Nevertheless, while I prepare a more elegant way to handle the problems you reported I suggest you use the options provided by yodl2whatever. Here are some considerations: By default the user name is used in the tmp files to prevent the tmp directory from getting clobbered by all kinds of leftovers from earlier runs. Although that file is intended for consumption by yodlpost sometimes it's read by humans as well. But that's the exception so it's probably more useful to remove it by default. Currently, the yodl2whatever script provides the --unique flag, which *will* create a unique filename (but the file will outlive the yodl run, so you'll have to do some cleaning up, I guess). In addition, the --tmp=path option is provided, so you could define different locations for, e.g., a man-page run and a html-run like this: For the man-page run: yodl2man --tmp=/tmp/adrian/man manpage.yo or yodl2man --unique --tmp=/tmp/adrian/man manpage.yo and for the html-document: yodl2html --tmp=/tmp/adrian/html htmlpage.yo or yodl2html --unique --tmp=/tmp/adrian/html htmlpage.yo I hope this reply solves the acute problem. If not, expect a new yodl release in a few days. Thanks again for the report, Cheers, -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465575: bisonc++: FTBFS: FlexLexer.h:130: error: expected unqualified-id before numeric constant
Dear Lucas, Thanks for reporting the compilation bug you found in bisonc++. It appears that the problem is caused by a new header setup in flex. When I recreated the file scanner/yylex.cc using `flex lexer' (in the directory ./scanner) the new file yylex.cc compiled without problems. I'll make sure a new yylex.cc is distributed in the next release (or maybe I'll have the build process always recreate yylex.cc). That should solve the problem. For now, this reply should also help those who read Bisonc++'s Bug Reports. Thanks again, -- Frank B. Brokken Center of Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423744: bobcat: FTBFS: i386: error: invalid conversion from 'sfsistat (*)(SMFICTX*, char*)' to 'sfsistat (*)(SMFICTX*, const char*)'
Dear Michael Ablassmeier, you wrote: Package: bobcat Severity: serious Version: 1.14.2-1 Justification: policy violation hi, Lucas has rebuild the archive on i386 and your package Failed to Build from Source with the following error: milter/initialize.cc: In static member function 'static void FBB::Milter::initialize(const std::string, FBB::Milter, size_t, long unsigned int)': milter/initialize.cc:79: error: invalid conversion from 'sfsistat (*)(SMFICTX*, char*)' to 'sfsistat (*)(SMFICTX*, const char*)' milter/initialize.cc:84: error: duplicate case value milter/initialize.cc:66: error: previously used here system - failure of system call (status 256) system - failure of system call (status 256) make: *** [build-stamp] Error 1 the full log can be found here: http://people.debian.org/~lucas/logs/2007/05/13/bobcat_1.14.2-1_sid32.buildlog bye, - michael Thanks for the report. I'll check it out ASAP. Peculiar that the error hasn't come up earlier. Maybe something else changed inducing this compilation error. I'll check it out, anyway. Thanks again, -- Frank B. Brokken Computing Center, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423744: bobcat: FTBFS: i386: error: invalid conversion from 'sfsistat (*)(SMFICTX*, char*)' to 'sfsistat (*)(SMFICTX*, const char*)'
Dear Michael Ablassmeier, you wrote: Lucas has rebuild the archive on i386 and your package Failed to Build from Source with the following error: ... The following can be used to provisionally repair the problem, pending the arrival of the next upgrade: In the file .../milter/milter (line 278), add `const': virtual sfsistat unknown(char const *ptr) same file, line 332, add `const': static sfsistat mUnknown(SMFICTX *ctx, char const *ptr) In the file .../milter/initialize.cc (line 84), change case label from EOM (which was probably a typo) into DATA: #if SMFI_VERSION 3 case DATA: // was: EOM: descr.xxfi_data = mData; AFAICS this works for both libmilter-dev 8.13.8-3 and 8.14.1-2. Kind regards, -- Frank B. Brokken Computing Center, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412003: FTBFS (alpha): DEFINEMACRO: max. 61 arguments supported, not 1
Dear Falk Hueffner, you wrote: Package: yodl Version: 2.10-1 Severity: serious Justification: no longer builds from source Brrr... Sounds ominous. Especially since the 2.04a *did* build on Alpha. I looked at the logs, and did notice some unexpected and possibly serious warnings, which definitely need some attention. One of the changes implemented in version 2.10 is the use of size_t rather than unsigned. It looks as though that's both the cause of the unexpected warnings and the cause of the execution problem. Actually, yodl builds fine, but then its execution shows unexpected behavior. E.g., messages like std.html.yo:100: DEFINEMACRO: max. 61 arguments supported, not 1 are of course remarkable: if 61 is the maximum number, then 1 should not qualify for an error, should it? Now my problem is that as far as I know nobody in my environment uses the Alpha running Debian Linux. I can ask around, maybe one of my colleagues has an Alpha. But on the other hand: maybe you could provide me with a (temporary) account on an Alpha so I can research the problem's cause myself rather than using a real `man-in-the-middle' who I would constantly have to ask to perform the next test. So, thanks for letting me know about this problem. I'll certainly have a look at it as soon as possible. Depending on me gaining access to an Alpha, the repair may either come quickly or not as quickly. Cheers, -- Frank B. Brokken Computing Center, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 signature.asc Description: Digital signature
Bug#391073: bisonc++: empty package on powerpc (known problem with icmake)
Dear Niko Tyni, you wrote: Package: bisonc++ Version: 1.4.0-2 Severity: grave Justification: renders package unusable Hi, the powerpc package of bisonc++ is currently empty. This is a known problem in icmake (#388495) that was recently fixed upstream. The stealth package also suffered from it recently (#388423). :-) Thanks (again) for noting this problem. Fortunately, our torture has come to an end: the cause of the problem was a nasty bug that hid itself somewhere deep down in icmake, and appearing only in extremely seldom conditions (one of them furtunately came to light on the powerpc, as you were quick to note) This afternoon I filed an bugreport against icmake, asking Francesco to install a new upstream release, and we have to wait for that to happen before icmake can do its work properly on the PPC. It's quite likely that my other packages, e.g., yodl and bobcat show the same problem. but if there's a problem the upgrade will solve theirs too. Thanks, of course, for pointing this out. We'll wait closing this bug until the new icmake relase has been accepted by Francesco. [Cc: George Danchev] -- Frank B. Brokken Computing Center, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl:11371/ Key Fingerprint: 8E36 9FC4 1DAA FCDF 1A0D B19F DAC4 BE50 38C6 6170 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
