Bug#477694: FTBFS: ext/threads/t/stress_re.t fails sporadically on sparc
On Thu, Apr 24, 2008 at 05:49:16PM +0200, Florian Weimer wrote: > Package: perl > Version: 5.8.8-7etch1 > Severity: serious > > To my knowledge, this bug only occurs on sparc in an etch chroot, > possibly only when running newer kernels. I cannot reproduce it with > the sid chroot on sperger. > The point at which the Perl process is terminated (IOW, number of lines > printed) varies from invocation to invocation. > > spontini, the sparc security build daemon, is similarly affected: > building perl sporadically fails as well, and it remains to be seen if > we can get it it to pass. Yeah, I can reproduce it on sperger/etch. It doesn't need the full Perl build tree, just running the system perl on ext/threads/t/stress_re.t (attached for convenience) shows the problem. It doesn't show up on my own sparc uniprocessor host, which has the Etch kernel, so it's either specific to new kernels or SMP hosts. As it works on sperger in the sid chroot, it would seem that newer versions of glibc work better. Looking at the glibc changelog, the threads implementation changed in 2.4.1 from LinuxThreads to NPTL, which sounds related. I don't really claim to know anything about their differences, though. CC'ing the debian-sparc list. help would be welcome. Bisecting with other kernel versions (sperger has 2.6.22.18sperger) might tell us something. Hm, one more data point: this was very easy to reproduce last night when sperger was empty, but now that there's some load from other people, the test completes almost all of the time. That would seem quite natural for a threading bug on an SMP host. Cheers, -- Niko Tyni [EMAIL PROTECTED] stress_re.t Description: Troff document
Processed: Re: [Resolvconf-devel] Bug#477752: resolvconf: Don't reinstall init script on upgrades
Processing commands for [EMAIL PROTECTED]: > tags 477752 confirmed pending Bug#477752: resolvconf: Don't reinstall init script on upgrades There were no tags set. Tags added: confirmed, pending > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477752: [Resolvconf-devel] Bug#477752: resolvconf: Don't reinstall init script on upgrades
tags 477752 confirmed pending stop On Fri, 2008-04-25 at 00:17 +0200, Jörg Sommer wrote: > Policy 10.7.3 says you must preserve user changes during upgrades, but on > upgrade (or reinstall) the init script level gets changed. I've a > different ordering of the services due to insserv and if you reset the > level on every upgrade, you destroy my settings. Thanks for the report. This will be fixed in the next release. To my fellow resolvconf developers: When I run lintian I get the following warning: W: resolvconf: manpage-has-errors-from-man usr/share/man/man8/resolvconf.8.gz 67: warning: `EX' not defined What is the best way to fix this? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465635: latex-cjk-chinese-arphic: FTBFS: debhelper errors
Hi Lucas! I'm still stuck when rebuilding the package. The reason is not your patch, but some changes in kpathsea, a part of TeX. This bug doesn't cause an FTBFS, but makes the packages fail to install properly. So I'm trying to solve this issue before I can upload a new version, with your patch included. So far my information notice. :-) Regards -- Danai SAE-HAN (韓達耐) 題目:《閑居初夏午睡起》 作者:楊萬里（１１２７－１２０６） 梅子留酸軟齒牙，芭蕉分綠與窗紗。 日長睡起無情思，閑看兒童捉柳花。 signature.asc Description: OpenPGP digital signature
Bug#477270: marked as done (linux-2.6: slab-fix-bootstrap-on-memoryless-node.patch causes memory corruption)
Your message dated Fri, 25 Apr 2008 07:52:16 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#477270: fixed in linux-2.6.24 2.6.24-6~etchnhalf.1
has caused the Debian Bug report #477270,
regarding linux-2.6: slab-fix-bootstrap-on-memoryless-node.patch causes memory
corruption
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 [EMAIL PROTECTED]
immediately.)
--
477270: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477270
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: linux-2.6
Version: 2.6.24-5~etchnhalf.1
Severity: grave
Tags: patch
Justification: causes non-serious data loss
slab-fix-bootstrap-on-memoryless-node.patch (commit
556a169dab38b5100df6f4a45b6553db94c1) in the etchnhalf kernel
introduces a condition that causes memory corruption in UML (as I have
experienced), ES7000 nodes (as Daniel Yeisley mention in the fix I will
mention in a moment), and possibly other scenarios. In my case,
"openssl speed rsa1024" returns this:
Doing 1024 bit private rsa's for 10s: 2249 1024 bit private RSA's in 3.91s
Doing 1024 bit public rsa's for 10s: RSA verify failure
12706:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is
not 01:rsa_pk1.c:100:
12706:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check
failed:rsa_eay.c:708:
1 1024 bit public RSA's in 1.98s
in SKAS4 immediately, or in SKAS3 after a random amount of uptime.
Though I have yet to notice any "real" data loss as the result of
corruption.
Commit ec1f5eeeb5a79a0d48036de649a3498da42db565 (attached) fixes this.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--- Begin Message ---
slab: fix cache_cache bootstrap in kmem_cache_init()
Commit 556a169dab38b5100df6f4a45b6553db94c1 ("slab: fix bootstrap on
memoryless node") introduced bootstrap-time cache_cache list3s for all nodes
but forgot that initkmem_list3 needs to be accessed by [somevalue + node]. This
patch fixes list_add() corruption in mm/slab.c seen on the ES7000.
Cc: Mel Gorman <[EMAIL PROTECTED]>
Cc: Olaf Hering <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Dan Yeisley <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
diff --git a/mm/slab.c b/mm/slab.c
index bb4070e..04b308c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1481,7 +1481,7 @@ void __init kmem_cache_init(void)
list_add(&cache_cache.next, &cache_chain);
cache_cache.colour_off = cache_line_size();
cache_cache.array[smp_processor_id()] = &initarray_cache.cache;
- cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE];
+ cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE + node];
/*
* struct kmem_cache size depends on nr_node_ids, which
@@ -1602,7 +1602,7 @@ void __init kmem_cache_init(void)
int nid;
for_each_online_node(nid) {
- init_list(&cache_cache, &initkmem_list3[CACHE_CACHE],
nid);
+ init_list(&cache_cache, &initkmem_list3[CACHE_CACHE +
nid], nid);
init_list(malloc_sizes[INDEX_AC].cs_cachep,
&initkmem_list3[SIZE_AC + nid], nid);
--- End Message ---
--- End Message ---
--- Begin Message ---
Source: linux-2.6.24
Source-Version: 2.6.24-6~etchnhalf.1
We believe that the bug you reported is fixed in the latest version of
linux-2.6.24, which is due to be installed in the Debian FTP archive:
linux-2.6.24_2.6.24-6~etchnhalf.1.diff.gz
to pool/main/l/linux-2.6.24/linux-2.6.24_2.6.24-6~etchnhalf.1.diff.gz
linux-2.6.24_2.6.24-6~etchnhalf.1.dsc
to pool/main/l/linux-2.6.24/linux-2.6.24_2.6.24-6~etchnhalf.1.dsc
linux-doc-2.6.24_2.6.24-6~etchnhalf.1_all.deb
to pool/main/l/linux-2.6.24/linux-doc-2.6.24_2.6.24-6~etchnhalf.1_all.deb
linux-headers-2.6.24-etchnhalf.1-all-hppa_2.6.24-6~etchnhalf.1_hppa.deb
to
pool/main/l/linux-2.6.24/linux-headers-2.6.24-etchnhalf.1-all-hppa_2.6.24-6~etchnhalf.1_hppa.deb
linux-headers-2.6.24-etchnhalf.1-all_2.6.24-6~etchnhalf.1_hppa.deb
to
pool/main/l/linux-2.6.24/linux-headers-2.6.24-etchnhalf.1-all_2.6.24-6~etchnhalf.1_hppa.deb
linux-headers-2.6.24-etchnhalf.1-common_2.6.24-6~etchnhalf.1_hppa.deb
to
pool/main/l/linux-2.6.24/linux-headers-2.6.24-etchnhalf.1-common_2.6.24-6~etchnhalf.1_hppa.deb
linux-headers-2.6.24-etchnhalf.1-parisc-smp_2.6.
Bug#474869: kchmviewer: diff for NMU version 3.1-1.1
Luk Claes wrote: > José Luis Tallón wrote: > >>> The attached file is the diff for my kchmviewer 3.1-1.1 NMU. The associated >>> changelog entry is: >>> >>> kchmviewer (3.1-1.1) unstable; urgency=medium >>> >>>* Non-maintainer upload. >>>* Bump Standards-Version to 3.7.3. >>>* Correct typographical error in package description (Gnome -> GNOME) >>>* Fix FTBFS with GCC 4.3 (Closes: #474869) >>>* Correct debian/watch file to report upstream version correctly >>> (Closes: #449696) >>> >>> >> Well, thanks, you just rendered my Maintainer Upload useless. >> It has been ready, and sent to an sponsor, for over two weeks now. >> > > It would have been better to mention this in the bug report instead of > just tagging it pending... > > >> I know we are already at 0-day NMU, but this was impolite at the very least. >> > > I don't think that helping by doing an NMU is impolite, though this > might just be a misunderstanding of your use of the pending tag... > Thanks, Luk. I *do* appreciate NMUs (I have just thanked Christian Perrier for his), but even when not required I creatinly prefer to be notified and be able to answer. Unfortunately, it usually takes me a lot to find new sponsors (and my usual sponsors are all overloaded). Hence, I do not get that many opportunities to do it "right". I have been yelling at -mentors for some sponsored uploads for about two months, and almost nobody responded --- I did get up-imapproxy uploaded, however. Cheers, J.L.
Processed: Re: gpg not installed, fails [i386 on amd64]
Processing commands for [EMAIL PROTECTED]: > retitle 477648 gpg not installed, fails Bug#477648: gpg not installed, fails [i386 on amd64] Changed Bug title to `gpg not installed, fails' from `gpg not installed, fails [i386 on amd64]'. > severity 477648 grave Bug#477648: gpg not installed, fails Severity set to `grave' from `normal' > found 477648 1.0.8 Bug#477648: gpg not installed, fails Bug marked as found in version 1.0.8. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477765: fails to install sid chroot: gnupg does not get installed
Also see #477648. Might be related. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Processed: fixes ages ago
Processing commands for [EMAIL PROTECTED]: > fixed 430227 3.6.0-21.1 Bug#430227: ldbl128 transition for alpha, powerpc, sparc, s390 Bug marked as fixed in version 3.6.0-21.1. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430227: marked as done (ldbl128 transition for alpha, powerpc, sparc, s390)
Your message dated Fri, 25 Apr 2008 11:50:40 +0300 with message-id <[EMAIL PROTECTED]> and subject line fixes ages ago has caused the Debian Bug report #430227, regarding ldbl128 transition for alpha, powerpc, sparc, s390 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 [EMAIL PROTECTED] immediately.) -- 430227: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430227 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: atlas3-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. --- End Message --- --- Begin Message --- fixed 430227 3.6.0-21.1 thanks -- "rm -rf" only sounds scary if you don't have backups --- End Message ---
Bug#432182: marked as done (nvidia-kernel-source: System unexpected freezes)
Your message dated Fri, 25 Apr 2008 08:58:52 + with message-id <[EMAIL PROTECTED]> and subject line Re: Bug#432182: Seems to be resolved has caused the Debian Bug report #432182, regarding nvidia-kernel-source: System unexpected freezes 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 [EMAIL PROTECTED] immediately.) -- 432182: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432182 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: linux-image-2.6.21-2-amd64 Version: 2.6.21-5 Severity: normal My system has the following components: * ASUS A8N-E Socket 939 NVIDIA nForce4 Ultra ATX AMD Motherboard * ASUS EN7300LE/HTD/128M GeForce 7300LE * Western Digital Caviar SE16 WD2500KS 250GB 7200 RPM SATA * AMD Athlon 64 X2 3800+ 2.0GHz / 1MB Cache / 2000MHz FSB / Socket 939 / Dual-Core (Manchester) I've had it for several months, and it has been very stable -- no unexplained hangs or freezes. I ran 2.6.18-4-amd64 for much of that time. Recently, I upgraded to 2.6.21-1-amd64 and then 2.6.21-2-amd64. While running 2.6.21-2-amd64, I've had two system hangs where the system becomes completely unresponsive. It doesn't respond to keyboard or mouse input (e.g., Ctrl-Alt-Backspace, Ctrl-Alt-Del, Ctrl-Alt-F1, are all ineffective). I end up having to reset the machine. There isn't any useful information in /var/log, so I don't know what else to report. I know this report isn't very useful by itself, but I thought when combined with other reports it might be useful. For the time being, I am running 2.6.21-1-amd64. # lspci -v -v 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: fee0 Data: 4049 Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x2, ASPM L0s, Port 3 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x4 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 8, PowerLimit 25.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [100] Virtual Channel 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: fee0 Data: 4051 Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0,
Processed (with 1 errors): notfixed 475148 in qt4-x11_4.4.0~rc1-2, fixed 475148 in 4.4.0~rc1-2
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.26 > notfixed 475148 qt4-x11_4.4.0~rc1-2 Unknown command or malformed arguments to command. > fixed 475148 4.4.0~rc1-2 Bug#475148: qt4-x11_4.4.0~rc1-1(sparc/experimental): FTBFS: error: explicit template specialization cannot have a storage class Bug marked as fixed in version 4.4.0~rc1-2. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: jk
Processing commands for [EMAIL PROTECTED]: > found 476976 0.98.1-1 Bug#476976: scons: Doesn't work at all Bug marked as found in version 0.98.1-1. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474294: RFH: Chrony goes into endless loop on x86_64
On Thu, Apr 24, 2008 at 02:21:39PM -0500, John Hasler wrote:
> Gabor writes:
> > That will be difficult since sometimes the bug does not hit for weeks and
> > then suddenly chrony starts to loop all the time.
>
> Are you saying that you have seen the bug?
Yes, see bug #447011. In fact, #474294 is a duplicate of #447011...
> > So I'd say go ahead and upload the new version to unstable, and if there
> > are no new occurances of the bug for 1-2 months then you can close it.
>
> Which would probably result in Chrony being removed from Lenny.
Well, then someone should start debugging it. The gdb trace sent by
Goshwin is quite promising. If UTI_NormaliseTimeval() is called with
x->tv_usec being a very large value (say LONG_MAX), that would clearly
explain the hang, and it would also explain why i386 does not seem to be
affected even if it is just as buggy as amd64: on i386, the while {}
loops execute at most 2147 times which is basically unnoticable, while
on amd64 that can be 2^32 times more.
So, IMHO turning the two while {} loops in UTI_NormaliseTimeval() into
divide/remainder operations should fix the hang. However, it still needs
investigation _why_ UTI_NormaliseTimeval() is being called with such a
bad time value, as it may be a result of a more severe bug like memory
corruption. Maybe upstream could help here.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
Laboratory of Parallel and Distributed Systems
Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary
Phone/Fax : +36 1 329-78-64 (secretary)
W3: http://www.lpds.sztaki.hu
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471670: [bzip2] CVE-2008-1372 buffer over-read via crafted archive file
Package: bzip2 Version: 1.0.5-0.1 --- Please enter the report below this line. --- Hi. This bug has been quiet for a while... I'm just pinging to see if there's any progress in fixing it in stable (and possibly oldstable). Regards, Zoran --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 990 testing security.debian.org 990 testing debian.iskon.hr 990 testing buildd.emdebian.org 600 stable security.debian.org 600 stable debian.iskon.hr 500 ubuntu-doko people.ubuntu.com 500 kernel-dists-sid kernel-archive.buildserver.net 500 feisty wine.budgetdedicated.com 50 unstabledebian.iskon.hr 50 unstabledebian-multimedia.org 50 unstablebuildd.emdebian.org 40 experimentaldebian.iskon.hr --- Package information. --- Depends(Version) | Installed -+-== libbz2-1.0 (= 1.0.5-0.1) | 1.0.5-0.1 libc6 (>= 2.7-1) | 2.7-10 -- Zoran D�elajlija Informacijski sustavi i servisi Iskon Internet d.d. Garicgradska 18, 1 Zagreb Croatia Telefon: +385 1 6000 700 Telefax: +385 1 6000 777 http://www.iskon.hr IZJAVA O ODRICANJU OD ODGOVORNOSTI: Sadr�aj ove poruke i eventualno prilo�enih datoteka povjerljiv je i namijenjen samo primateljima navedenima u adresi. Svako neovla�teno kori�tenje, objavljivanje, prerada, obrada, reprodukcija, prikazivanje, preno�enje, snimanje ili bilo koji drugi oblik neovla�tene uporabe ove elektroni�ke po�te podlije�e kaznenoj i prekr�ajnoj odgovornosti kao i gra�ansko pravnoj za�titi. DISCLAIMER: The contents of this email as well as any files attached to it are confidential and intended solely for recipients which they are addressed to. Any unauthorised use, publishing, editing, treatment, reproduction, displaying, transmitting, photocopying, dissemination, or any other type of unauthorised use of this e-mail is illegal and, as such, shall be subject to criminal and offence (infringement, violation) responsibility, as well as civil legal protection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471670: [bzip2] CVE-2008-1372 buffer over-read via crafted archive file
On Fri, April 25, 2008 13:08, Zoran Dzelajlija wrote: > Hi. This bug has been quiet for a while... I'm just pinging to see if > there's any progress in fixing it in stable (and possibly oldstable). Just a quick note: I'm not aware of progress for stable, but I can already note that no updates are made anymore to oldstable, that has been EOLed. cheers, Thijs
Processed: found 477747 in 2.0.0.9-3
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.25 > found 477747 2.0.0.9-3 Bug#477747: icedove: Linking a trivial program with icedove-xpcom fails Bug marked as found in version 2.0.0.9-3. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477805: vlc: CVE-2008-1881 stack-based buffer overflow in subtitle parsing
Package: vlc Severity: grave Tags: security Hi, the following CVE (Common Vulnerabilities & Exposures) id was published for vlc. CVE-2008-1881[0]: | Stack-based buffer overflow in the ParseSSA function | (modules/demux/subtitle.c) in VLC 0.8.6e allows remote attackers to | execute arbitrary code via a long subtitle in an SSA file. NOTE: this | issue is due to an incomplete fix for CVE-2007-6681. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1881 http://security-tracker.debian.net/tracker/CVE-2008-1881 -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpWwfQi7S3Th.pgp Description: PGP signature
Bug#477744: hypre_2.0.0.dfsg-1(sparc/unstable): FTBFS on sparc, error: cannot compile a simple Fortran program
On Fri, 2008-04-25 at 01:18 +0200, Martin Zobel-Helas wrote: > Package: hypre > Version: 2.0.0.dfsg-1 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of hypre_2.0.0.dfsg-1 on lebrun by sbuild/sparc 98 > > Build started at 20080423-1139 > > [...] > > > ** Using build dependencies supplied by package: > > Build-Depends: debhelper (>= 3.0), libopenmpi-dev, libsuperlu3-dev, > > libatlas-base-dev | libblas-3gf.so > > [...] > > > checking whether mpicc accepts -g... (cached) yes > > checking for mpicc option to accept ANSI C... (cached) none needed > > checking whether we are using the GNU C++ compiler... yes > > checking whether mpicxx accepts -g... yes > > checking how to run the C++ preprocessor... mpicxx -E > > checking whether we are using the GNU Fortran 77 compiler... no > > checking whether mpif77 accepts -g... no > > checking how to get verbose linking output from mpif77... configure: > > WARNING: compilation failed > > > > checking for Fortran libraries of mpif77... > > checking for dummy main to link with Fortran libraries... none > > checking for Fortran name-mangling scheme... configure: error: cannot > > compile a simple Fortran program > > See `config.log' for more details. > > make: *** [build-stamp] Error 1 > > dpkg-buildpackage: failure: debian/rules build gave error exit status 2 > > A full build log can be found at: > http://buildd.debian.org/build.php?arch=sparc&pkg=hypre&ver=2.0.0.dfsg-1 Indeed. It used to build-dep on libmpich1.0-dev, which depended on the Fortran compiler, but libopenmpi-dev does not. I'll fix that real soon. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467096: traverso: compiled with optimisations not supported on all i386 subarchitectures
sorry for my non-working patch, it'll get removed by the next upload. the upstream author is in #traverso on freenode and knows about this problem. he's working on a solution. yours, gürkan
Bug#477765: refer to #476689
Hi Martin, Please refer to bug #476689, I believe your bootstrap issue is tracked there. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file
Package: blender Severity: grave Tags: security Hi, the following CVE (Common Vulnerabilities & Exposures) id was published for blender. CVE-2008-1102[0]: | Stack-based buffer overflow in the imb_loadhdr function in Blender | 2.45 allows user-assisted remote attackers to execute arbitrary code | via a .blend file that contains a crafted Radiance RGBE image. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1102 http://security-tracker.debian.net/tracker/CVE-2008-1102 -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpxowXGzWB9O.pgp Description: PGP signature
Bug#476045: backports
Hi, Note that this also breaks backports to etch, where gcc-4.2 isn't available. Unless you have strong reasons to avoid gcc-4.1, I recommend that you simply remove the variable override: # we are modern and build with 4.2 everywhere CXX=g++-4.2 CC=gcc-4.2 export CXX CC IMO being modern isn't really a package-specific issue ;-) -- Robert Millan "The technological evasion of the license is as unacceptable as the legal evasion of the license [...]. That's the provision in section 1 regarding keys. [...] We say one thing: when you sell somebody a home... give him the keys" -- Eben Moglen on GPLv3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475036: Wanted features
According to your plans of redesign please consider #48 as features. Always lacking them since have started using make-kpkg 8 years ago. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: your mail
Processing commands for [EMAIL PROTECTED]: > package liferea Ignoring bugs not assigned to: liferea > tags 474736 security Bug#474736: liferea: opens browser for titles and descriptions with embedded URLs There were no tags set. Tags added: security > quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477805: vlc: CVE-2008-1881 stack-based buffer overflow in subtitle parsing
Hi! Should be fixed in 0.8.6f, for patch see: http://git.videolan.org/gitweb.cgi?p=vlc.git;a=commitdiff;h=94baded6eff88e39c98b6e3572826f16f21ceec3 http://bugs.gentoo.org/show_bug.cgi?id=214277#c2 -- Tomas Hoger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file
Hi! Upstream patch: svn diff -r14431:14461 https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/imbuf/intern/radiance_hdr.c http://cvs.fedoraproject.org/viewcvs/rpms/blender/devel/blender-2.45-cve-2008-1102.patch HTH -- Tomas Hoger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477034: Patch to fix 477034
tags 477034 + patch thanks Hi! Please find attached a patch to fix this bug. The solution is to just use the right Python version as given by pyversions -d. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 diff -Nru --exclude changelog wapiti-1.1.6/debian/rules wapiti-1.1.6/debian/rules --- wapiti-1.1.6/debian/rules 2008-04-25 09:30:48.0 +0530 +++ wapiti-1.1.6/debian/rules 2008-04-25 09:30:48.0 +0530 @@ -22,7 +22,7 @@ chmod +x $(CURDIR)/debian/wapiti/usr/bin/wapiti # for lintian to solve the hybrid problem - chmod +x $(CURDIR)/debian/wapiti/usr/lib/python2.4/site-packages/*.py + chmod +x $(CURDIR)/debian/wapiti/usr/lib/`pyversions -d`/site-packages/*.py #rm -f $(CURDIR)/debian/wapiti/usr/lib/python2.4/site-packages/*.egg-info binary-indep: install signature.asc Description: Digital signature
Bug#452128: Is there a need to run the upgrade script?
Sorry for the delay. I somehow missed your e-mail. On Saturday 19 April 2008 04:00:41 am Jan Wagner wrote: > You are confusing me with your /var/lib/gallery2/g2data*. What > does "ls -la /var/lib/gallery2/" say? zsh 11 % ls -la /var/lib/gallery2/ total 1 drwxr-xr-x 3 root root 80 2007-04-01 22:06 . drwxr-xr-x 47 root root 1208 2008-04-12 02:17 .. drwxrwxrwx 3 www-data www-data 72 2006-09-09 16:24 g2data.bak Thanks, Shawn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477004: Patch to fix the magicor FTBFS
tags 477004 + patch thanks Hi! Please find attached a patch to fix this bug by using a generic Python version. You should also consider using a Python support system like pycentral or pysupport for handling the byte compilation. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 --- magicor-1.0/debian/magicor.dirs +++ magicor-1.0/debian/magicor.dirs @@ -1,3 +1,2 @@ usr/games -usr/lib/python2.4/site-packages/magicor etc diff -u magicor-1.0/debian/magicor.install magicor-1.0/debian/magicor.install --- magicor-1.0/debian/magicor.install +++ magicor-1.0/debian/magicor.install @@ -5,4 +4,0 @@ -debian/tmp/usr/lib/python2.4/site-packages/magicor/*.py -debian/tmp/usr/lib/python2.4/site-packages/magicor/editor/*.py -debian/tmp/usr/lib/python2.4/site-packages/magicor/sprites/*.py -debian/tmp/usr/lib/python2.4/site-packages/magicor/states/*.py diff -u magicor-1.0/debian/rules magicor-1.0/debian/rules --- magicor-1.0/debian/rules +++ magicor-1.0/debian/rules @@ -11,0 +12,6 @@ + +install/magicor:: + dh_install debian/tmp/usr/lib/`pyversions -d`/site-packages/magicor/*.py usr/lib/`pyversions -d`/site-packages/magicor + dh_install debian/tmp/usr/lib/`pyversions -d`/site-packages/magicor/editor/*.py usr/lib/`pyversions -d`/site-packages/magicor/editor + dh_install debian/tmp/usr/lib/`pyversions -d`/site-packages/magicor/sprites/*.py usr/lib/`pyversions -d`/site-packages/magicor/sprites + dh_install debian/tmp/usr/lib/`pyversions -d`/site-packages/magicor/states/*.py usr/lib/`pyversions -d`/site-packages/magicor/states signature.asc Description: Digital signature
Processed: Patch to fix the magicor FTBFS
Processing commands for [EMAIL PROTECTED]: > tags 477004 + patch Bug#477004: magicor: FTBFS: dh_install: magicor missing files (debian/tmp/usr/lib/python2.4/site-packages/magicor/*.py), aborting There were no tags set. Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 477808
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.26 > tags 477808 + patch Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file Tags were: security Tags added: patch > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 477805
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.26 > tags 477805 + patch Bug#477805: vlc: CVE-2008-1881 stack-based buffer overflow in subtitle parsing Tags were: security Tags added: patch > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452128: Is there a need to run the upgrade script?
Hi Shawn, On Friday 25 April 2008 16:04, Shawn Willden wrote: > zsh 11 % ls -la /var/lib/gallery2/ > total 1 > drwxr-xr-x 3 root root 80 2007-04-01 22:06 . > drwxr-xr-x 47 root root 1208 2008-04-12 02:17 .. > drwxrwxrwx 3 www-data www-data 72 2006-09-09 16:24 g2data.bak looks like you messed up your system somehow. # ls -la /var/lib/gallery2/ total 12 drwxr-xr-x 3 root root 4096 Apr 23 2007 . drwxr-xr-x 28 root root 4096 Jan 28 21:55 .. drwxr-xr-x 8 www-data www-data 4096 Apr 23 2007 g2data With kind regards, Jan. -- Never write mail to <[EMAIL PROTECTED]>, you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgptOGDeoXYvj.pgp Description: PGP signature
Bug#477194: starting exim4 with identical options from command line OK
Package: exim4 Version: 4.69-2 Followup-For: Bug #477194 If I start exim4 from the command line #/usr/sbin/exim4 -bd -q30m it starts without complaint. These are the exact options exim4 would normally start with in the past, but something in the startup sequence has changed and it doesn't start through the normal services now. -- Package-specific info: Exim version 4.69 #1 built 12-Apr-2008 09:55:16 Copyright (c) University of Cambridge 2006 Berkeley DB: Berkeley DB 4.6.21: (September 27, 2007) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='smarthost' dc_other_hostnames='trav.savageroad.com' dc_local_interfaces='127.0.0.1' dc_readhost='xmission.com' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='mail.xmission.com' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:trav.savageroad.com -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.25 (SMP w/2 CPU cores; 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 exim4 depends on: ii debconf [debconf-2.0] 1.5.21 Debian configuration management sy ii exim4-base4.69-2+b1 support files for all Exim MTA (v4 ii exim4-daemon-light4.69-2+b1 lightweight Exim MTA (v4) daemon exim4 recommends no packages. -- debconf information: exim4/drec: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477827: am-utils fails to build if change configure.in and autoconf 2.61 installed
Package: am-utils Version: 6.1.5-3 Severity: serious Tags: patch Justification: no longer builds from source If, for some reason or other, one changes the configure.in file and tries to rebuild the am-utils package, and a newer version of autconf is installed then am-utils fails to build at the dh_ins For example: Script started on Fri 25 Apr 2008 03:11:40 PM CEST [EMAIL PROTECTED]:~/am-utils-6.1.5$ rm configure [EMAIL PROTECTED]:~/am-utils-6.1.5$ autoconf [EMAIL PROTECTED]:~/am-utils-6.1.5$ dpkg-buildpackage -rfakeroot dpkg-buildpackage: source package is am-utils dpkg-buildpackage: source version is 6.1.5-3 dpkg-buildpackage: source changed by Tim Cutts <[EMAIL PROTECTED]> dpkg-buildpackage: host architecture i386 dpkg-buildpackage: source version without epoch 6.1.5-3 [...] dh_install --fail-missing -a -i cp: cannot stat `debian/tmp/usr/info': No such file or directory dh_install: command returned error code 256 make: *** [install] Error 1 [EMAIL PROTECTED]:~/am-utils-6.1.5$ exit Script done on Fri 25 Apr 2008 04:11:47 PM CEST The problem is that as of autoconf 2.61-4 "infodir" is by default /usr/share/info, not /usr/info like the debian/autoconf-doc.install file expects. A workaround is to force infodir on the make install step in debian/rules: --- am-utils-6.1.5/debian/rules.orig2008-04-25 15:11:57.0 +0200 +++ am-utils-6.1.5/debian/rules 2008-04-25 16:19:58.0 +0200 @@ -108,6 +108,7 @@ dh_installdirs $(MAKE) prefix=`pwd`/debian/tmp/usr \ + infodir=`pwd`/debian/tmp/usr/info \ mandir=`pwd`/debian/tmp/usr/share/man install rm -fr debian/tmp/usr/etc rm debian/tmp/usr/sbin/lostaltmail -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-ssi-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages am-utils depends on: ii debconf1.5.11etch1 Debian configuration management sy ii libamu46.1.5-3 Support library for amd the 4.4BSD ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime ii libhesiod0 3.0.2-18.1Libraries for hesiod, a service na ii libldap2 2.1.30-13.3 OpenLDAP libraries ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra ii perl 5.8.8-7etch1 Larry Wall's Practical Extraction ii portmap5-9.ssi2 The RPC portmapper ii ucf2.0020Update Configuration File: preserv am-utils recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Patch to fix 477034
Processing commands for [EMAIL PROTECTED]: > tags 477034 + patch Bug#477034: wapiti: FTBFS: chmod: cannot access `/build/user/wapiti-1.1.6/debian/wapiti/usr/lib/python2.4/site-packa ges/*.py': No such file or directory There were no tags set. Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file
tag 477808 pending thanks On 25/04/2008, Tomas Hoger wrote: > Hi! Hi, > Upstream patch: > […] > HTH sure, many thanks! Mraw, KiBi. pgpxSmlVBKHEA.pgp Description: PGP signature
Processed: Re: Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file
Processing commands for [EMAIL PROTECTED]: > tag 477808 pending Bug#477808: blender: CVE-2008-1102 arbitrary code execution via crafted .blend file Tags were: patch security Tags added: pending > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 477732 is serious
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.20 > severity 477732 serious Bug#477732: libgsl0ldbl must conflict with libgsl0 Severity set to `serious' from `wishlist' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477506: Bug#476823: ltsp - FTBFS: error: current host architecture 's390' does not appear in package's architecture list (amd64 i386 powerpc)
tags 476823 help tags 477506 help thanks On Sat, Apr 19, 2008 at 02:03:48PM +0200, Bastian Blank wrote: > There was an error while trying to autobuild your package: > > > Automatic build of ltsp_5.1.3-1 on debian-31.osdl.marist.edu by sbuild/s390 > > 98 > [...] > > dh_gencontrol -a > > dpkg-gencontrol: error: current host architecture 's390' does not appear in > > package's architecture list (amd64 i386 powerpc) this was intentional, as ltsp doesn't really have testing network boot support for most architectures, and many architectures don't really seem to likely to be useful as thin-clients. i'm having trouble finding documentation for the process to reduce the number of architectures for a set of packages. changing "Architecture: any" to "Architecture: foo bar baz" clearly seems to stop the package from sucessfully building, but doesn't stop a buildd from attempting to build the package. from what i've gathered, i'll need to contact ftp-master and/or debian-release about getting the packages removed from unstable and testing? thanks for your help! live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Bug#476823: ltsp - FTBFS: error: current host architecture 's390' does not appear in package's architecture list (amd64 i386 powerpc)
Processing commands for [EMAIL PROTECTED]: > tags 476823 help Bug#476823: ltsp - FTBFS: error: current host architecture 's390' does not appear in package's architecture list (amd64 i386 powerpc) There were no tags set. Tags added: help > tags 477506 help Bug#477506: ltsp_5.1.3-1(sparc/unstable): There were no tags set. Tags added: help > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477491: Acknowledgement ([python-moinmoin] upgrade from 1.5.8 to 1.6.2 broke wiki(no RequestModPy))
One problem with the migration instructions in README.migration.gz is that moin is not in the path for user www-data. I can find moin in /usr/share/moin/server/moin and use the full path but I get the following error when I run it. /etc/moin# /usr/share/moin/server/moin --config-dir /etc/moin --wiki-url localhost/profitwiki migration data Loading ... MoinMoin - 1.6.3 [release] error: too many arguments moin - MoinMoin daemon usage: moin command commands: start start the server stop stop the server restart stop then start the server kill kill the server @copyright: 2004-2005 Thomas Waldmann, Nir Soffer @license: GNU GPL, see COPYING for details. If I run moin-mass-migrate there is the same problem with moin not being in the path. I hard coded /usr/share/moin/server/moin in the moin-mass-migrate script and then I get the same error as above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477836: foomatic-gui: Unable to read printer database
Package: foomatic-gui Version: 0.7.7-0.2 Severity: grave Justification: renders package unusable Foomatic-gui (version 0.7.7-0.2) is not accessible any more. Since the command line's interface, I obtain the message "Unable to read printer database". -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-486 Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages foomatic-gui depends on: ii gksu 2.0.0-5 graphical frontend to su ii python 2.4.4-6 An interactive high-level object-o ii python-foomatic 0.7.7-0.2 Python interface to the Foomatic p ii python-glade22.12.1-1GTK+ bindings: Glade support ii python-gnome22.22.0-1Python bindings for the GNOME desk ii python-gnome2-extras 2.14.3-1+b1 Python bindings for the GNOME desk ii python-gtk2 2.12.1-1Python bindings for the GTK+ widge Versions of packages foomatic-gui recommends: ii netcat1.10-37TCP/IP swiss army knife -- transit ii netcat-traditional [netcat] 1.10-37TCP/IP swiss army knife ii nmap 4.53-1 The Network Mapper ii pconf-detect 0.5-11 Small printer auto-detect command- pn smbclient (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476048: netdude: FTBFS: checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory
Kumar Appaiah wrote: > Goof up! Here you go! :-) Great, thanks! One tiny error, however - "This package contains the are the libraries." in the libnetdude long description. I'm guessing this should be "This package contains the shared libraries" or similar. The next step would be to prepare an upload of this package and send a link to the .dsc to [EMAIL PROTECTED] so it can be uploaded. :) Regards, -- Chris Lamb, UK [EMAIL PROTECTED] GPG: 0x634F9A20 signature.asc Description: PGP signature
Processed: update
Processing commands for [EMAIL PROTECTED]: > found 472700 1:1.9.2-3 Bug#472700: Source package contains non-free IETF RFC/I-D Bug marked as found in version 1:1.9.2-3. > found 393420 1.5.5.dfsg.1-0.1 Bug#393420: Source package contains non-free IETF RFC/I-D's Bug marked as found in version 1.5.5.dfsg.1-0.1 and reopened. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476045: backports
On Fri, Apr 25, 2008 at 02:22:21PM +0200, Robert Millan wrote: > > Hi, > > Note that this also breaks backports to etch, where gcc-4.2 isn't available. > > Unless you have strong reasons to avoid gcc-4.1, I recommend that you simply > remove the variable override: > > # we are modern and build with 4.2 everywhere > CXX=g++-4.2 > CC=gcc-4.2 > export CXX CC > > IMO being modern isn't really a package-specific issue ;-) > It was when 4.2 wasn't the default and 4.1 didn't work right because of visibility issues. I can surely drop this on 0.8 update. BTW, no idea if you are trying to go for something here, but please don't NMU for iceowl. If you want to do iceowl go for the bzr branch i maintain at least. - Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477283: Patch to fix 477283
tags 477283 + patch thanks Hi! Please find attached a patch to fix this bug, by adding an include for the problematic file. HTH. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 diff -Nru --exclude changelog /tmp/F5nLzD2mwj/stella-2.2/src/emucore/Cart.cxx /tmp/X7nDkpZmLi/stella-2.2/src/emucore/Cart.cxx --- stella-2.2/src/emucore/Cart.cxx 2006-03-05 06:48:41.0 +0530 +++ stella-2.2/src/emucore/Cart.cxx 2008-04-25 20:57:25.0 +0530 @@ -16,6 +16,7 @@ // $Id: Cart.cxx,v 1.19 2006/03/05 01:18:41 stephena Exp $ // +#include #include #include "bspf.hxx" signature.asc Description: Digital signature
Processed: Patch to fix 477283
Processing commands for [EMAIL PROTECTED]: > tags 477283 + patch Bug#477283: FTBFS with gcc-4.3 There were no tags set. Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476554: marked as done (mumble-server: postinst renders installation impossible)
Your message dated Fri, 25 Apr 2008 15:47:09 +
with message-id <[EMAIL PROTECTED]>
and subject line Bug#476554: fixed in mumble 1.1.3-3
has caused the Debian Bug report #476554,
regarding mumble-server: postinst renders installation impossible
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 [EMAIL PROTECTED]
immediately.)
--
476554: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476554
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: mumble-server
Version: 1.1.3-2
Severity: grave
Tags: patch
Justification: renders package unusable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA224
Hi!
While installing dpkg aborts because "do_configuration" is not a known
command. Just move to function to the begin of the script (patch below,
hope it works).
By the way, thanks for packaging! :)
Cheers,
Hauke
*** diff
diff -uPr mumble-1.1.3/debian/mumble-server.postinst
mumble-1.1.3~/debian/mumble-server.postinst
- --- mumble-1.1.3/debian/mumble-server.postinst2008-04-17
15:09:05.0 +0200
+++ mumble-1.1.3~/debian/mumble-server.postinst 2008-04-17 15:07:32.0
+0200
@@ -17,17 +17,6 @@
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
- -CONF="/etc/mumble-server/mumble-server.ini"
- -CONF_NEW="/etc/mumble-server/mumble-server.ini.new"
- -CONF_OLD="/etc/mumble-server/mumble-server.ini.old"
- -TEMPLATE="/usr/share/mumble-server/templates/murmur.ini.system"
- -do_configuration;
- -CONF="/etc/dbus-1/system.d/murmur.conf"
- -CONF_NEW="/etc/dbus-1/system.d/murmur.conf.new"
- -CONF_OLD="/etc/dbus-1/system.d/murmur.conf.old"
- -TEMPLATE="/usr/share/mumble-server/templates/murmur.conf"
- -do_configuration;
- -
do_configuration() {
if [ -f ${CONF} ] ; then
# No configuration exists, just install the template one.
@@ -47,6 +36,16 @@
fi
}
+CONF="/etc/mumble-server/mumble-server.ini"
+CONF_NEW="/etc/mumble-server/mumble-server.ini.new"
+CONF_OLD="/etc/mumble-server/mumble-server.ini.old"
+TEMPLATE="/usr/share/mumble-server/templates/murmur.ini.system"
+do_configuration;
+CONF="/etc/dbus-1/system.d/murmur.conf"
+CONF_NEW="/etc/dbus-1/system.d/murmur.conf.new"
+CONF_OLD="/etc/dbus-1/system.d/murmur.conf.old"
+TEMPLATE="/usr/share/mumble-server/templates/murmur.conf"
+do_configuration;
case "$1" in
configure)
- -- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iE8DBQFIB0/NGOp6XeD8cQ0RC0gfAN9ce/CzIzB9Uo00hZ35c4hy5Rkb37nDDFBO
WcK0AN94lNmSWEzw0imqdkHWZI4QaRzr9oPJeZq3g+yF
=4s0m
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Source: mumble
Source-Version: 1.1.3-3
We believe that the bug you reported is fixed in the latest version of
mumble, which is due to be installed in the Debian FTP archive:
mumble-server-web_1.1.3-3_all.deb
to pool/main/m/mumble/mumble-server-web_1.1.3-3_all.deb
mumble-server_1.1.3-3_i386.deb
to pool/main/m/mumble/mumble-server_1.1.3-3_i386.deb
mumble_1.1.3-3.diff.gz
to pool/main/m/mumble/mumble_1.1.3-3.diff.gz
mumble_1.1.3-3.dsc
to pool/main/m/mumble/mumble_1.1.3-3.dsc
mumble_1.1.3-3_i386.deb
to pool/main/m/mumble/mumble_1.1.3-3_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Patrick Matthäi <[EMAIL PROTECTED]> (supplier of updated mumble package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 18 Apr 2008 18:00:00 +0100
Source: mumble
Binary: mumble mumble-server mumble-server-web
Architecture: source all i386
Version: 1.1.3-3
Distribution: unstable
Urgency: low
Maintainer: Debian VoIP Team <[EMAIL PROTECTED]>
Changed-By: Patrick Matthäi <[EMAIL PROTECTED]>
Description:
mumble - Low latency VoIP client
mumble-server - Low latency VoIP server
mumble-server-web - Web scripts for mumble-server
Closes: 476472 476554
Changes:
mumble (1.1.3-3) unstable; urgency=low
.
* Call do_conf
Bug#452128: Is there a need to run the upgrade script?
On Friday 25 April 2008 08:20:06 am Jan Wagner wrote: > Hi Shawn, > > On Friday 25 April 2008 16:04, Shawn Willden wrote: > > zsh 11 % ls -la /var/lib/gallery2/ > > total 1 > > drwxr-xr-x 3 root root 80 2007-04-01 22:06 . > > drwxr-xr-x 47 root root 1208 2008-04-12 02:17 .. > > drwxrwxrwx 3 www-data www-data 72 2006-09-09 16:24 g2data.bak > > looks like you messed up your system somehow. Okay. I've never messed with the files in that directory (or any, really), but my G2 installation is fairly old, has been upgraded repeatedly, and was created as an import from a G1 gallery, and I did have to restore from backup after the upgrade failure... so who knows where along the line something might have moved some stuff to a backup, then failed, or whatever. Anyway, any suggestions on how I can get to a clean state? Without, of course, losing all of my data? Thanks, Shawn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477506: ltsp - FTBFS: error: current host architecture 's390' does not appear in package's architecture list (amd64 i386 powerpc)
[Vagrant Cascadian] > from what i've gathered, i'll need to contact ftp-master and/or > debian-release about getting the packages removed from unstable and > testing? You need to submit a BTS issue against the ftp.debian.org pseudopackage, asking for the removal of the binary packages for the packages no longer supported by the ltsp package. See http://bugs.debian.org/47> for an example. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476048: netdude: diff for QA upload 0.3.3-6
Hi,
The attached file is the diff for my netdude 0.3.3-6 QA upload. The
associated changelog entry is:
netdude (0.3.3-6) unstable; urgency=medium
* QA Upload.
* debian/rules:
+ Unexport flags set by dpkg-buildpackage to allow ./configure to run,
thus preventing an FTBFS. (Closes: #476048).
+ Do not set DH_COMPAT.
* debian/control:
+ Standards version is now 3.7.3 (no changes needed).
+ Use at least debhelper 5 for build.
+ Update descriptions, fix typos.
+ Use Homepage field.
* Menus:
- Offer the Debian-supplied .xpm over the .png
- Resize the .xpm to 32x32.
The .dsc is available from the following URL:
http://chris-lamb.co.uk/debian/qa/netdude_0.3.3-6.dsc
Regards,
--
Chris Lamb, UK [EMAIL PROTECTED]
GPG: 0x634F9A20
diff -Nru netdude-0.3.3/debian/changelog netdude-0.3.3/debian/changelog
--- netdude-0.3.3/debian/changelog 2008-04-25 17:15:44.0 +0100
+++ netdude-0.3.3/debian/changelog 2008-04-25 17:15:45.0 +0100
@@ -1,3 +1,21 @@
+netdude (0.3.3-6) unstable; urgency=medium
+
+ * QA Upload.
+ * debian/rules:
++ Unexport flags set by dpkg-buildpackage to allow ./configure to run,
+ thus preventing an FTBFS. (Closes: #476048).
++ Do not set DH_COMPAT.
+ * debian/control:
++ Standards version is now 3.7.3 (no changes needed).
++ Use at least debhelper 5 for build.
++ Update descriptions, fix typos.
++ Use Homepage field.
+ * Menus:
+- Offer the Debian-supplied .xpm over the .png
+- Resize the .xpm to 32x32.
+
+ -- Chris Lamb <[EMAIL PROTECTED]> Fri, 25 Apr 2008 17:10:27 +0100
+
netdude (0.3.3-5) unstable; urgency=medium
* QA upload.
diff -Nru netdude-0.3.3/debian/compat netdude-0.3.3/debian/compat
--- netdude-0.3.3/debian/compat 1970-01-01 01:00:00.0 +0100
+++ netdude-0.3.3/debian/compat 2008-04-25 17:15:45.0 +0100
@@ -0,0 +1 @@
+5
diff -Nru netdude-0.3.3/debian/control netdude-0.3.3/debian/control
--- netdude-0.3.3/debian/control2008-04-25 17:15:44.0 +0100
+++ netdude-0.3.3/debian/control2008-04-25 17:15:45.0 +0100
@@ -2,8 +2,9 @@
Section: net
Priority: optional
Maintainer: Debian QA Group <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>> 3.0.0), autotools-dev, gettext, bison, m4,
libgtk1.2-dev, libpcap-dev, dpatch
-Standards-Version: 3.6.1
+Build-Depends: debhelper (>= 5), autotools-dev, gettext, bison, m4,
libgtk1.2-dev, libpcap-dev, dpatch
+Standards-Version: 3.7.3
+Homepage: http://netdude.sourceforge.net/
Package: netdude
Architecture: any
@@ -26,8 +27,6 @@
TCP and UDP, and a dummy plugin.
* Through the plugin mechanism, Netdude provides a good facility for
writing tcpdump trace file filters.
- .
- http://netdude.sourceforge.net/
Package: netdude-dev
Architecture: any
@@ -37,7 +36,7 @@
It is a GUI-based tool that allows you to make detailed changes to
packets in tcpdump trace files.
.
- These are the development files.
+ This package contains the development files.
Package: libnetdude
Architecture: any
@@ -47,4 +46,4 @@
It is a GUI-based tool that allows you to make detailed changes to
packets in tcpdump trace files.
.
- This are the libs.
+ This packages contains the shared object files.
diff -Nru netdude-0.3.3/debian/menu netdude-0.3.3/debian/menu
--- netdude-0.3.3/debian/menu 2008-04-25 17:15:44.0 +0100
+++ netdude-0.3.3/debian/menu 2008-04-25 17:15:45.0 +0100
@@ -1,2 +1,2 @@
?package(netdude):needs="x11" section="Applications/Network/Monitoring"
title="Netdude" command="/usr/bin/netdude" \
- icon="/usr/share/netdude/pixmaps/netdude-icon.png"
+ icon="/usr/share/netdude/pixmaps/netdude-icon.xpm"
diff -Nru netdude-0.3.3/debian/netdude-icon.xpm
netdude-0.3.3/debian/netdude-icon.xpm
--- netdude-0.3.3/debian/netdude-icon.xpm 2008-04-25 17:15:44.0
+0100
+++ netdude-0.3.3/debian/netdude-icon.xpm 2008-04-25 17:15:45.0
+0100
@@ -1,243 +1,189 @@
/* XPM */
-static char *netdude-icon[] = {
+static char *netdude_icon[] = {
/* columns rows colors chars-per-pixel */
-"48 48 189 2",
-" c #00",
-". c #090602",
-"X c #0d0803",
-"o c #170d05",
-"O c #1a0e05",
-"+ c #1e1207",
-"@ c #221207",
-"# c #271b0a",
-"$ c #2b1709",
-"% c #2f1f0b",
-"& c #34200c",
-"* c #3c220d",
-"= c #3c2a0f",
-"- c #3d2c10",
-"; c #570707",
-": c #550b08",
-"> c #590608",
-", c #5e0a09",
-"< c #5a120a",
-"1 c #5d1a0d",
-"2 c #43230e",
-"3 c #42290f",
-"4 c #522c11",
-"5 c #592f12",
-"6 c #523915",
-"7 c #5c3213",
-"8 c #630708",
-"9 c #650909",
-"0 c #680709",
-"q c #6c0909",
-"w c #63130c",
-"e c #6a110c",
-"r c #6c1b0e",
-"t c #6e1f10",
-"y c #74080a",
-"u c #7c090a",
-"i c #72110c",
-"p c #74190e",
-"a c #7b110c",
-"s c #662310",
-"d c #6b2b12",
-"f c #643414",
-"g c #6e3014",
-"h c #6d3b17",
-"j c #762311",
-"k
Bug#477867: java-gnome: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: java-gnome Version: 4.0.6-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477846: axis: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: axis Version: 1.4-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477876: libjogl-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libjogl-java Version: 1.1.1~rc8-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477858: eclipse: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: eclipse Version: 3.2.2-5 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477859: glib-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: glib-java Version: 0.4.2-9 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477842: Package:: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: Package: Version: $pkg Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477845: babel: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: babel Version: 1.2.0.dfsg-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477887: librepository: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: librepository Version: 0.1.4-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477860: eclipse-cdt: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: eclipse-cdt Version: 3.1.2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477889: libswirl-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libswirl-java Version: 1.0.13-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477906: swig1.3: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: swig1.3 Version: 1.3.35-3.1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477884: libpano13: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libpano13 Version: 2.9.12.dfsg-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477849: bsh: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: bsh Version: 2.0b4-7 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477870: lasso: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: lasso Version: 2.1.1-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477878: libmatthew-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libmatthew-java Version: 0.6-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477891: libtritonus-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libtritonus-java Version: 20070428-6 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477850: cairo-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: cairo-java Version: 1.0.8-8 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477863: gdb: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: gdb Version: 6.8-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477903: sacjava: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: sacjava Version: 1.3-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477901: qdbm: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: qdbm Version: 1.8.74-1.1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477873: libgtk-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libgtk-java Version: 2.10.2-6 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477852: classpath: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: classpath Version: 2:0.97-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477857: docbook-xsl-saxon: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: docbook-xsl-saxon Version: 1.00.dfsg.1-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477898: pdftk: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: pdftk Version: 1.41-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477894: libvte-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libvte-java Version: 0.12.3-4 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477881: libmx4j-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libmx4j-java Version: 3.0.2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477905: swt-gtk: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: swt-gtk Version: 3.3.1-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477864: hyperestraier: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: hyperestraier Version: 1.4.9-1.2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477883: libjaxp1.2-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libjaxp1.2-java Version: 1.2.01-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477882: libgconf-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libgconf-java Version: 2.12.6-4 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477890: libtool: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libtool Version: 1.5.26-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477877: libflexdock-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libflexdock-java Version: 0.5.1-dfsg1-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477904: setools: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: setools Version: 3.3.4.ds-3 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477853: commons-daemon: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: commons-daemon Version: 1.0.2~svn20061127-6 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477885: libreadline-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libreadline-java Version: 0.8.0.1-8 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477874: libgui-commands-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libgui-commands-java Version: 1.1.43-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477844: ant: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: ant Version: 1.7.0-5 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477869: grinvin: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: grinvin Version: 1.0.3.dfsg.1-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477865: icepick: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: icepick Version: 0.01-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477868: kaffe: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: kaffe Version: 2:1.1.8-4 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477848: brltty: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: brltty Version: 3.9-7 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477847: bouncycastle: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: bouncycastle Version: 1.39-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477888: libservlet2.4-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libservlet2.4-java Version: 5.0.30-7 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477871: libextractor-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libextractor-java Version: 0.5.18-1 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477851: charva: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: charva Version: 1.1.4-2 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477872: libgnome-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: libgnome-java Version: 2.12.7-4 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477909: trang: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Package: trang Version: 20030619-6 Severity: serious User: [EMAIL PROTECTED] Usertags: gcj-bd gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). A package build-depending on default-jdk-builddep should use as JAVA_HOME /usr/lib/jvm/default-java, or as path for the tools /usr/lib/jvm/default-java/bin. If the package builds just architecture dependent binaries which contain only byte-code compiled to native code (packages which often end with "-gcj"), then the architecture restrictions on the build dependency may not be needed (however the package cannot be built anymore on those archs). In this case make sure that the binary packages get removed on these architectures. Please check the influence of a package upload on ongoing transitions before an upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
