Processing of publib_0.40-2_i386.changes
publib_0.40-2_i386.changes uploaded successfully to ftp-master.debian.org along with the files: publib_0.40-2.dsc publib_0.40-2.debian.tar.xz publib-dev_0.40-2_i386.deb Greetings, Your Debian queue daemon (running on host coccia.debian.org)
Processing of publib_0.40-2_i386.changes
/publib_0.40-2_i386.changes is already present on target host: publib-dev_0.40-2_i386.deb Either you already uploaded it, or someone else came first. Job publib_0.40-2_i386.changes removed. Greetings, Your Debian queue daemon (running on host franck.debian.org)
publib_0.40-2_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 19 Jan 2016 23:18:43 +0100 Source: publib Binary: publib-dev Architecture: source i386 Version: 0.40-2 Distribution: unstable Urgency: high Maintainer: Debian QA Group Changed-By: Robert Luberda Description: publib-dev - library of miscellaneous C functions Closes: 790273 Changes: publib (0.40-2) unstable; urgency=high . * QA upload: - maintainer set to Debian QA Group; - git packaging moved to the collab-maint project. * Introduced the following patches: - 001-Remove-strndup.patch to fix FTBFS on current gcc and glibc by removing declaration of strndup() function together with its implementation and man page (closes: #790273); - 0002-Fix-undefined-behavior-warning.patch to fix an off-by-one bug in base64 decoder resulting in an undefined behavior warning given by gcc-5; - 0003-Remove-Makefile-at-distclean.patch to make sure the generated Makefile is dropped, so that sequential builds do not fail; - 0004-Fix-spelling-errors-in-manpages.patch to fix spelling typos in `occurrence' and `occurred' words, noticed by lintian. in `occurrence' and `occurred' words, noticed by lintian; - 0005-Pass-LDFLAGS-to-test-programs.patch to use $(LDFLAGS) while linking test programs. * Mark the binary package as `Multi-Arch: same'. * Bump Standards-Version to 3.9.6 (no other changes needed). Checksums-Sha1: 6869637e7ca8e807e29680c8a17d1bde08b9fe31 1772 publib_0.40-2.dsc cc2c6c119490fa0a7d3e8e050e4bccbff73d78ad 8140 publib_0.40-2.debian.tar.xz 3424010487b726175385c62dc300e20f9715fba1 154148 publib-dev_0.40-2_i386.deb Checksums-Sha256: 6a1902e360fd64a07a241d0d74cba89c1a573cbff61c8a3b34f357400f1ea0d4 1772 publib_0.40-2.dsc 659d335cfecd0496bf019959740bc20837351b5f808aaf9bb9332aa9e8e47a69 8140 publib_0.40-2.debian.tar.xz e32d90f5e6915cd0f1016ecc213c186cd822c59bde84ddecdab9c0ee66e85ba4 154148 publib-dev_0.40-2_i386.deb Files: 9ff704916b686bd6acdc9c54abed5fd5 1772 libdevel optional publib_0.40-2.dsc fd5598770a8847057b9976f0787d739b 8140 libdevel optional publib_0.40-2.debian.tar.xz 7ddf34ea9b8e4626174630dd9d2eaa8e 154148 libdevel optional publib-dev_0.40-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWnrdrAAoJEGMd51U76K/UJQ0QAJHaKs0Yd5neCbovUMa4JMYT ltITXIu69eLZ+OYGPSFUnSpwYRcWAMnH1LC7BP7tqPZDu3trhjMqqRXKtJ0dE58x QA6qeRVIglYdLc/8pQqaPBYqCN6cJu/Siq5o+qR7dcWh2nve7qkgKEGWVDEdf4qr kj/8/WWCQxERDi1iFBX9XqyIp+FZ/6sHTOhh0bmzcik2VG+9Osp1RKvSYUiRmIFc EWnY3YaDhSuonVmv/yJhXDV2JFr2zHPAitLvEhrW7U8VOY7Yhh4qwCvGWv3VwW5b GYllhCBj1YKr0pef6kCuBl60q2e1C6UaHnYSM9r61brIqQRb1m3PU5DdvvQ59gtY Td2apiNJgr9+XvIepvTPptpQcZpcgsTwN+av+/Cdb1l4Eo+soOi8j96YDC8ZuuOn 2TSg1Nx1UEt93rxMGo2SmxNGfeKDBoORwlM1YQcvOVgo7jzUNsKgnFx5dDknvvYR wzJGIo9xf+H8DJvL/8a1OiEksEfk0ZEQLNe/ChzOCTlsrRfIO7z+PzPkxHGNl9yx p202ZPTubhvuH+/H4y6WAN/VVJKW7cKF1OIR+v1X3Zq/CgXkNIVLXhcM+0LPo6ww vUMntBGBat1KIfUhYpJ3HRDemriOQRm0uHkrPPqdWwnebj+L3dbWYmeBZu9+qqUS ZMww0h7XenCZXvn6O6ix =9K4K -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of cfflib_2.0.5-2_source.changes
cfflib_2.0.5-2_source.changes uploaded successfully to localhost along with the files: cfflib_2.0.5-2.dsc cfflib_2.0.5-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org)
cfflib_2.0.5-2_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 20 Jan 2016 19:18:17 + Source: cfflib Binary: python-cfflib Architecture: source Version: 2.0.5-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Mattia Rizzolo Description: python-cfflib - Multi-modal connectome and metadata management and integration Closes: 807760 Changes: cfflib (2.0.5-2) unstable; urgency=medium . * QA upload. * Orphan the package. Closes: #807760 * Run wrap-and-sort Checksums-Sha1: 819098e1c296a290e130d78040cfe5c74e4f2f6d 1890 cfflib_2.0.5-2.dsc edbc16f60b445748e420025b539dba004f2717d9 3536 cfflib_2.0.5-2.debian.tar.xz Checksums-Sha256: 4b397696f961b53fbad897e6fe41e35c490d9489b4951fbf786300d5d2ad2403 1890 cfflib_2.0.5-2.dsc 5d3de7ae40bcd0dc12cc0941e1763c5120be81a0acd37984f5cbe7c5d19027e8 3536 cfflib_2.0.5-2.debian.tar.xz Files: b7ee051389746dff44ff9f301d6f2304 1890 python extra cfflib_2.0.5-2.dsc d06380fa8eafd6ef327a08ed394c3b24 3536 python extra cfflib_2.0.5-2.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWn92WAAoJEEsEP825REVADX4P/2zAvNqYWMi8PjnIOD9fvCVr 5NfESyYBPPjkh+Wk7O339eQqsScIwAidaDjB2zBknciuET3r0LS92s+4BXpzt+QE Wl3gaNyZZ5d5V9GFgjuCfqdI0zgrdGvt80AOdr//zdvI8n/dXjyzn9IwwUwarZXL CiA3w/HIOPc/cnCkCFcdBjQL0mOpj/4rQgFuKIzBlzsMAmxI+HoPc+Kaz/CLx+GY qwh/P/1t5kCRePvZyNpyG55UuGPgl67DW5Dccpzte8ciOdyeQYytBUJqVHBELTSN H3iWhiPsdVicwI62YVPRN4Ld1vy/lhSJglhmTsxcCEUcJIzEcXAVEvTA5K2wvTB3 8B2oBy+MATZ7OrU1ZylMSlwk2jqQI9Fx7zeKVX2Yf0yKUg9N9Zul5rpozkcgH/gv n2JjX/qTtgMV+x/YM6umr3AquDnpqgAVA+CBjqLUy0QkDF6O6N5m8lB7KwrWXVMO Ko72IBZixYgMSLQVj8tFn6+s7NlIlYbikpo3tfeaeuiiqAgLmxKbzjC/m2SggvDU wZZHOqdABcW2zWoxJqnqsj5Qn67Jp8RAL0sBR11V72rHVHbWcGBz1CU6VaPX6+WC uKWiczC2k92OfNQ32P/PdpvH6VI+T6ve7U9yTOM2F/lhTW5rdpHNNsFjhGI6XRA/ 6bJAafdX5H/KQlVfZQWP =BK/o -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of simpletal_4.1-9_source.changes
simpletal_4.1-9_source.changes uploaded successfully to localhost along with the files: simpletal_4.1-9.dsc simpletal_4.1-9.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org)
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 12:57, Michal Suchanek escribió: Unless the user requests two bootloaders that are incompatible the medium can be created. Ignoring bootloaders is not a good idea. If the user requested something that is not possible the build should report an error and stop. Yeah, that it's hard to implement from the perspective of a single bootloader script. So I decided not to implement it. You could add an additional script or function named: check_compatible_bootable_pairs (as you propose) but then you need to maintain that fictional database each time a new bootloader gets in. That's why I decide to avoid it using it. What it's straight-forward to implement is one of the only-secondary bootloaders finding themselves as a primary bootloader and outputting a warning message. But, I'm not sure what to put there as a warning. Any suggestion? Unsupported bootloader combination or whatever. It should not be a warning however. The script should avoid making unbootable medium. Thanks Michal I have implemented: Check_Primary_Bootloader_Role, Check_Secondary_Bootloader_Role functions for avoiding non supported bootloader combinations on: https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased So that part is solved. (I'll send a proper rebased set of patches in the future). adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
simpletal_4.1-9_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 21 Jan 2016 00:46:58 + Source: simpletal Binary: python-simpletal Architecture: source Version: 4.1-9 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Mattia Rizzolo Description: python-simpletal - Simple TAL, TALES and METAL implementation Closes: 808126 Changes: simpletal (4.1-9) unstable; urgency=medium . * QA upload. * debian/control: + Orphan the package. Closes: #808126 + Move the git repository to collab-maint. Checksums-Sha1: e94cfb2d3ce39df90e2ec8fb4df520384517ccb5 1873 simpletal_4.1-9.dsc 676d292a486bf92dc6c8aa4fd3d1e0cd6a295fdd 3440 simpletal_4.1-9.debian.tar.xz Checksums-Sha256: a7ca7e74c220e61afc0eef5fe830aa0d8c25629339a417a8397eb84586250ecb 1873 simpletal_4.1-9.dsc 38c078009beee25ff76870588b0e4ffb88eb423694a876dc121bbb6f05632404 3440 simpletal_4.1-9.debian.tar.xz Files: 2975263a60218ef1ac0df3f962af1181 1873 python optional simpletal_4.1-9.dsc 2a286e39e95ab753d65185096667f863 3440 python optional simpletal_4.1-9.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWoCtXAAoJEEsEP825REVAeAgQAMnAzzmGtkVbyk5Cdg0ez8KB AFDu30uUewDIZYIRNbv4Tp3pDuQHX1dUk3vWC5+lH7keyB3NMttIrjWuSVwQeGZ1 s3QC3B67sSYQPduXa9mEfEjmqvf8H0Vnijtblq7FvT7IiZSBixaQTEeQhh+LxwdJ 0i19jraBYDfm/0e2QwxU3vvWaqJIGMsOt1vmxh/ttwEJUIK/pk27N4q3LL/9QQ5f GRl/JNiznRoncjJVbpK+Aw/YUK7I3wKYJXsBj9B/kx5nPR7EZJUHE5NOLezlpOro mbIs1NA6xMGP7IMCH+2Y4AYzXBopxqbK+DjNh+eQoBcmR+4VFWQRezsNpNUidpCo PUTQ62l8dsD/T2/ZFLH9Ua2qFz90GFvxCYfArE0snopL7VBxS8BFfZa5Va6J8GF4 dVHLIMNCh3eqbEdcuNUKBuVB25FDn45XKEt4a1Ikag0trHbh0OZhTe+jBx8/a2As BNKXvM4vh8w40NQnRBsH2GW/g3DtUy0Vuggq81I3ZuGxsaZCaFxK7Kzj/XKsgs9k 9Hl78QWdRry2xuXjwHQEBM5cZekqXBsDDZcHAP2SZpI2g1VhVKey2A5ZollGeGND A7rtcxQbDFBGTiiSL3d6kPxMXLt4cs88ogIXaeZEYb6GgtvhHUnWDBDZBpRrmDYK 8iLk/yWimUn0F9ghhtVc =5PFX -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 14:00, Thomas Schmitt escribió: So any bootloader is made primary by leaving out -eltorito-alt-boot. There is no "primary" or "secondary" on the level of boot images and loaders. (Of course you may call them this way in your project.) There are first, second, third ... El Torito boot images or MBR, GPT, APM partition entries. The sequence is just needed because not all can be first in the list. The boot firmware inspects the medium for its known lures, picks a tasty one, and follows it to the boot loader or kernel. So, yes, I'm the one who invented the term primary for live-build. Actually, it was not meant for alt El Torito boot entries (or non first entries as you clarify). The first idea was to add both syslinux and grub-pc in the same image. Grub-pc would be the one installed to be boot but syslinux files would be there for Multi-USB tools to know how to understand the iso and put it into an USB. The Grub-pc bits were thought in first place for Super Grub2 Disk (which it is Grub2 cfg files mainly). (Now that I think of the current 'check primary bootloader role' functions unable me to perform that Super Grub2 Disk Debian Live that included the Syslinux bits too. Anyways I'll find a workaround for that in the future. Not a priority right now.) Now primary means: "First lure" and secondary means "Second lure" by your definition. Currently there's no way to stop you from requesting: --bootloaders="syslinux,grub-efi,syslinux-efi" Given the way that both grub-efi and syslinux-efi use: /efi/boot/bootia32.efi and /efi/boot/bootx64.efi the last one to be run would overwrite the first one efi files. You can probably use only one legacy bootloader but syslinux-efi and grub-efi use different files so it should be possible to install both. I am not sure how selecting one or the other would work, though. You can offer several EL Torito boot images for BIOS, indeed. It will depend on your BIOS what it does in this case. Interesting. There can be only one MBR, though. So you would have to hop by MBR x86 code to a standalone program which chooses among the BIOS suitable El Torito boot images. With EFI it makes few sense to offer more than one El Torito boot image or EFI System Partition. UEFI 2.4 rather prescribes to handle all alternatives inside the FAT filesystem. The firmware will start the \EFI\BOOT\BOOT*.EFI binary which it deems suitable for its processor type. This binary is quite free in its further proceedings. So... How would you go about for a: --bootloaders="syslinux,grub-efi,syslinux-efi" to make sense if, as I have stated earlier (although I might have missed something there) they would overwrite their /efi/boot/boot*efi files ? adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 13:38, Thomas Schmitt escribió: Hi, adrian15 wrote: * What is it a secondary bootloader? It's what happens when you request mkisofs that your bootloader to be boot in second place or as a second partition. I don't know how it actually works. An ISO may contain several lures for boot firmware. If it is booted from CD/DVD/BD, then the lures are in the El Torito boot catalog. In case of debian-cd it contains two entries which point to boot images. One entry is marked as suitable for BIOS and one marked as suitable for EFI. The boot firmware then picks what it deems right and starts it, or offers it to the user for starting. Interesting. If the ISO is presented on USB stick or alike, then BIOS looks for the magic number of an MBR and if so, mindlessly executes the x86 machine code that starts at byte 0 of the ISO. This code then hops onto the same boot code that is advertised by El Torito (because xorriso or isohybrid patched its block address into the MBR code). Aha. EFI looks on USB stick for an MBR partition of type 0xef or for a single partition of type 0xee. In the latter case it assumes the presence of GPT and looks for a GPT partition with type GUID 28732ac11ff8d211ba4b00a0c93ec93b. Inside the found partition it expects a FAT filesystem and particular binaries for each supported processor archictecture. E.g. \EFI\BOOT\BOOTX64.EFI The El Torito EFI boot image has the same content specification as the EFI System Partition. Therefore both boot paths can share the same data. My cheat sheet is at http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt Great! I want to document the different ways of how BIOS boot, UEFI boot and Secure Boot work and that might be helpful. - So, I guess the -eltorito-alt-boot does the magic but I'm not sure. Maybe someone else can explain it better than me. -eltorito-alt-boot is simply a separator between the options of El Torito boot images. I assume your first boot image is announced by -b and gets the usual options -no-emul-boot -boot-load-size 4 -boot-info-table Before the announcement of the EFI boot image begins, option -eltorito-alt-boot is needed to protect your -b and its helpers from being overwritten. That it's quite interesting. Do you mean if you have: xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2 you could just re-arrange them as: xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1 and it would be fine? So that it's not strictly necessary for syslinux or grub-pc to be a primary bootloader (or first lure in your definition) ? That would also simplify my contributed code to live-build by not needing to handle if a bootloader is primary/secondary or not. So in grub-efi we just add to the xorriso options: -eltorito-alt-boot \ -e boot/grub/efi.img \ -no-emul-boot \ -isohybrid-gpt-basdat \ -isohybrid-apm-hfsplus Here a second boot image gets announced by -e and the next three options apply to it. Ok. And in syslinux-efi (currently) we add: -eltorito-alt-boot \ --efi-boot boot/efi.img \ Option --efi-boot is a shortcut for -eltorito-alt-boot -e ... -no-emul-boot -eltorito-alt-boot normally used by grub-mkrescue. The SYSLINUX community prefers -e. Knowing that I will probably expand that so that the syslinux-efi and grub-efi options are more similar and we can compare them in a more easy manner. -append_partition 2 0x01 \ binary/boot/efi.img I wonder what EFI firmware would hop on an MBR partition of type 0x01. An EFI System Partition in MBR should have type 0xef to be recognized. That needs to be asked to Hertzog. I just tried to use his original work. It looks like this variant will not get GPT. That's fully compliant to UEFI 2.4. Just the MBR partition type should be 0xef. (Does "syslinux-efi" mean that you can boot from ISO via EFI and SYSLINUX stuff to an operating system ? That would be new.) I don't know what you mean by 'SYLINUX stuff to an operating system. I understand that Hertzog work let's you boot into the cd booting by the means of EFI. The EFI image needs to include the configuration file (as opossed to the grub-efi implementation which only stores its configuration file in the CD/DVD/BD media). --- Above options do not produce HFS+ with blessing. Option -isohybrid-apm-hfsplus causes an Apple Partition Map entry which points to the data content of boot/grub/efi.img. If I'm not mistaken Hertzog removed that option because you suggested to remove it on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66 Are you requesting to put this option back ? There are two ways known to me how to get a boot path via HFS+: Fedora Live CD as of Matthew Garrett or grub-mkrescue as of Vladimir Serbinenko. The debian-cd method is one of them? Or is it not?
libexplain is marked for autoremoval from testing
libexplain 1.4.D001-2 is marked for autoremoval from testing on 2016-02-05 It is affected by these RC bugs: 808854: libexplain: FTBFS: FAILED test of dup2 EBADF
snd is marked for autoremoval from testing
snd 11.7-5 is marked for autoremoval from testing on 2016-02-10 It is affected by these RC bugs: 810861: snd-gtk-pulse: Cannot locate libgsl.so.0
Bug#812168: skyeye: FTBFS using clang instead of gcc
Package: skyeye
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Detected this kind of error:
http://clang.debian.net/status.php?version=3.6.0&key=FUNCTION_RETURNS_VALUE
Full build log is available here:
http://clang.debian.net/logs/2015-03-25/skyeye_1.2.5-4_unstable_clang.log
I have attached a patch to fix this error.
Regards,
--Arthur Marble
-- System Information:
Debian Release: sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE="en_US.UTF-8"
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.6.2-3 (based on LLVM 3.6.2)
--- a/arch/arm/common/armsupp.c
+++ b/arch/arm/common/armsupp.c
@@ -693,7 +693,7 @@
//chy 2004-07-19 should fix in the future
//printf("SKYEYE ARMul_MRC,NOT ALLOWed UndefInstr CPnum is %x, instr %x\n",CPNum, instr);
ARMul_UndefInstr (state, instr);
- return;
+ return 0;
}
cpab = (state->MRC[CPNum]) (state, ARMul_FIRST, instr, &result);
--- a/arch/bfin/mach/bf533_io.c
+++ b/arch/bfin/mach/bf533_io.c
@@ -864,7 +864,7 @@
default:
IO_ERR;
}
- return;
+ return 0;
}
static bu32
@@ -883,7 +883,7 @@
default:
IO_ERR;
}
- return;
+ return 0;
}
static void
--- a/arch/bfin/mach/bf537_io.c
+++ b/arch/bfin/mach/bf537_io.c
@@ -870,7 +870,7 @@
default:
IO_ERR;
}
- return;
+ return 0;
}
static bu32
@@ -889,7 +889,7 @@
default:
IO_ERR;
}
- return;
+ return 0;
}
static void
--- a/arch/coldfire/common/cf_arch_interface.c
+++ b/arch/coldfire/common/cf_arch_interface.c
@@ -41,7 +41,7 @@
#include "skyeye_config.h"
char Run_Exit = 0;
-SKYEYE_DBGR_DEFAULT_CHANNEL(run);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(run); // Unused macro? */
static int stop_now = 0;
--- a/arch/coldfire/common/exception.c
+++ b/arch/coldfire/common/exception.c
@@ -10,7 +10,7 @@
#include "coldfire.h"
-SKYEYE_DBGR_DEFAULT_CHANNEL(exception);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(exception); // Unused macro? */
static short exception_pending = 0;
static unsigned int (*iack_func[8])(unsigned int interrupt_level)
--- a/arch/coldfire/common/i.c
+++ b/arch/coldfire/common/i.c
@@ -10,7 +10,7 @@
#include "coldfire.h"
-SKYEYE_DBGR_DEFAULT_CHANNEL(i);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(i); // Unused Macro? */
#define MALLOC_STEP 16
struct _Instruction *Instruction = NULL;
--- a/arch/coldfire/common/handlers.c
+++ b/arch/coldfire/common/handlers.c
@@ -11,7 +11,7 @@
#include "coldfire.h"
-SKYEYE_DBGR_DEFAULT_CHANNEL(handlers);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(handlers); // Unused macro? */
void SR_Set(short Instr, int Source, int Destination, int Result)
--- a/arch/coldfire/common/ram.c
+++ b/arch/coldfire/common/ram.c
@@ -15,7 +15,7 @@
/*#define SKYEYE_DBGR_OFF*/
#include "coldfire.h"
-SKYEYE_DBGR_DEFAULT_CHANNEL(ram);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(ram); // Unused macro? */
void ram_init(void);
static void ram_setup(struct _memory_segment *s);
--- a/arch/coldfire/common/memory.c
+++ b/arch/coldfire/common/memory.c
@@ -31,7 +31,7 @@
/* memory core copy with values used when reset */
static struct _memory_core memory_core_reset_values;
-TRACER_DEFAULT_CHANNEL(memory);
+TRACER_DEFAULT_CHANNEL(char memory);
static struct _memory_module *memory_module = NULL;
--- a/arch/coldfire/instruction/i_div.c
+++ b/arch/coldfire/instruction/i_div.c
@@ -63,7 +63,7 @@
int DIVSTime[8]={18, 20, 20, 20, 20, -1, -1, -1};
-SKYEYE_DBGR_DEFAULT_CHANNEL(i_div);
+/* SKYEYE_DBGR_DEFAULT_CHANNEL(i_div); // Unused macro? */
#define DIV_W_REGISTER(word) (((word)&0x0e00) >> 9)
--- a/arch/mips/common/dcache.c
+++ b/arch/mips/common/dcache.c
@@ -242,7 +242,8 @@
int i;
// A direct memory access.
-return mips_mem_read(pa, x, size);
+mips_mem_read(pa, x, size);
+ return;
}
/* Store data to the virtual address (va). The address translation has already
* been performed and the physical address is (pa). The coherency algorithm to
@@ -336,5 +337,6 @@
store(MIPS_State* mstate, UInt32 data, VA va, PA pa, int size) {
UInt32 addr=bits(pa, 31, 0);
UInt32 x = data;
-return mips_mem_write(pa, &data, size);
+mips_mem_write(pa, &data, size);
+ return;
}
--- a/utils/debugger/ppc_regdefs.c
+++ b/utils/debugger/ppc_regdefs.c
@@ -96,7 +96,7 @@
case 69:
//XER = v;
gCPU.xer = v;
-return;
+break;
case 70:
//FPSCR = v;
gCPU.fpscr = v;
Bug#809882: marked as done (abiword: FTBFS with libpng16)
Your message dated Thu, 21 Jan 2016 07:47:55 +0100 with message-id <1453358875.3930.4.ca...@debian.org> and subject line Re: fix is in git, not uploaded has caused the Debian Bug report #809882, regarding abiword: FTBFS with libpng16 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 809882: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809882 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: abiword Severity: important User: lib...@packages.debian.org Usertags: libpng16-transition Dear abiword maintainer, Currently we are preparing the transistion of libpng1.2 to libpng1.6. The transistion bug is #650601. A rebuilt of all packages depending on libpng-dev and libpng12-dev has been done. The result with buildlogs can be found here: https://libpng.sviech.de/ abiword FTBFS during this rebuild. The buildlog is available at https://libpng.sviech.de/abiword.build The Titanpad at https://titanpad.com/libpng16-transistion might give you clues about what went wrong as well as some recipes/pointers how to fix them. Please feel free to amend the information on the pad as you might see fit. A plain-text, non java-script version is here: https://titanpad.com/ep/pad/export/libpng16-transistion/latest Please try to make abiword compatible with libpng16 and then make sure to B-D on libpng-dev only, if the fix makes it possible to compile it against libdev12 and libdev16. If you can only make in a non-backward compatible way, please B-D on libpng16-dev. This bug will become RC as soon as the transistion starts. Best regards, -- tobi --- End Message --- --- Begin Message --- On Tue, 12 Jan 2016 04:51:11 +0100 Adam Borowski wrote: > Hi! > I've prepared a fix, however, I've been unable to test it as there's a > massive chain of dependencies that need updating; some can be simply > recompiled but some FTBFS on their own. > > It's pushed to the collab-maint git. > > -- > A tit a day keeps the vet away. > > Yepp, it builds fine now.--- End Message ---
Processed: Re: fix is in git, not uploaded
Processing control commands:
> reopen -1
Bug #809882 {Done: Tobias Frost } [src:abiword] abiword: FTBFS
with libpng16
Bug reopened
Ignoring request to alter fixed versions of bug #809882 to the same values
previously set
--
809882: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809882
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#809882: fix is in git, not uploaded
Control: reopen -1 closed by accident as not yet uploaded.
