Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Hi James, > The relevant CMake file addition was sourced[1] from the LLVM codebase, which > is licensed under a variant of the Apache 2.0 license with some exception > clauses added for the LLVM project. This is not yet documented in the source > package. Thanks for pointing this out. It turns out I've failed to update the copyright file for some other included code as well. I'm preparing an upload to fix this now. > To explain my reasoning: On balance I'd prefer opening a serious-severity bug > to prevent migration (that could later be reduced in severity) than to allow > the package transition while being aware of a potential problem. Yes, makes sense! Gr. Matthijs signature.asc Description: PGP signature
Bug#1002913: openttd: FBTFS
Hi Aurelien, Thanks for reporting, I had already seen the failure and am working on a fix, probably next weekend. The issue is caused by the buildds building arch and arch-indep separately, which exposes a problem in the rules file, but I hadn't tested this scenario before upload. Gr. Matthijs signature.asc Description: PGP signature
Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1
Hi Adrian, It took a while longer than anticipated, because of a problem with last month's keyring update, but that has now been resolved, so my uploads have come through. > packages without valid signature are usually silently dropped, > expect that you might have to reupload. Maybe packages with an expired signature are handled differently, since my packages were processed without reupload now. Thanks again for your interest and time! Gr. Matthijs signature.asc Description: PGP signature
Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1
Hi Adrian, > I've prepared an NMU for grfcodec (versioned as 6.0.6-5.1) and uploaded > it to DELAYED/15. Please feel free to tell me if I should cancel it, or > to use the changes for a maintainer upload instead. Thanks for your interest and picking this up! However, I had actually *just* uploaded a new version myself yesterday, but it seems they are not picked up. I suspect this is because my gpg key expired and the validity extension I did a while ago isn't picked up by the keyring yet. As soon as it is, I expect my pending packages will be processed. See also https://salsa.debian.org/openttd-team/grfcodec/-/commits/master/ I suspect it would be best to cancel your upload, and use my version instead. Gr. Matthijs signature.asc Description: PGP signature
Bug#980641: nml: builds with patch
Hi Phil, > Indeed, I've cleaned up my local test and pushed to salsa: > > https://salsa.debian.org/emorrp1/nml/-/commit/27c0aea7cd2670462c24246caf510d7dd8cb99dd Thanks! I think to be really correct, though, I'd have to backup the old files and restore them on clean (or maybe make a copy of the entire regression directory and run tests in there). > > I'll see if upstream maybe wants to do a release with these changes > > included, might be the easiest route... > > With 84 commits to master, I'm not convinced that would qualify for an > unblock. Hm, I hadn't really thought about the freeze. Seems we're still in soft freeze, and this not a very high-profile package, so I don't think a manual unblock is needed yet, but looking at the git log, it seems it's not just a few small fixes, also new features and refactors that might not be appropriate in this stage, so maybe better to backport the fix indeed. I also just noticed that I missed the nml 0.5.3 release in september. Given that's just a few changes, mostly for compatibility, I'm inclined to still include that release in my next upload, even with the freeze. Gr. Matthijs signature.asc Description: PGP signature
Bug#980641: nml: builds with patch
Hi Phil, Mathias, Thanks for your interest in nml and your effort in getting this bug squashed :-) > It would be a shame if openttd got autorm'ed just as the bullseye > freeze starts in earnest. Yeah, I'll make sure that doesn't happen. > Upstream have re-exported the pcx files and I can confirm nml now builds > correctly with these 3 files copied into place before tests. Cool, thanks for confirming. It would be obvious to just backport these changes, but I think the quilt patches used by the Debian patches cannot represent changes to binary files, so it would be a bit more hassle (probably needs some scripting in debian/rules) to include these changes. I'll see if upstream maybe wants to do a release with these changes included, might be the easiest route... Gr. Matthijs signature.asc Description: PGP signature
Bug#954672: openttd-opengfx: FTBFS: Error: (AttributeError) "module 'time' has no attribute 'clock'".
reassign 954672 nml 0.4.5-2 thanks Hi Lucas, > > Error:(AttributeError) "module 'time' has no attribute 'clock'". > > Command: ['/usr/bin/nmlc', '-c', '-p', 'DOS', '-M', > > '--MF=ogfx1_base.grf.dep', '--grf', 'ogfx1_base.grf', 'ogfx1_base.nml'] > > Location: File "/usr/lib/python3/dist-packages/nml/generic.py", line 332, > > in print_progress thanks for reporting. Seems this is really a bug in the nml compiler, which uses time.clock, which was deprecated since Python 3.3 and removed in 3.8. I'm also the maintainer of that package, so I'll make sure to get this fixed. Gr. Matthijs signature.asc Description: PGP signature
Bug#942716: add patch
Hey Matthias, > patch at > http://launchpadlibrarian.net/447871899/nml_0.4.5-1build2_0.4.5-1ubuntu1.diff.gz Thanks for the report and the patch, looks good. I'll prepare an upload with it, probably somewhere next week. Gr. Matthijs signature.asc Description: PGP signature
Bug#942716: add patch
Hey Matthias, > Thanks for the report and the patch, looks good. I'll prepare an upload > with it, probably somewhere next week. I had another look upstream, seems they fixed it by falling back to PILLOW_VERSION unconditionally, but I also noticed PIL.__version__ is actually the recommended replacement (available since pillow 3.4.0, which is < oldstable, so can probably be used unconditionally as well). See https://github.com/OpenTTD/nml/issues/39 for the upstream discussion. Gr. Matthijs signature.asc Description: PGP signature
Bug#913509: openttd FTBFS with ICU 63.1
Hi László, thanks for your investigation and patch. I ended up backporting the upstream patches for the issue, which turned out to be identical to your patch :-) I've just uploaded a version with this patch, as well as a bunch of other pending changes. Gr. Matthijs signature.asc Description: PGP signature
Bug#808508: nml: FTBFS: PIL: Exception: tostring() has been removed. Please call tobytes() instead.
> Exception: tostring() has been removed. Please call tobytes() instead. Thanks for reporting. Turns out upstream has fixed this, so this will get fixed with the next upstream release. Gr. Matthijs signature.asc Description: Digital signature
Bug#808510: openttd-opengfx: FTBFS: PIL: (Exception) "tostring() has been removed. Please call tobytes() instead.".
> Error:(Exception) "tostring() has been removed. Please call tobytes() > instead.". Thanks for reporting. I've informed upstream about this bug, it will probably be fixed for the next upstream release. Gr. Matthijs signature.asc Description: Digital signature
Bug#603752: CVE-2010-4168
Hi folks, thanks for reporting and testing! Just thought I'd mention, I had trouble connecting to multiplay servers *before* I applied this patch, despite the suggestion it 'does not change network compatibility at all'. I've double-checked this with upstream: There's really no way this can affect connecting, since the changed code is only ran at disconnects. I've also checked myself, I could join servers with an unpatched servers normally. Perhaps you had some other transient problem? I'm preparing an upload right now, so this should be fixed soon. Gr. Matthijs signature.asc Description: Digital signature
Bug#595738: openttd: Does not ship sources for .grf files
Package: openttd Version: 1.0.3-2 Severity: serious Justification: Policy 2.2.1 The OpenTTD package does not ship sources for the openttd.grf and openttdw.grf files, which contain resources used for playing the game with the original TTD graphics. The upcoming 1.0.4 upstream release should supply sources and allow rebuilding these grf files. Gr. Matthijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573505: php-doc xml validation error caused by libxml2 / fixed by new upstream version
Hi, (If you're in a hurry, you might want to skip to the end of the mail, since the conclusion is partly unrelated to my in-depth analysis of the problem) it seems PHD is completely innocent for this bug. Upgrading PHD didn't seem to help (though I'm not 100% sure that the upgrading worked, I did throw out the old version entirely). From configure.php, it seems that this error occurs when asking the DOMDocument builtin PHP class to validate, even before PHD is called at all. Instead the manual.xml validation errors reported here seem to be caused by recent changes in libxml2, as suggested in this post: http://www.mail-archive.com/x...@gnome.org/msg07188.html Apparently, there was recently a change in libxml to pass on the current default namespace when expanding entity references. This was a change to fix this bug: https://bugzilla.gnome.org/show_bug.cgi?id=502960 This problem seems to occur when the entity referenced actually contains complete nodes, which don't have an xmlns= of themselves. The workaround suggested in the first post above is to explicitly define a default namespace inside the node(s) generated by the entity. From (quickly) looking at the source, for when the Namespace default prefix was not found error occurs, it seems that the following happens: * A new node (presumably from an entity reference) is created, which gets the current default namespace passed in (presumably from the node that references the entity) (xmlSAX2StartElementNs() in SAX2.c) * The new node checks his default namespace, using the xmlSearchNs function from tree.c. Its documentation says: We don't allow to cross entities boundaries. If you don't declare the namespace within those you will be in troubles !!! A warning is generated to cover this case. * The namespace could not be found, generating the Namespace default prefix was not found error. This seems related to this (old) bug, marked wontfix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174793 This post, from 2002 suggests that the behaviour for xmlSearchNS above is actually a libxml2 bug, but one whose workaround is good practice anyway: http://mail.gnome.org/archives/xslt/2002-January/msg00022.html This post concerns explicit namespace prefixes in entities, which are not declared in the entity itself. However, it is my suspicion that the recent change in libxml is now causing the libxml bug from 2002 to appear for entities that don't declare a default namespace either (previously, the node inside the entity just wouldn't have any namespace associated with it, which was probably not correct either, but did validate, since xmlSAX2StartElementNS() didn't try to check the namespace at all). So it seems the official workaround to this is declaring a default xml namespace inside each entity declaration (I haven't tried this). I don't know enough of the XML (NS) specification to know if this is a real solution or if libxml2 should really be fixed instead... However, it seems that this problem really isn't Debian specific, so upstream should be seeing the same problems. Looking at the latest upstream version of the documentation, it sems that upstream has already applied the workaround. For example, the frontpage.authors entity at: http://svn.php.net/repository/phpdoc/en/trunk/contributors.ent Closer inspection shows that this is fixed in r290424 and r290427: matth...@xanthe:$ svn log -c 290424 -c 290427 http://svn.php.net/repository/phpdoc/en/trunk r290424 | bjori | 2009-11-09 16:58:06 +0100 (Mon, 09 Nov 2009) | 3 lines Add namespace declaration to all free standing elements # See https://bugzilla.gnome.org/show_bug.cgi?id=502960 r290427 | bjori | 2009-11-09 17:04:52 +0100 (Mon, 09 Nov 2009) | 3 lines Adding namespace declaration to newly introduced entities # See https://bugzilla.gnome.org/show_bug.cgi?id=502960 So, it turns out we can easily fix this problem by packaging the latest version of the php documentation. Considering that we're currently shipping a version from 2008, that seems like a good idea anyway. It's not exactly obvious to me how the documentation stuff is organized and how to get a orig tarball from upstream's svn (it seems that the Debian package merges a few directories from SVN?), so I haven't tested this theory. There's probably more things to fix when upgrading, though. Lior, could you take care of this upgrade? If not, I can see if I can prepare something, since I'd like to preserve php-doc (though I don't have too much time, of course :-p). Gr. Matthijs signature.asc Description: Digital signature
Bug#576374: FTBFS: *** [grfmrgc.bin] Error 1 [alpha, armel, hppa, ia64, s390, sparc]
Hi Jonathan, grfcodec is failing to build on all buildds [1], with output like this: Not all, it works on a few architectures. The reason for this is that grfcodec uses upx to do binary compression, which only works on the more common architectures. I've already prepared a new upload that simply skips the compression, I'll upload that today or tomorrow. Gr. Matthijs signature.asc Description: Digital signature
Bug#576374: FTBFS: *** [grfmrgc.bin] Error 1 [alpha, armel, hppa, ia64, s390, sparc]
Hi Jonathan, I don’t know enough to tell whether the compression was important, but if it was, is there a way for a script to ask upx whether it is capable of compressing a given file (or whether it supports ELF files targetted to a given platform)? Nah, it was just a gimmik to make the binaries smaller AFAIK, grfcodec won't work any different without it. So, don't bother :-) Gr. Matthijs signature.asc Description: Digital signature
Bug#570104: openttd: Don't propagate 1.0 development releases to testing
Package: openttd Version: 1.0.0~beta4-1 Severity: serious Due to some issues with my sbuild workflow, 1.0.0~beta4-1 accidentally got uploaded to unstable instead of experimental. However, a final 1.0 release is expected soon, the beta release is already quite stable and usable and having 1.0 in unstable allows for some extra testing of the integration with the upcoming opengfx and opensfx packages, so I won't be forcing a downgrade with epochs etc. Instead, we'll leave 1.0 in unstable until it is final. This bug report is intended to prevent migration to testing. Gr. Matthijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216142856.16597.60371.report...@xanthe.stderr.nl
Bug#509025: splashy: Fixed upstream
Package: splashy Version: 0.3.12-1 Followup-For: Bug #509025 I also ran into this problem (also when upgrading mysql) and took a peek at upstream sources. From the git log, this was fixed upstream in rev dccdf4532edc4edd135bb89d16cd24904dbc8af9 already (which means the recently released 0.3.13 version has this fixed). Gr. Matthijs -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages splashy depends on: ii initramfs-tools0.92n tools for generating an initramfs ii libc6 2.7-16GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-11 direct frame buffer graphics - sha ii libgcc11:4.3.2-1 GCC support library ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libmagic1 4.26-2File type determination library us ii libsplashy10.3.12-1 Library to draw splash screen on b ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. Versions of packages splashy suggests: ii console-common0.7.80 basic infrastructure for text cons ii splashy-themes0.4.1 A complete user-space boot splash pn upstart none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493714: openttd: Network exploitable buffer overrun
Hi, I got a private mail by the maintainer stating: New version should be uploaded this weekend, I'll mail the release team with details when that happens. I'm having a bit of a problem with this upload, since my regular sponsor seems to be away. I had asked a DD to upload it last weekend, but hasn't had time for it yet. I've put the new version up at mentors.debian.net and asked for a sponsor on debian-mentors@ as well. Release team has also been mailed about possibly including this version in testing. Gr. Matthijs signature.asc Description: Digital signature
