Bug#477023: stellarium: FTBFS: CMake Error: Could not find JPEG library
Le lundi 21 avril 2008 à 02:34 +0200, Sune Vuorela a écrit : While trying to fix cmake, I discovered that stellarium ships its own embedded FindQt4.cmake file. And the error is not related to that Hello, do you mean that the FindQt4.cmake file is not a problem, and there's no need to remove/fix it ? You also need to build-dep on libjpeg62-dev, as you include headers from there. With that change, your package seems to build. Thanks ! Regards, Cédric
Bug#441370: stellarium-data: Contain architecture specific files in 'all' package
Le dimanche 09 septembre 2007 à 15:35 +0200, Julien BLACHE a écrit : Petter Reinholdtsen [EMAIL PROTECTED] wrote: Hi, I guess I learned something new, then. I thought the .mo files was mmapped into the programs and looked up using fast and arch-specific methos. If this is not true, I can change my packaging practice. :) I don't know the specifics on gettext's implementation, but this file from the gettext manual offers some hindsight on the file format: http://www.gnu.org/software/gettext/manual/html_node/MO-Files.html I don't see anything arch-specific at first glance, and they discuss a couple of issues like hash tables and alignment mostly to end up telling that it doesn't buy much in the end :) That's also my opinion, but I'm going to ask a gettext expert. For now I'm lowering the bug severity. Thank you both for your input :)
Bug#434112: stellarium: Floating point exception upon start
Le samedi 21 juillet 2007 à 12:26 -0400, Nathan A. Stine a écrit : Package: stellarium Version: 0.9.0-1+b1 Severity: grave Justification: renders package unusable Stellarium 0.9.0-1+b1 just entered testing today. I upgraded, and the program no longer works: Version 0.9.0-1+b1 does not exist in Debian ...
Bug#434112: stellarium: Floating point exception upon start
Le dimanche 22 juillet 2007 à 18:21 -0400, Nathan A. Stine a écrit : On Sun, 2007-07-22 at 23:23 +0200, Fabien Chéreau wrote: Hi could you run a gdb on it to see where it crashes exactely? (type gdb stellarium, then run, then where) Thanks, Fabien After a reboot, the program runs flawlessly. I couldn't tell you what the problem was. If I had to guess, it might have been something with QT. I had no QT libs before installing the package, and this was the first version of stellarium that used QT. There must have been a library or something that didn't get initialized properly...who knows. Either way, the bug can be closed. Sorry to waste your time. Please reopen this bug and follow Fabien instructions if this bug occurs again. Regards,
Bug#434112: stellarium: Floating point exception upon start
Le mardi 24 juillet 2007 à 20:02 +0200, Cyril Brulebois a écrit : Cedric Delfosse [EMAIL PROTECTED] (24/07/2007): Stellarium 0.9.0-1+b1 just entered testing today. I upgraded, and the program no longer works: Version 0.9.0-1+b1 does not exist in Debian ... Yes, it does exist. [EMAIL PROTECTED]:~$ rmadison stellarium [...] stellarium |0.9.0-1 | testing | source, arm, hppa, ia64, mips, mipsel, s390, sparc stellarium |0.9.0-1 | unstable | source, arm, hppa, ia64, m68k, mips, mipsel, s390, sparc stellarium | 0.9.0-1+b1 | testing | alpha, amd64, i386, powerpc stellarium | 0.9.0-1+b1 | unstable | alpha, amd64, i386, powerpc Ok, I did not notice the binary NMUs :(
Bug#421394: Confirmation and full error output
Le lundi 30 avril 2007 à 13:24 +0100, Matt Zimmerman a écrit : severity 421394 serious thanks Confirmed here. The cause seems to be that manual.html is missing from the binary package entirely (at least the i386 build), though still referenced by the .doc-base file. Hmmm weirdo. I no more ship manual.html in the package because upstream no longer maintain it. And the package no more provides the /usr/share/doc-base/pv file too. (The pv package doesn't have a postinst script anymore). I can't reproduce this bug on my system. Maybe this is related to a specific doc-base package version ... Can you tell me your version of doc-base ?
Bug#365465: gaphor and zope3/python-interface dependency
Le lundi 08 janvier 2007 à 00:28 +0100, Fabio Tranchitella a écrit : Hi, * 2007-01-07 14:06, Cedric Delfosse wrote: Could you please post your NMU patch as a review it ? If it's OK for me, I will upload a new package with your patch (giving you all the credits for this patch, of course). I'm attaching a NMU patch to fix the bug splitting the package into gaphor and gaphor-lib. The latter conflicts on zope3 and python-zopeinterface, and the former depends on gaphor-lib | zope3. Hello, please NMU. I tested your patch and looks like that's ok. But notice that bug 365465 has been already closed ! Please close bug 365912 (similar bug that was open after 365465) instead in your debian/changelog. Thanks for your help. Regards,
Bug#365465: gaphor and zope3/python-interface dependency
Le mercredi 03 janvier 2007 à 09:18 +0100, Fabio Tranchitella a écrit : Hi Cedric, your package gaphor is affected by a RC bug (#365465) and for this reason it will be excluded from the etch if the bug won't be solved in time. The actual package in testing/unstable conflicts on zope3 and python-zopeinterface because gaphor makes use of some of the libraries provided by zope3, but they are provided upstream and installed within the same path used by the zope3 package. This makes the package not usable on machines where there are other zope3-related packages. My proposed solution is to split those files into a gaphor-lib (or gaphor-zope) package, conflicting with zope3 and python-zopeinterface, and let gaphor depend on gaphor-lib | zope3. I'm writing this e-mail in order to have your opinion on such a change: as you could imagine, I am not comfortable to do it with a NMU. I'm willing to co-maintain the package if you think it would be the case, too. Hello, sorry for the late answer. Could you please post your NMU patch as a review it ? If it's OK for me, I will upload a new package with your patch (giving you all the credits for this patch, of course). Regards,
Bug#394056: gaphor: FTBFS: tries to create .gaphor in $HOME
Le jeudi 19 octobre 2006 à 08:56 +0200, Julien Danjou a écrit : Package: gaphor Version: 0.8.1-4 Severity: serious Hello, There was a problem while autobuilding your package: Could you retry a build ? I can't reproduce it. Thanks
Bug#381388: gaphor: Fatal Python error: can't initialise module diacanvas.view
Le vendredi 04 août 2006 à 10:17 +1000, Pietro Abate a écrit : [...] $gaphor Fatal Python error: can't initialise module diacanvas.view Aborted There's a missing dependency on python-gnome2 package. Il will upload a fixed version today. Regards
Bug#360571: A quick fix for CVE-2006-0048
Hi,
here is a very quick fix so that at least tcpick does not segfault.
tcpick will abort like this with this patch:
# tcpick -r /tmp/tcpick_test.pcap -a -Y -yP -n not port 22
tcpick: invalid option -- Y
Starting tcpick 0.2.1 at 2006-04-03 21:16 CEST
Timeout for connections is 600
tcpick: reading from /tmp/tcpick_test.pcap
setting filter: not port 22
1 SYN-SENT 10.1.7.1:1025 10.1.7.3:443
seqprobe
.8...1.7.1.10.in-addr.arpa.
SUICIDE: [got_packet] payload lenght calculated with iplen and hdr-len
differs by -10 bytes
hdr-len = 64
datalink_size = 14
IP_SIZE = 20
iplen= 40
tcp_size = 20
iplen - IP_SIZE - tcp_size = 0
(hdr-len - (int)( payload - packet ) = 10
3 packets captured
1 tcp sessions detected
Regards,
--
Cédric Delfosse, http://cdelfosse.free.fr
Get a free backup server: http://lrs.linbox.org !
--- loop.c.orig 2006-04-03 21:39:35.0 +0200
+++ loop.c 2006-04-03 21:39:56.0 +0200
@@ -69,7 +69,6 @@
payload = (u_char *)(packet + datalink_size + IP_SIZE + tcp_size);
payload_len = iplen - IP_SIZE - tcp_size;
-#ifdef TCPICK_DEBUG
if( payload_len != (hdr-len - (int)( payload - packet ) ) ) {
suicide( got_packet,
payload lenght calculated with iplen and hdr-len\n
@@ -92,7 +91,6 @@
);
}
-#endif /* TCPICK_DEBUG */
if( flags.header 0 )
display_header( stdout, ippacket, tcppacket,
signature.asc
Description: Ceci est une partie de message numériquement signée
Bug#343109:
severity 343109 important quit I downgrade this bug to important, because AMD64 was an unofficial architecture for Sarge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343109: boa-constructor: Fails to start
Hello, Can you start boa-constructor, and send me the full console output ? You should have something like: $ boa-constructor Starting Boa Constructor v0.3.0 importing wxPython reading user preferences Created directory: /home/op/.boa-constructor Created directory: /home/op/.boa-constructor/docs-cache Created directory: /home/op/.boa-constructor/Plug-ins running main... creating Palette importing Palette ... If you remove your $HOME/.boa-constructor, does it work better ? Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326927:
Hi, I tested the patch and it fixes the problem, thanks. Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
