Bug#630670: libcore-ocaml-dev: not installable on any architecture
Package: libcore-ocaml-dev Version: 0.6.0-3 Severity: grave Tags: sid User: trei...@debian.org Usertags: edos-uninstallable Affects: libcore-extended-ocaml-dev Hi, libcore-ocaml-dev is not installable in sid on any architecture. On amd64, the reason indicated is: libcore-ocaml-dev (= 0.6.0-3) depends on missing: - libsexplib-camlp4-dev-1ym21 -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630667: Installs files under / and /yapra directly
Hi, That's strange but is that correct? I downloaded from archives and check its contents. It seems completely normal. How to get your package? % dpkg-deb -c /var/cache/apt/archives/yapra_0.1.2-3_all.deb drwxr-xr-x root/root 0 2010-10-11 15:27 ./ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ruby/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ruby/1.8/ -rw-r--r-- root/root 1690 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/ -rw-r--r-- root/root 1484 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/runtime.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/ -rw-r--r-- root/root 347 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/erb_applier.rb -rw-r--r-- root/root 952 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/mechanize_base.rb -rw-r--r-- root/root 436 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/feed_item_operator.rb -rw-r--r-- root/root 308 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/context_aware.rb -rw-r--r-- root/root 468 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin/base.rb -rw-r--r-- root/root 3847 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/pipeline.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin/ -rw-r--r-- root/root 1351 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin/advance_mode_registry.rb -rw-r--r-- root/root 917 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin/registry_factory.rb -rw-r--r-- root/root 1299 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin/compatible_mode_registry.rb -rw-r--r-- root/root 670 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin/base.rb -rw-r--r-- root/root42 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/plugin.rb -rw-r--r-- root/root69 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/legacy_plugin.rb -rw-r--r-- root/root 136 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/version.rb -rw-r--r-- root/root 2326 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/config.rb -rw-r--r-- root/root 1986 2010-10-11 15:27 ./usr/lib/ruby/1.8/yapra/inflector.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/bin/ -rwxr-xr-x root/root 2339 2010-10-11 15:27 ./usr/bin/yapra drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/ drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/config/ -rw-r--r-- root/root 434 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/config/basic_auth.rb -rw-r--r-- root/root 791 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/config/agent.rb -rw-r--r-- root/root 496 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/config/web_post.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/feed/ -rw-r--r-- root/root 865 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/feed/load.rb -rw-r--r-- root/root 1102 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/feed/custom.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/filter/ -rw-r--r-- root/root 1340 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/filter/apply_template.rb -rw-r--r-- root/root 1649 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/filter/entry_full_text.rb -rw-r--r-- root/root 1620 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/filter/deduped.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/test/ -rw-r--r-- root/root 188 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/test/test.rb -rw-r--r-- root/root 198 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/test/raise_error.rb -rw-r--r-- root/root 502 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/test/append_entry.rb -rw-r--r-- root/root 234 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/test/test2.rb drwxr-xr-x root/root 0 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/publish/ -rw-r--r-- root/root 1637 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/publish/file_download.rb -rw-r--r-- root/root 4037 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/publish/imap.rb -rw-r--r-- root/root 613 2010-10-11 15:27 ./usr/share/yapra/lib-plugins/yapra/plugin/publish/gmail.rb -rw-r--r-- root/root 21
Bug#629930: libstdc++6: 4.6.0-12 breaks something in /lib64/*
Matthias Klose said on Mon, Jun 13, 2011 at 12:21:17PM +0200,: > severity 629930 normal > thanks > nobody else seems to see this, can't reproduce it either. Well, I had unst installed a fresh system with squeeze netinst ISO CD, upgraded to -12 and later upgraded to -13 on a different machine. SInce that machine does not have this problem, either an upgrade chain, or some other package is precipitating this issue. Both machines have identical sources.list (experimental, unstable, and testing, in that order). THe newer machine was upgraded just once, and some pick and choose was done using the experimental repositories, and most of things are from testing there. (did an aptitude upgrade about 6 hours back, and nothing is broken so faron the other machine), -- Mahesh T. Pai || Free Software - it is free as in FREEDOM -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630129: libwx-perl: Error: Unable to initialize gtk, is DISPLAY set properly?
I have attached the packages differences, so far. Still builds fine in wheezy but not in unstable. Regards Salvatore --- /tmp/wheezy 2011-06-16 08:24:32.838848570 +0200 +++ /tmp/sid 2011-06-16 08:24:36.950844283 +0200 @@ -1,11 +1,11 @@ -Setting up bsdmainutils (8.2.2) ... +Setting up bsdmainutils (8.2.3) ... Setting up debhelper (8.1.6) ... Setting up file (5.04-5+b1) ... Setting up fontconfig (2.8.0-2.2) ... Setting up fontconfig-config (2.8.0-2.2) ... Setting up gettext (0.18.1.1-3) ... Setting up gettext-base (0.18.1.1-3) ... -Setting up groff-base (1.21-5) ... +Setting up groff-base (1.21-6) ... Setting up html2text (1.3.2a-15) ... Setting up intltool-debian (0.35.0+20060710.1) ... Setting up libalien-wxwidgets-perl (0.51+dfsg-1) ... @@ -17,27 +17,27 @@ Setting up libavahi-common3 (0.6.30-3) ... Setting up libcairo2 (1.10.2-6) ... Setting up libcroco3 (0.6.2-1) ... -Setting up libcups2 (1.4.6-6) ... +Setting up libcups2 (1.4.6-9) ... Setting up libdatrie1 (0.2.4-2) ... -Setting up libdbus-1-3 (1.4.8-3) ... -Setting up libdrm2 (2.4.25-2) ... +Setting up libdbus-1-3 (1.4.12-2) ... +Setting up libdrm2 (2.4.25-3) ... Setting up libexpat1 (2.0.1-7) ... Setting up libextutils-parsexs-perl (2.220600-1) ... -Setting up libextutils-xspp-perl (0.1601-1) ... +Setting up libextutils-xspp-perl (0.1602-1) ... Setting up libfontconfig1 (2.8.0-2.2) ... Setting up libfontenc1 (1:1.1.0-1) ... Setting up libfreetype6 (2.4.4-1) ... Setting up libgcrypt11 (1.4.6-5) ... Setting up libgdk-pixbuf2.0-0 (2.23.3-3) ... -Setting up libgl1-mesa-glx (7.10.2-3) ... +Setting up libgl1-mesa-glx (7.10.3-1) ... Setting up libglib2.0-0 (2.28.6-1) ... -Setting up libglu1-mesa (7.10.2-3) ... +Setting up libglu1-mesa (7.10.3-1) ... Setting up libgnutls26 (2.10.5-1+b1) ... Setting up libgpg-error0 (1.10-0.3) ... Setting up libgssapi-krb5-2 (1.9.1+dfsg-1+b1) ... Setting up libgtk2.0-0 (2.24.4-3) ... Setting up libgtk2.0-common (2.24.4-3) ... -Setting up libice6 (2:1.0.7-1) ... +Setting up libice6 (2:1.0.7-2) ... Setting up libio-stringy-perl (2.110-4) ... Setting up libjasper1 (1.900.1-7+b1) ... Setting up libjpeg62 (6b1-1) ... @@ -48,10 +48,10 @@ Setting up libmagic1 (5.04-5+b1) ... Setting up libpango1.0-0 (1.28.3-6) ... Setting up libpcre3 (8.12-3) ... -Setting up libpipeline1 (1.2.0-2) ... +Setting up libpipeline1 (1.2.0-3) ... Setting up libpixman-1-0 (0.21.8-1) ... Setting up libpng12-0 (1.2.44-2) ... -Setting up libsm6 (2:1.2.0-1) ... +Setting up libsm6 (2:1.2.0-2) ... Setting up libtasn1-3 (2.9-3) ... Setting up libtest-pod-perl (1.44-1) ... Setting up libthai-data (0.1.15-1) ... @@ -62,33 +62,33 @@ Setting up libwxbase2.8-dev (2.8.10.1-3.1) ... Setting up libwxgtk2.8-0 (2.8.10.1-3.1) ... Setting up libwxgtk2.8-dev (2.8.10.1-3.1) ... -Setting up libx11-6 (2:1.4.3-1) ... -Setting up libx11-data (2:1.4.3-1) ... -Setting up libxau6 (1:1.0.6-1) ... +Setting up libx11-6 (2:1.4.3-2) ... +Setting up libx11-data (2:1.4.3-2) ... +Setting up libxau6 (1:1.0.6-3) ... Setting up libxaw7 (2:1.0.9-2) ... -Setting up libxcb-render0 (1.7-2) ... -Setting up libxcb-shm0 (1.7-2) ... -Setting up libxcb1 (1.7-2) ... -Setting up libxcomposite1 (1:0.4.3-1) ... -Setting up libxcursor1 (1:1.1.11-1) ... -Setting up libxdamage1 (1:1.1.3-1) ... -Setting up libxdmcp6 (1:1.1.0-1) ... -Setting up libxext6 (2:1.3.0-1) ... -Setting up libxfixes3 (1:5.0-2) ... +Setting up libxcb-render0 (1.7-3) ... +Setting up libxcb-shm0 (1.7-3) ... +Setting up libxcb1 (1.7-3) ... +Setting up libxcomposite1 (1:0.4.3-2) ... +Setting up libxcursor1 (1:1.1.11-3) ... +Setting up libxdamage1 (1:1.1.3-2) ... +Setting up libxdmcp6 (1:1.1.0-3) ... +Setting up libxext6 (2:1.3.0-3) ... +Setting up libxfixes3 (1:5.0-4) ... Setting up libxfont1 (1:1.4.3-2) ... -Setting up libxft2 (2.2.0-2) ... -Setting up libxi6 (2:1.4.2-1) ... -Setting up libxinerama1 (2:1.1.1-1) ... +Setting up libxft2 (2.2.0-3) ... +Setting up libxi6 (2:1.4.3-3) ... +Setting up libxinerama1 (2:1.1.1-3) ... Setting up libxkbfile1 (1:1.0.7-1) ... Setting up libxml2 (2.7.8.dfsg-3) ... Setting up libxmu6 (2:1.1.0-2) ... Setting up libxmuu1 (2:1.1.0-2) ... Setting up libxpm4 (1:3.5.9-1) ... -Setting up libxrandr2 (2:1.3.1-1) ... -Setting up libxrender1 (1:0.9.6-1) ... -Setting up libxt6 (1:1.1.1-1) ... -Setting up libxxf86vm1 (1:1.1.1-1) ... -Setting up libyaml-perl (0.72-1) ... +Setting up libxrandr2 (2:1.3.1-2) ... +Setting up libxrender1 (1:0.9.6-2) ... +Setting up libxt6 (1:1.1.1-2) ... +Setting up libxxf86vm1 (1:1.1.1-2) ... +Setting up libyaml-perl (0.73-1) ... Setting up man-db (2.6.0.2-1) ... Setting up po-debconf (1.0.16+nmu1) ... Setting up shared-mime-info (0.90-1) ... @@ -103,4 +103,4 @@ Setting up xfonts-utils (1:7.6~1) ... Setting up xkb-data (2.1-2) ... Setting up xserver-common (2:1.10.2-1) ... -Setting up xvfb (2:1.10.2-1) ... +Setting up xvfb (2:1.10.2-1+b1) ... signature.asc Description: Digital signature
Bug#630618: [INTL:es] Spanish debconf translation for shadow
The subject of the report is wrong, I made a mistake when I sent it. It's not the Spanish debconf translation, it's the Spanish translation. Sorry. -- Saludos Fran -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578056: EQ overflowing. The server is probably stuck in an infinite loop.
On 2011-06-16 00:39 +0200, Thomas PIERSON wrote: > I have the same issue : > * window manager: gnome2 > * no reaction on keypress or mouse click > * mouse pointer still moves > * could not change to another tty with ctrl-alt-F[1-6] You are seeing the same symptom, but that does not necessarily mean that it is the same problem. See http://nouveau.freedesktop.org/wiki/TroubleShooting#Igetthe.22EQoverflowing.22error for more explanations. > I use a kernel 2.6.39-2 . > I attach a xorg-log which contain the crash. Thanks. This looks somewhat odd to me: > [ 113.586] Segmentation fault at address 0x3393938 > [ 113.586] > Fatal server error: > [ 113.586] Caught signal 11 (Segmentation fault). Server aborting > [ 113.586] > [ 113.586] > Please consult the The X.Org Foundation support >at http://wiki.x.org > for help. > [ 113.586] Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > [ 113.586] > [ 142.490] [mi] EQ overflowing. The server is probably stuck in an infinite > loop. How come that the X server tries to continue after the segfault? > Is there any news about upstream fixes for this bug? > Do you need any logs? You could try to debug the problem yourself, please see http://pkg-xorg.alioth.debian.org/howto/use-gdb.html for instructions. Trying different kernels might also be useful. In any case, please open a new bug if you find out anything interesting. The current one is already unusable. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630214: libapt-inst1.2: file conflict with apt 0.8.14.1 (/usr/share/locale/vi/LC_MESSAGES/libapt-inst1.2.mo)
retitle 630214 libapt-inst1.2: missing Breaks against apt versions from before the split severity 630214 important found 630214 apt/0.8.15~exp2 quit Hi again, Jonathan Nieder wrote: > Based on the changelog entry > >* debian/control: > - add libapt-pkg4.10 and libapt-inst1.2 library packages > > I am guessing there is a missing Breaks+Replaces. Looking over the debdiff, I see a Replaces now but not a Breaks. The Replaces is tracked in Bug#630204 (thanks, Shirish!), so I'll recycle this bug to track the Breaks. As mentioned in policy §7.6.1 (Overwriting files in other packages), a person trying the sequence: - unpack new libapt-inst1.2 - remove new libapt-inst1.2 in the process of recovering from a failing upgrade will find that /usr/lib/libapt-inst.so.1.2.0 goes missing, and a Breaks is recommended to avoid that. On the other hand, with Breaks, a friendly package manager might update apt first, meaning files are missing in the window between when new apt is unpacked and libapt-inst1.2 is unpacked. (This is _always_ a possibility with Breaks+Replaces, hence probably a policy bug.) I suppose my knee-jerk suggestion would be to make libapt-inst1.2 Breaks: apt (pre-split) and Replaces: apt (unversioned), to install the same files in apt, and to raise a policy bug to fix the advice in §7.6.1. Other ideas welcome, too, of course. Thanks and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630669: [l10n] Updated Czech translation of resolvconf debconf messages
Package: resolvconf Severity: wishlist Tags: l10n, patch Hi, in attachement there is updated Czech (cs.po) translation of resolvconf debconf messages. Please include it with the package. Thanks -- Miroslav Kure # Czech translation of resolvconf debconf templates # Copyright (C) 2008, 2011 Miroslav Kure # This file is distributed under the same license as the resolvconf package. # msgid "" msgstr "" "Project-Id-Version: resolvconf 1.52\n" "Report-Msgid-Bugs-To: resolvc...@packages.debian.org\n" "POT-Creation-Date: 2011-05-31 20:26+0200\n" "PO-Revision-Date: 2011-06-15 15:02+0200\n" "Last-Translator: Miroslav Kure \n" "Language-Team: Czech \n" "Language: cs\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:2001 msgid "Prepare /etc/resolv.conf for dynamic updates?" msgstr "Připravit /etc/resolv.conf pro dynamické aktualizace?" #. Type: boolean #. Description #: ../templates:2001 msgid "" "The resolvconf package contains the infrastructure required for dynamic " "updating of the resolver configuration file. Part of the necessary " "infrastructure is a symbolic link from /etc/resolv.conf to /etc/resolvconf/" "run/resolv.conf. If you choose this option then this link will be created; " "the existing /etc/resolv.conf file will be preserved as /etc/resolvconf/" "resolv.conf.d/original, and will be restored if this package is removed." msgstr "" "Balík resolvconf obsahuje infrastrukturu vyžadovanou pro dynamické " "aktualizace konfiguračního souboru resolveru. Součástí infrastruktury je i " "symbolický odkaz z /etc/resolv.conf na /etc/resolvconf/run/resolv.conf. " "Pokud budete souhlasit, odkaz se vytvoří automaticky. Stávající /etc/resolv." "conf bude zachován jako /etc/resolvconf/resolv.conf.d/original a při " "odstranění balíku bude obnoven." #. Type: boolean #. Description #: ../templates:2001 msgid "" "Declining this option will prevent future installations from recreating the " "symbolic link and therefore the resolver configuration file will not be " "dynamically updated. Dynamic updating can then be activated following " "instructions in the README file." msgstr "" "Zamítnutí této volby zabrání budoucím instalacím, aby vytvářely symbolický " "odkaz, v důsledku čehož nebude konfigurační soubor resolveru aktualizován " "dynamicky. Pro aktivování dynamických aktualizací postupujte dle instrukcí v " "souboru README." #. Type: boolean #. Description #: ../templates:2001 msgid "" "The presence of resolvconf can affect the behavior of other programs, so it " "should not be left installed if unconfigured." msgstr "" "Přítomnost resolvconfu může ovlivnit chování ostatních programů, takže pokud " "balík nenastavíte, měli byste jej raději odinstalovat." #. Type: note #. Description #. Type: note #. Description #: ../templates:3001 ../templates:4001 msgid "Reboot recommended" msgstr "Doporučuje se restartovat systém" #. Type: note #. Description #: ../templates:3001 msgid "" "Suppliers of name server information such as local caching name servers and " "interface configurers are expected to supply name server information to the " "resolvconf program. However, although installation of the resolvconf package " "triggers them to supply their information, some of them fail to do so." msgstr "" "resolvconf očekává, že mu informace o jmenných serverech poskytnou programy " "k tomu určené, jako jsou lokální cachovací jmenné servery nebo programy pro " "konfiguraci síťových rozhraní. Přestože si od nich resolvconf při instalaci " "tyto informace vyžádá, některé programy bohužel neodpoví." #. Type: note #. Description #: ../templates:3001 msgid "" "This bug would lead to loss of valid name server information on installation " "of the resolvconf package if the following workaround were not adopted: " "resolvconf includes the full contents of the pre-installation /etc/resolv." "conf in its database until reboot. This has the drawback that name server " "information is retained even if the associated interface is later " "deconfigured. (This incorrect behavior is judged to be less harmful than the " "alternative of losing valid information.)" msgstr "" "Tato chyba by při instalaci resolvconfu vedla ke ztrátě informací o platném " "jmenném serveru a proto existuje následující obezlička: resolvconf až do " "restartu ve své databázi uchová kompletní obsah souboru /etc/resolv.conf z " "doby před instalací resolvconfu. To má nevýhodu v tom, že pokud je příslušné " "síťové rozhraní vypnuto, informace o svázaném jmenném serveru v resolvconfu " "zůstává, což je považováno za menší zlo, než ztráta platné informace." #. Type: note #. Description #: ../templates:3001 msgid "" "Until the bug in question is fixed and the workaround removed, the only way " "to ensure that resolvconf has fully correct name server information after " "the resolvconf package has been installed on a running system is to reboot " "the system." msgstr "
Bug#630668: fai-server: fai-chboot and DNS entries with AAAA, do not work
Package: fai-server Severity: normal Tags: ipv6 Pretty simple: # getent hosts lava 2001:551:610a:712:313:6555:face:abec lava.example.com # host lava lava.example.com has address 10.3.2.41 lava.example.com has IPv6 address 2001:551:610a:712:313:6555:face:abec # fai-chboot -d lava Bad arg length for Socket::inet_ntoa, length is 16, should be 4 at /usr/sbin /fai-chboot line 69. # # grep hosts /etc/nsswitch.con hosts: files dns # cat /etc/host.conf multi on # cat /etc/resolv.conf search example.com nameserver ::1 nameserver 141.11.31.41 options inet6# removing this do not change anything # grep -v '^#' /etc/gai.conf (empty) # I have nscd (nslcd in fact) deamon running. But after stoping it behaviour is the same. I have read a source file of fai-chboot and it looks OK, but for some reason (similary to getent above) a branch with one revoled address is taken, not two. Maybe some problem in perl's gethost function? -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630192: unattended-upgrades: AttributeError: 'module' object has no attribute 'Config'
found 630192 0.72.2
stop
Sorry, seems the adaptations for the new python-apt 0.8 API are not
complete after all:
# unattended-upgrade -d
Initial blacklisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,label=Debian-Security,archive=stable',
'o=Debian,a=stable', 'o=Debian,a=testing']
Traceback (most recent call last):
File "/usr/bin/unattended-upgrade", line 737, in
main(options)
File "/usr/bin/unattended-upgrade", line 497, in main
if (is_dpkg_journal_dirty() and
File "/usr/bin/unattended-upgrade", line 82, in is_dpkg_journal_dirty
apt_pkg.Config.find_file("Dir::State::status"))+"/updates"
AttributeError: 'module' object has no attribute 'Config'
NB: This is with python-apt version 0.8.0 installed
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629956: apt: apt-cache fails with current fakeroot
Hey Jonathan, Jonathan Nieder [2011-06-15 16:11 -0500]: > One approach would be to say that running a typical test suite is not > something fakeroot can fully support Note that this isn't really a test suite problem -- it applies to a plain "fakeroot apt-cache", which could be done in any kind of package build, or worse, in "fakeroot fakechroot" environments where you actually have a work environment. It's trivial to work around it in test suites, but harder to do in fakechroot environments. > - on the other hand, it can be used as in Martin's example test >suite, to opportunistically say "If I have permission to make >something --- e.g., a cache --- in the system a little better, >let me actually do that". Right, that's how apt-cache seems to use it (again, it's nothing to do with my test suite, that was just a place where I noticed it). As a check like if (access(file)) if (open() < 0) error_handling else no_perm_fallback() is usually bad programming style due to race conditions, as you already said, I filed the bug against apt and not fakeroot. It's usually better to do if (open() < 0) if (errno == EPERM) no_perm_fallback() else error_handling > But we live in the real world. Maybe it would be best to revert the > change in sid and introduce it in experimental, to get a better sense > of whether the weight of the impact goes one way or another. > > Anyway, Clint, please feel free to revert the change. I'll think > more. Let's not get in a hurry here. I deliberately filed the bug as "minor" and against apt, not fakeroot. If the apt maintainers are okay with changing the code to not use access() at all here, we can make both use cases work. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#630624: postgresql-9.1: ..automate the "please dump your 9.1 clusters first and remove them..." step?
Hello Arnt, Arnt Karlsen [2011-06-15 18:42 +0200]: > Package: postgresql-9.1 > Version: 9.1~beta1-4 > Severity: wishlist > > > ...automating the "please dump your 9.1 clusters first and remove them..." > step, > e.g. with a big blue screen to scare the people who are not sure they have no > important pg-9.1 databases, would allow us who knows we can nuke our old > data, > the optional "yes, nuke my old junk data" button. ;o) I knew someone would ask for that, but I won't work on it myself. This is an experimental package, and the DB format won't change any more after the first release candidate, so it will only be useful for these one or two testing versions. So the effort/benefit ratio is fairly small here. Patches accepted, though :) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630667: Installs files under / and /yapra directly
Package: yapra Version: 0.1.2-3 Severity: grave While looking at the Contents file, I noticed something strange at the end of it. Running dpkg-deb -c confirmed it. Following is an excerpt from dpkg-deb -c. -rw-r--r-- root/root 1042 2010-10-18 10:28 ../usr/share/man/man1/yapra.1.gz drwxr-xr-x root/root 0 2010-10-18 10:28 ./yapra/ -rw-r--r-- root/root 2326 2010-10-18 10:28 ./yapra/config.rb -rw-r--r-- root/root69 2010-10-18 10:28 ./yapra/legacy_plugin.rb drwxr-xr-x root/root 0 2010-10-18 10:28 ./yapra/legacy_plugin/ -rw-r--r-- root/root 1351 2010-10-18 10:28 ../yapra/legacy_plugin/advance_mode_registry.rb -rw-r--r-- root/root 1299 2010-10-18 10:28 ../yapra/legacy_plugin/compatible_mode_registry.rb -rw-r--r-- root/root 670 2010-10-18 10:28 ../yapra/legacy_plugin/base.rb -rw-r--r-- root/root 917 2010-10-18 10:28 ../yapra/legacy_plugin/registry_factory.rb drwxr-xr-x root/root 0 2010-10-18 10:28 ./yapra/plugin/ -rw-r--r-- root/root 347 2010-10-18 10:28 ../yapra/plugin/erb_applier.rb -rw-r--r-- root/root 952 2010-10-18 10:28 ../yapra/plugin/mechanize_base.rb -rw-r--r-- root/root 308 2010-10-18 10:28 ../yapra/plugin/context_aware.rb -rw-r--r-- root/root 468 2010-10-18 10:28 ./yapra/plugin/base.rb -rw-r--r-- root/root 436 2010-10-18 10:28 ../yapra/plugin/feed_item_operator.rb -rw-r--r-- root/root 1986 2010-10-18 10:28 ./yapra/inflector.rb -rw-r--r-- root/root 3847 2010-10-18 10:28 ./yapra/pipeline.rb -rw-r--r-- root/root 1484 2010-10-18 10:28 ./yapra/runtime.rb -rw-r--r-- root/root 136 2010-10-18 10:28 ./yapra/version.rb -rw-r--r-- root/root42 2010-10-18 10:28 ./yapra/plugin.rb -rw-r--r-- root/root 1690 2010-10-18 10:28 ./yapra.rb -- System Information: Debian Release: squeeze/sid APT prefers natty-updates APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-8-generic (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630666: multiarch breaks webgl in chromium
Source: mesa Version: 7.10.2-4 My video card is a nVidia one. Webgl in chromium run smoothly with mesa <= 7.10.2-3. After upgrading to 7.10.2-4 and 7.10.3-1, chromium just complain that it do not support webgl. However, chrome://gpu-internals/ still show that everything is "Hardware accelerated". I had tried to symlink so files to /usr/lib, but the error remains. I dropped all multiarch diffs and rebuild mesa, webgl works again with mesa 7.10.3. I think chromium uses dlopen() tricks, but I have no idea why symlinks do not work for it. test page for webgl: http://www.khronos.org/webgl/wiki/Demo_Repository -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630550: Withdraw bug report-fixed manually with "aptitude -r"
Bug still exists, but manually fixed using "aptitude -r" . No reply necessary. There were KDE library dependencies that were preventing update manager from updating. I discovered the issue using command line "aptitude -r" and removed the KDE programs that were causing the update manager to stall. The problem of "update manager" not giving a clue to the problem still exists, but my problem has been solved. Thank you, Keep Debianing - Original Message -From: ow...@bugs.debian.org (Debian Bug Tracking System)Date: Wednesday, June 15, 2011 1:03 amSubject: Bug#630550: Acknowledgement (updatemanager: Update manager stalls)To: GregM > Thank you for filing a new Bug report with Debian.> > This is an automatically generated reply to let you know your message> has been received.> > Your message is being forwarded to the package maintainers and other> interested parties for their attention; they will reply in due course.> > As you requested using X-Debbugs-CC, your message was also > forwarded to> countergu...@optonline.net> (after having been given a Bug report number, if it did not have one).> > Your message has been sent to the package maintainer(s):> unknown-pack...@qa.debian.org> > If you wish to submit further information on this problem, please> send it to 630...@bugs.debian.org.> > Please do not send mail to ow...@bugs.debian.org unless you wish> to report a problem with the Bug-tracking system.> > -- > 630550: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630550> Debian Bug Tracking System> Contact ow...@bugs.debian.org with problems>
Bug#630665: minissdpd: exits if the network is not up when it starts
Package: minissdpd Version: 1.0-2 Severity: normal minissdpd exits if the network is not up when it starts and does not start when NetworkManager has finally started the network up. I think minissdpd should just wait for network before binding to ports: minissdpd[1011]: setsockopt(udp, IP_ADD_MEMBERSHIP): No such device minissdpd[1011]: Failed to add membership for address 0.0.0.0. EXITING minissdpd[1011]: Cannot open socket for receiving SSDP messages, exiting -- System Information: Debian Release: wheezy/sid APT prefers experimental APT policy: (1900, 'experimental'), (1800, 'unstable'), (1700, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minissdpd depends on: ii libc6 2.13-7 Embedded GNU C Library: Shared lib -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#630664: gtk-recordmydesktop: advanced button not functional
Package: gtk-recordmydesktop Version: 0.3.8-3 Severity: important clicking the gtk-recordmydesktop advanced button does not bring up the options window to set program options. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gtk-recordmydesktop depends on: ii python 2.6.6-3+squeeze6interactive high-level object-orie ii python-gtk2 2.17.0-4Python bindings for the GTK+ widge ii python-support 1.0.10 automated rebuilding support for P ii recordmydesktop 0.3.8.1+svn602-1+b1 Captures audio-video data of a Lin gtk-recordmydesktop recommends no packages. gtk-recordmydesktop suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628339: licq: FTBFS: convert: missing an image filename `debian/licq/usr/share/pixmaps/licq.xpm'
tag 628339 patch
thanks
Hi,
I created the patch that revise this bug.
I attached.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
diff -Nru licq-1.5.0/debian/control licq-1.5.0/debian/control
--- licq-1.5.0/debian/control 2010-10-03 19:24:40.0 +0900
+++ licq-1.5.0/debian/control 2011-06-16 11:34:32.0 +0900
@@ -1,5 +1,5 @@
Source: licq
-Build-Depends: cdbs (>= 0.4.52), cmake (>= 2.6.0), debhelper (>= 6.0.7), imagemagick, kdebase-data (>= 4:4.0.0), kdelibs5-dev, libboost-dev (>= 1.33.1), libcdk5-dev, libgloox-dev (>= 1.0), libgpgme11-dev (>= 0.4.2), libgtest-dev (>= 1.5.0), libhunspell-dev, libncurses5-dev, libqt4-dev (>= 4.3.0), libssl-dev, libxosd-dev (>= 2.1.0), libxss-dev, qt4-dev-tools
+Build-Depends: cdbs (>= 0.4.52), cmake (>= 2.6.0), debhelper (>= 6.0.7), imagemagick, kdebase-data (>= 4:4.0.0), kdelibs5-dev, libboost-dev (>= 1.33.1), libcdk5-dev, libgloox-dev (>= 1.0), libgpgme11-dev (>= 0.4.2), libgtest-dev (>= 1.5.0), libhunspell-dev, libncurses5-dev, libqt4-dev (>= 4.3.0), libssl-dev, libxosd-dev (>= 2.1.0), libxss-dev, qt4-dev-tools, oxygen-icon-theme
Section: net
Priority: optional
Maintainer: Erik Johansson
diff -Nru licq-1.5.0/debian/rules licq-1.5.0/debian/rules
--- licq-1.5.0/debian/rules 2010-10-03 19:24:40.0 +0900
+++ licq-1.5.0/debian/rules 2011-06-16 11:35:17.0 +0900
@@ -109,6 +109,6 @@
install-licq-common::
$(DEB_MAKE_ENVVARS) $(MAKE) -C $(CMAKE_BUILDDIR) install DESTDIR=$(CURDIR)/debian/licq
mkdir -p debian/licq/usr/share/pixmaps
- convert /usr/share/icons/oxygen/32x32/apps/licq.png debian/licq/usr/share/pixmaps/licq.xpm
+ convert /usr/share/icons/oxygen/48x48/actions/im-icq.png debian/licq/usr/share/pixmaps/licq.xpm
mkdir -p debian/licq-dev/usr
mv debian/licq/usr/include debian/licq-dev/usr/include
Bug#630415: guile-1.8: Enable thread support
Michael Terry writes: > In Ubuntu, I was rebasing to Debian and noticed that the only difference we > still held was the attached patch to enable thread support. Seems like > something Debian would want too? > > The original notice for this change was: > > - Build with thread support. Some guile-using programs like autogen need > it. > - Add debian/guile-1.8-libs.shlibs: Thread support breaks ABI, bump the > soname. > > Thanks for considering the patch. I'll have to look at the patch, but the original reason I never supported 1.8 threads in Debian is because I released a version without threads -- threads were broken early on, and a releasing a newer threaded version would break the ABI. I see from the comment above that the ABI was bumped, but I'll have to examine how that was done. Previously, I couldn't bump the soname because it might conflict with the 2.0 sonames, once 2.0 was released. I haven't checked to see what they chose yet. In any case, my current plan is just to finish packaging 2.0, which will have threads, and then start planning the removal of 1.8. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630663: [approx] approx-import refuses to import arch-indep debs that are named as arch-dep debs
Package: approx Version: 4.6-1 Severity: minor --- Please enter the report below this line. --- I've recently installed approx. Mostly, I have been very happy with its performance and usefulness. One thing troubled me: I was getting 120 +/- packages not imported from the existing apt cache. As I tracked down the problem, I noticed that theses same packages were also being flagged as improperly named (such as debian-reference-en_2.46_amd64.deb, but should be named debian-reference_2.46_all.deb).Two copies existed in the cache that were the same size and returned the same md5sum; this was true for most packages that were failing to be imported by approx-import. A few were older versions that should have purged with `apt-get autocleaned`, but perhaps the wrong naming prevented apt from seeing them. So, for each package failing to import, I removed the improperly named deb and then approx-import did it's job just fine. This problem was a bit frustrating, but all in all, I'm actually glad approx-import refused to import the problem packages. I realise this may seem like a non-issue to you, but I guess I think of approx as having helped me fix a small problem. I also thought that if this could happen to me, it might happen to others. So perhaps this bug report should just be closed at your own convenience. But, at least someone else might benefit from my troubles. Thanks for approx! It's great to have a program that does so much: caching proxy as well as a local repo maintainer. Good job. Respectfully, John Vogel --- System information. --- Architecture: amd64 Kernel: Linux 2.6.39-2-amd64 Debian Release: wheezy/sid 500 unstablelocalhost 500 testing localhost 500 experimentallocalhost 1 experimentallocalhost --- Package information. --- Depends (Version) | Installed ===-+-=== debconf (>= 0.5) | 1.5.39 OR debconf-2.0 | libc6 (>= 2.7) | 2.13-7 libpcre3 (>= 8.10) | 8.12-3 adduser | 3.113 bzip2 | 1.0.5-6 curl| 7.21.6-1 openbsd-inetd | OR inet-superserver| update-inetd| 4.38+nmu1 Package's Recommends field is empty. Suggests (Version) | Installed ==-+-=== libconfig-model-approx-perl| 1.003-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#303145: [Pkg-openssl-devel] Bug#303145: Patch
On 06/13/2011 10:08 PM, Scott Schaefer wrote:
On 06/13/2011 06:10 AM, Kurt Roeckx wrote:
On Fri, May 06, 2011 at 08:35:57AM -0400, Scott Schaefer wrote:
See attached. Prints "completion" message only on successful return.
Also fixes bug which prevents executing -newreq-nodes option, and
includes newer options in usage message.
Can you also check the CA.sh script for the same problems?
Kurt
I will be glad to submit patch for CA.sh, since, on quick review, it
indeed has same two problems as CA.pl; i.e.
1) It prints "success" messages, even on failure of underlying SSL
command(s), and
2) The usage message in lacking the newer, added valid arguments,
This will probably require 24-48 hours, since I have travel commitment
tomorrow.
OTOH, my assertion that my original patch for CA.pl 'fixes bug which
prevents executing -newreq-nodes option' is WRONG. I badly misread
that code in order to conclude what I did; i.e. the original code does
execute both -newreq and -newreq-nodes options correctly.
Note the patch still correctly executes both options, and both did
incorrectly print "success" message even on failure of underlying SSL
command. For this reason, I would prefer to leave the patch intact,
and simply change the second part of the description to only "Also
includes newer options in usage message". If you prefer, I can submit
revised patch file that does not re-order the testing of command-args
vs patterns /^-newreq$/ and/^-newreq-nodes$/.
Attached are two patches. The first is a replacement for the original
and applies to CA.pl. The second is new, and applies to CA.sh.
Please note that both of these are less-than-thoroughly tested. I have
verified most of the functionality, but not all of the boundary cases
which I would normally test before releasing as production code. In
addition, the original(s) had some inconsistencies and unclear design
choices which I am not certain I understand the rationale for.
However, I am starting my first vacation of more than three days in over
six years tomorrow morning, and will be unable to test any more until my
return.
diff --git a/apps/CA.pl b/apps/CA.pl
--- a/apps/CA.pl
+++ b/apps/CA.pl
@@ -44,6 +44,26 @@
$ENV{OPENSSL} = $openssl;
}
+sub system_command() {
+my $cmd = shift;
+my $ret = 2;
+if ($cmd) {
+system($cmd);
+if ($? == -1) {
+print "ERROR: Failed to execute: $cmd\n";
+exit 1;
+}
+elsif ($? & 127) {
+printf "ERROR: Process died with signal %d, %s coredump\n",($? & 127),(($? & 128) ? 'with' : 'without');
+exit 1;
+}
+else {
+$ret = $? >> 8;
+}
+}
+$ret;
+}
+
$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};
$DAYS="-days 365"; # 1 year
$CADAYS="-days 1095"; # 3 years
@@ -62,25 +82,39 @@
$RET = 0;
+$USAGE = <<"_USAGE_";
+usage: $0 -newcert | -newreq | -newreq-nodes | -newca |
+ -sign | -signreq | -signCA | -signcert | -xsign | pkcs12 | -verify
+_USAGE_
+$HELP_USAGE = <<"_HELP_USAGE_";
+usage: $0 option
+ Valid options
+-newca : Create local CA directory structure
+-newcert : Create certficate
+-newreq|-newreq-nodes : Create certficate request
+-sign|-signreq|-signCA|-signcert|-xsign : Sign cert/request
+-pkcs12 name (default='My Certificate') : Create PKCS-12 certificate
+-verify [file [file]]: Verifiy certificate(s); newcert.pem if no file(s)
+_HELP_USAGE_
+
+
foreach (@ARGV) {
+$result='';
if ( /^(-\?|-h|-help)$/ ) {
- print STDERR "usage: CA -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify\n";
+ print STDERR $HELP_USAGE;
exit 0;
} elsif (/^-newcert$/) {
# create a certificate
- system ("$REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS");
- $RET=$?;
- print "Certificate is in newcert.pem, private key is in newkey.pem\n"
+ $RET=&system_command("$REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS");
+ $result="Certificate is in newcert.pem, private key is in newkey.pem";
} elsif (/^-newreq$/) {
# create a certificate request
- system ("$REQ -new -keyout newkey.pem -out newreq.pem $DAYS");
- $RET=$?;
- print "Request is in newreq.pem, private key is in newkey.pem\n";
+ $RET=&system_command("$REQ -new -keyout newkey.pem -out newreq.pem $DAYS");
+ $result="Request is in newreq.pem, private key is in newkey.pem";
} elsif (/^-newreq-nodes$/) {
# create a certificate request
- system ("$REQ -new -nodes -keyout newkey.pem -out newreq.pem $DAYS");
- $RET=$?;
- print "Request is in newreq.pem, private key is in newkey.pem\n";
+ $RET=&system_command("$REQ -new -nodes -keyout newkey.pem -out newreq.pem $DAYS");
+ $result="Request is in newreq.pem, private key is in newkey.pem";
} elsif (/^-newca$/) {
# if explicitly asked for or it doesn't exist then setup the
# directory structure that Eric likes to manage things
@@
Bug#629329: pu: package sphinx/0.6.6-3+squeeze1
* Adam D. Barratt , 2011-06-14, 21:06:
I'd like to upload new version of Sphinx into s-p-u, which fixes
compatibility with jQuery >= 1.4. (Upstream ships a copy of jQuery
1.2.6, but in Debian we use the packaged one, which is 1.4.2 in
squeeze.)
I'm guessing there's no easy way to have the newer jQuery support both
versions of the syntax? (Hey, it can't hurt to ask...)
Hmm, I didn't even think about this possibility, as JavaScript is not my
favourite programming language. But it turns out that in fact it's quite
easy to fix the issue in jQuery; please see the attached patch. (Only
the second file is actually used at build time, but I wanted to keep
them in sync.)
However, I am a bit wary of patching jQuery, because it's definitely
Sphinx is at fault here: the methods that disappeared were clearly
marked as "for internal use only" in the jQuery code.
Also, the patch only does the trick if the documentation was built with
a reasonably recent version of Sphinx. Apparently Sphinx 0.5.x had its
own incompatibilities with jQuery 1.4, which I'm not really willing to
investigate...
There are 55 documentation packages in squeeze affected by this bug.
Unfortunately, the sole upload of Sphinx won't automatically fix them,
as they ship copies of broken javascript code. :(
As I understand it, most of the affected packages are arch:all, so we
can't simply fix the issues via a mass binNMU.
Actually I misread my notes when I was writing the original mail: the
number of affected packages is 65 (55 arch:all + 10 arch:any). However,
upon further inspection I discovered that, due to various packaging bugs,
search function is broken in 48 of them anyway. That leaves us with 15
arch:all packages and 2 binNMUable ones. Two of the arch:all packages
would have to be rebuilt regardless of whether we decide to patch jQuery
or not.
Here are lists of source packages that could be fixed:
arch:all, built with ancient Sphinx (can be fixed only by sourceful
upload):
- argvalidate
- ipython
arch:all, built with recent Sphinx (can be fixed either by sourceful
upload or by patching jQuery):
- ganeti
- libvigraimpex
- mlpy
- nipy
- nipype
- pam-python
- python-apsw
- python-djvulibre
- python-whoosh
- python2.6
- python3.1
- scikit-learn
- update-manager
arch:any, built with recent Sphinx (can be fixed either by binNMU or by
patching jQuery):
- fityk
- pynifti
I don't suppose you fancy no-change-NMUing 55 packages? ;-)
TBH, I was secretly hoping thay you say NACK for updating documentation
packages. ;)
--
Jakub Wilk
--- jquery-1.4.2.orig/src/core.js
+++ jquery-1.4.2/src/core.js
@@ -342,6 +342,13 @@
};
jQuery.extend({
+ className: {
+ // Forward-ported from jQuery 1.2.6 to work around Debian bug #628642
+ has: function( elem, className ) {
+ return jQuery.inArray( className, (elem.className || elem).toString().split(/\s+/) ) > -1;
+ }
+ },
+
noConflict: function( deep ) {
window.$ = _$;
--- jquery-1.4.2.orig/dist/jquery.js
+++ jquery-1.4.2/dist/jquery.js
@@ -359,6 +359,13 @@
};
jQuery.extend({
+ className: {
+ // Forward-ported from jQuery 1.2.6 to work around Debian bug #628642
+ has: function( elem, className ) {
+ return jQuery.inArray( className, (elem.className || elem).toString().split(/\s+/) ) > -1;
+ }
+ },
+
noConflict: function( deep ) {
window.$ = _$;
Bug#630662: libdeal.ii-dev: missing libtrilinos_*.so.10.0 linkage
Package: libdeal.ii-dev Version: 6.3.1-1 Severity: normal When I try to compile /usr/share/doc/deal.ii-examples/step-1, I get complaints about missing trillinos libraries and ultimately, the example does not compile. $ make Makefile:151: Makefile.dep: No such file or directory Remaking Makefile.dep ==optimized= step-1.cc Linking step-1 /usr/bin/ld: warning: libtrilinos_stratimikosamesos.so.10.0, needed by /usr/lib/libdeal_II_2d.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libtrilinos_stratimikosaztecoo.so.10.0, needed by /usr/lib/libdeal_II_2d.so, not found (try using -rpath or -rpath-link) and so on. Indeed ldd /usr/lib/libdeal_II_2d.so shows a bunch of "not found" trilinos 10.0 libraries. It appears that the current version of libtrillinos=10.4.0.dfsg-1 no longer contains 10.0 libraries, but instead only 10.4. The libdeal.ii-dev package however claims to be compatible with libtrilinos-dev (>= 9.0.2.dfsg-3). I have confirmed that rebuilding the package solves the problem. Kevin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (400, 'stable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc3.00 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libdeal.ii-dev depends on: ii libblas-dev1.2-8 Basic Linear Algebra Subroutines 3 ii libboost-dev 1.46.1.1 Boost C++ Libraries development fi ii libdeal.ii6.3.16.3.1-1 Finite element library - shared li ii liblapack-dev 3.2.1-8 library of linear algebra routines ii libnetcdf-dev 1:4.1.1-5 Development kit for NetCDF ii libpetsc3.1-dev3.1.dfsg-11 Static libraries, shared links, he ii libscotchmetis-dev 5.1.11.dfsg-7 programs and libraries for graph, ii libslepc3.0.0-dev 3.0.0-p7.dfsg-7.1 Scalable Library for Eigenvalue Pr ii libsuitesparse-dev 1:3.4.0-2 libraries for sparse matrices comp ii libtbb-dev 3.0+r147-1parallelism library for C++ - deve ii libtrilinos-dev10.4.0.dfsg-1 parallel solver libraries within a libdeal.ii-dev recommends no packages. Versions of packages libdeal.ii-dev suggests: pn deal.ii-doc(no description available) ii deal.ii-examples 6.3.1-1Finite element library - documenta pn libdeal.ii-dbg (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462731: Current maintainer - I just found this bug
Quarry uses the GTK+ theme application font, so when you change the font size for your GTK+ desktop apps, Quarry should follow suit. Now the bad news: it might not work in Gnome 3 - I don't even know where to set the font there. But at the time this bug was submitted (and still if using Gnome/GTK+ 2), changing the GTK+ setting was 100% the correct solution. It should be (or have been, at least) under Gnome Control Center / Appearance. Hope this helps.
Bug#630661: further notifications about shutdown flags that can only be used along with -h flag.
Source: sysvinit
Version: 2.88dsf-13.10
Severity: normal
Tags: patch
Please further notify about shutdown flags that can only be used along with -h
flag.
--- man/shutdown.8 2010-03-23 16:37:01.0 +0200
+++ man/shutdown.8.new 2011-06-16 03:24:25.0 +0300
@@ -70,7 +70,8 @@
.\"}}}
.\"{{{ -P
.IP \fB\-P\fP
-Halt action is to turn off the power.
+Modifier to the -h flag. Halt action is to turn off the power.
+Must be used with the -h flag.
.\"}}}
.\"{{{ -H
.IP \fB\-H\fP
In addition, removes the obsolete usage comment at the beginning of
src/shutdown.c
--- src/shutdown.c 2011-06-16 03:21:58.0 +0300
+++ src/shutdown.c.new 2011-06-16 03:21:08.0 +0300
@@ -1,15 +1,7 @@
/*
* shutdown.c Shut the system down.
*
- * Usage: shutdown [-krhfnc] time [warning message]
- * -k: don't really shutdown, only warn.
- * -r: reboot after shutdown.
- * -h: halt after shutdown.
- * -f: do a 'fast' reboot (skip fsck).
- * -F: Force fsck on reboot.
- * -n: do not go through init but do it ourselves.
- * -c: cancel an already running shutdown.
- * -t secs: delay between SIGTERM and SIGKILL for init.
+ * Usage: See the usage function in this file.
*
* Author: Miquel van Smoorenburg, miqu...@cistron.nl
*
@@ -124,12 +116,15 @@
{
fprintf(stderr,
"Usage:\t shutdown [-akrhPHfFnc] [-t sec] time [warning message]\n"
+ " \t -H and -P flags can only be used along with -h fl
ag.\n"
"\t\t -a: use /etc/shutdown.allow\n"
"\t\t -k: don't really shutdown, only warn.\n"
"\t\t -r: reboot after shutdown.\n"
"\t\t -h: halt after shutdown.\n"
- "\t\t -P: halt action is to turn off power.\n"
- "\t\t -H: halt action is to just halt.\n"
+ "\t\t\t-P: halt action is to turn off power.\n"
+ "\t\t\t can only be used along with -h flag.\n"
+ "\t\t\t-H: halt action is to just halt.\n"
+ "\t\t\t can only be used along with -h flag.\n"
"\t\t -f: do a 'fast' reboot (skip fsck).\n"
"\t\t -F: Force fsck on reboot.\n"
"\t\t -n: do not go through \"init\" but go down real fast.\n"
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630660: [golang] missing determiner in extended description "guarantees that full Go development environment is installed"
Package: golang Version: 1:57.1-4 Severity: minor The extended description starts with: This package is a metapackage that, when installed, guarantees that (almost) full Go development environment is installed. The noun phrase "full Go development environment" is missing a determiner. There is no reason to use the zero article here. You may want to add a "the" or an "a". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627007: Severe "Processor Leak" when Pointer is on GTK/GDK Window
Just found what looks suspiciously like a proverbial smoking gun on the GTK/GDK side of things. Rather contrary to my previous suspicions, disabling handling FocusOut, FocusIn, LeaveNotify and EnterNotify events failed to improve the situation. So, finally went in and tried adding "return_val=FALSEl; break;" right after the ClientMessage case in gdk/x11/gdkevents.c, just after line 2007. Suddenly the problem disappears and things seem to continue working. The problem of course is this *really* isn't the right place for a problem like this to show up. I (or someone else) will have to figure out what the heck in GTK/GDK is causing this. Looking at the patch in Tao Nelson's message on bug #266118. No, I'm pretty sure that *doesn't* solve the problem. It may work around it, by causing unclutter to go through its main loop again and inserting a delay, but that merely means the fight slows down to the point you don't notice it, I'm pretty sure it doesn't /solve/ it. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) / \_CS\ | _ -O #include O- _ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630659: ITP: ruby-pkg-config -- pkg-config implementation for Ruby
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: ruby-pkg-config Version : 1.1.2~git20110615 Upstream Author : Kouhei Sutou * URL : https://github.com/rcairo/pkg-config * License : LGPL-2.1+ Programming Lang: Ruby Description : pkg-config implementation in Ruby pkg-config can be used in your extconf.rb to properly detect neeed libraries for compiling Ruby native extensions, using the pkg-config database. Note that this package does not use pkg-config, only it's database. -- Antonio Terceiro http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Bug#630658: sbuild-createchroot succfails badly with invalid user
Package: sbuild Version: 0.62.2-1 Severity: grave Justification: Unusable, unable to create a chroot, also highly confusing. Hi. So, having faith, I purged sbuild and schroot entirely (yay for the failing delgroup call, by the way, and a different error than #619892 -- sbuild being the last remaining group for the sbuild user or something similar), trying to start afresh and without any prejudices. Now, even creating a chroot fails, or succeeds, depending on which line one reads: | [config file excerpt] | I: Please rename and modify this file as required. | mkdir /etc/sbuild/chroot | I: sudo chroot configuration linked as | /etc/sbuild/chroot/sid-amd64-sbuild. | chown: invalid user: `sbuild:sbuild' | E: Failed to set sbuild:sbuild ownership on /build | Failed to set up chroot | E: Error creating chroot session: skipping apt update | I: Successfully set up sid chroot. | I: Run "sbuild-adduser" to add new sbuild users. Looks like yet another proof of sbuild's extreme fragility. :( -- System Information: Debian Release: sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sbuild depends on: ii adduser 3.113 add and remove users and groups ii libc62.13-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-13 GCC support library ii libsbuild-perl 0.62.2-1Tool for building Debian binary pa ii libstdc++6 4.6.0-13GNU Standard C++ Library v3 ii perl 5.12.3-7+b1 Larry Wall's Practical Extraction ii perl-modules 5.12.3-7Core Perl modules Versions of packages sbuild recommends: ii debootstrap 1.0.32 Bootstrap a basic Debian system ii fakeroot 1.16-1 tool for simulating superuser priv Versions of packages sbuild suggests: pn deborphan (no description available) ii wget 1.12-3.1 retrieves files from the web -- Configuration Files: /etc/schroot/buildd/config changed [not included] /etc/schroot/buildd/copyfiles changed [not included] /etc/schroot/buildd/fstab changed [not included] /etc/schroot/buildd/nssdatabases changed [not included] ^ Also, lies. I never touched those files. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626172: aptitude, elinks: something is wrong here
Hi again, something has been done – elinks dropped the firefox dependency, which made it, and thus aptitude, buildable (although with not all B-Ds in their latest versions) on m68k again. (Haven’t got a chance to test it in action yet though, but next cowbuilder update I’ll ask one of my machines to use it for build dependency resolving again.) I still think the presence of a package that occasionally build-depends on firefox out of all things is a mistake, but feel free to reduce the severity on this one. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606309: trang ends with Bus error on kfreebsd-amd64
Hello, Ondřej Surý, le Wed 08 Dec 2010 10:30:46 +0100, a écrit : > Trang fails with Bus error when rebuilding rng files for opendnssec on > kfreebsd-amd64: and it doesn't happen on kfreebsd-i386. I'm getting the following backtrace on asdfasdf.debian.net: 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 (gdb) bt #0 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #1 0x000803cf93b8 in __pthread_wait_for_restart_signal () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #2 0x000803cf9f8c in pthread_create@@GLIBC_2.3 () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #3 0x0008029884c2 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #4 0x0008020104cf in _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, void (*)(java::lang::Thread*)) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #5 0x0008020078ea in void java::lang::Thread::start() () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #6 0x000801fbc55a in _Jv_CreateJavaVM () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #7 0x000801fbc637 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char const*, int, char const**, bool) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #8 0x000800820ce1 in main () from /usr/lib/x86_64-kfreebsd-gnu/libgij.so.12 #9 0x0008049f61e9 in __libc_start_main () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1 #10 0x0040060c in ?? () #11 0x7fffeb38 in ?? () #12 0x001c in ?? () #13 0x in ?? () (gdb) disassemble 0x000803cfa2c7 Dump of assembler code for function __pthread_sigsuspend: 0x000803cfa2c0 <+0>: mov$0x155,%eax 0x000803cfa2c5 <+5>: syscall => 0x000803cfa2c7 <+7>: retq i.e. the segfault is triggered from the kernel itself. Does anybody has any idea? I'd tend to reassign this to libgcj12 or kfreebsd-8, since there doesn't seem to be anything specific to trang in this backtrace. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630579: nvidia-glx: glx cannot be utilised
Is there a workaround we can do in the meantime, eg changing symlinks? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630641: gem2deb: duplicate install of files in lib/
Lucas Nussbaum escreveu isso aí: > Package: gem2deb > Version: 0.2.4 > Severity: important > > Hi, > > for ruby-xmlparser (found in the pkg-ruby-extras repo, not uploaded yet > because of that problem), gem2deb installs the files in lib/ to > /usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/ and > /usr/lib/ruby/vendor_ruby/1.8/x86_64-linux/. > > This might be related to the fact that extconf.rb is in the root dir. It happens exactly because of that. The extconf.rb in the root dir will be invoked once for each supported Ruby interpreter, and it will install the lib/ files in the arch-specific dirs. And if I am not mistaken, gem2deb itself will *also* install the files under lib/ to the arch-independent dir ... Moving extconf.rb and the C files to an ext/ dir it probably the best solution, and will work ok for Rubygems as well. I don't know if there is a sane way to handle this in gem2deb ... the problem is a broken upstream build system. -- Antonio Terceiro http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Bug#630118: closed by Bart Martens (updated checksums)
Perhaps you can use WWW::Mechanize and a cron job to always keep everything up to date? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630566: linux-source-2.6.39: 2.6.39-2 : bluetooth broken
Am Mittwoch, 15. Juni 2011, 13:26:50 schrieben Sie: > > did you try 3.0-rc2 in experimental? > > thanks I tried it now and the problem is the same (same error). btw. I had trouble to compile the 3.0 kernel. I needed to remove the modules apm and lguest. It also uses much more ram than 2.6.39. Probably it needs an updated kernel-package and some more work but that has nothing to do with the bluetooth problem of course. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630657: apt: [l10n:ca] Updated Catalan translation
Package: apt Version: 0.8.15~exp1 Severity: wishlist Tags: l10n Hi, Attached is a Catalan update for apt. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_ES.UTF-8@valencia, LC_CTYPE=ca_ES.UTF-8@valencia (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring 2010.08.28 GnuPG archive keys of the Debian a ii gnupg 1.4.11-3 GNU privacy guard - a free PGP rep ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-11 GCC support library ii libstdc++6 4.6.0-11 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime apt recommends no packages. Versions of packages apt suggests: pn apt-doc(no description available) ii aptitude 0.6.4-1terminal-based package manager (te ii bzip2 1.0.5-6high-quality block-sorting file co ii dpkg-dev 1.16.0.3 Debian package development tools ii lzma 4.43-14Compression method of 7z format in ii python-apt0.8.0 Python interface to libapt-pkg ii synaptic 0.75.1 Graphical package manager -- no debconf information ca.po.gz Description: GNU Zip compressed data
Bug#630453: the tutorial's license don't pass the "free island" test
Hi it's requested has been replaced with it's strongly encouraged. You can find copies of the modified document here: http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt Regards, David On 16/06/2011 7:20 AM, Georges Khaznadar wrote: Hello David, thank you for your fast response! You probably have heard of the Debian guidelines about free software (DFSG), they try to define most clearly the frontier between free and non-free software. In real life, things are not either black or white: black and white are united by a continuous series of grey tones. The "desert island test" is one of the touchstones we use to decide whether something is free or non-free. Here is a simple version of this test: please imagine that you live in a desert island, and that you got the software X, possibly enclosed in a floating bottle. Then you examine the software, and the license says that you must communicate with its author to be authorized to use this software (for any usage which is possible in the case of free software: running it, reading its source, modifying it). If the license compells you to communicate with the author, it is no more DFSG-free. You license still contains one phrase which does not pass this test: "If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer." The words "it's requested" are compelling. Hence this tutorial falls into the category of non-DFSG-free documents. Please consider some rewording, for example: s/it's requested that you/you are strongly encouraged to/ For how many people would the modified version of the licence change their behavior? I believe that there are plenty of people who do not take serously the licenses: those won't read your license, either in its compelling form or in its milder form. However which such a rewording, your license would definitely belong to the category of FDSG-free documents. Timo, Berndt, what is your mind about this? Best regards, Georges. Kicad a écrit : Hi, I have deleted the offending line from the current version of the document, which was updated this year. Does this resolve the issue? You can find copies of the modified document here: http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt Kind Regards, David On 15/06/2011 7:24 AM, Georges Khaznadar wrote: Hi, thank you for your fast reply Timo. Let us wait some time for David's response. Best regards, Georges. Timo Juhani Lindfors a écrit : Hi, Georges Khaznadar writes: is it possible to have a single source package, giving two output packages in different sections like main and non-free? my idea is that it is not allowed, this is not possible indeed since non-free stuff is not ok in the source package either. so I should withdraw the conflicting file from kicad's source, to build a package kicad-X.XX+dfsg, and upload a package kicad-tutorial to the NEW queue. Sounds possible. I would rather see the license fixed though. I already started updating the tutorial with screenshots from a more recent kicad before I noticed the first page banner. -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630656: ITP: libdata-taxi-perl -- Taint-aware, XML-ish data serialization
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli * Package name: libdata-taxi-perl Version : 0.96 Upstream Author : Miko O'Sullivan * URL : http://search.cpan.org/dist/Data-Taxi/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Taint-aware, XML-ish data serialization -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630619: [imagemagick] Could you test with version on mentors
Hi, I have just uploaded a new version on mentors. Could you test please ? bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630655: libgadu: New upstream version available
Package: libgadu Version: 1:1.10.1-1 Severity: wishlist libgadu 1.11.0 is available at http://toxygen.net/libgadu/ Could you package this version? TIA Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630654: pidgin must build depend on libgadu-dev (>= 1:1.11.0)
Package: pidgin Version: 2.8.0-1 Severity: important The security team is surely not happy that currently an internal version of libgadu is used. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630653: ITP: libbencode-perl -- BitTorrent serialisation format
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli * Package name: libbencode-perl Version : 1.4 Upstream Author : Aristotle Pagaltzis * URL : http://search.cpan.org/dist/Bencode/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : BitTorrent serialisation format -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630652: bjam: define the right OS name on Hurd
Package: boost1.46
Version: 1.46.1-6
Severity: normal
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
currently bjam does not identify Hurd when using e.g. os.name in jam scripts:
$ bjam -v | head -n1
Boost.Jam Version 3.1.19. OS=UNKNOWN.
The attached patch (which should be suitable for upstream inclusion) sets the
correct #define's for Hurd in bjam, adding also the path detection for the
bjam test suite.
$ bjam -v | head -n1
Boost.Jam Version 3.1.19. OS=HURD.
Thanks,
--
Pino
Description: bjam: define the right OS variable on Hurd
Author: Pino Toscano
--- a/tools/build/v2/engine/src/jam.h
+++ b/tools/build/v2/engine/src/jam.h
@@ -391,6 +391,10 @@
#define OSMINOR "OS=KFREEBSD"
#define OS_KFREEBSD
#endif
+#ifdef __GNU__
+#define OSMINOR "OS=HURD"
+#define OS_HURD
+#endif
#ifndef OSMINOR
#define OSMINOR "OS=UNKNOWN"
#endif
--- a/tools/build/v2/test/BoostBuild.py
+++ b/tools/build/v2/test/BoostBuild.py
@@ -240,6 +240,12 @@
jam_build_dir = "bin.freebsd"
elif os.uname()[0] == "OSF1":
jam_build_dir = "bin.osf"
+elif os.uname()[0] == "GNU":
+cpu = os.uname()[4]
+if re.match("i.86.*", cpu):
+jam_build_dir = "bin.hurdx86";
+else:
+jam_build_dir = "bin.hurd" + os.uname()[4]
else:
raise "Don't know directory where Jam is built for this
system: " + os.name + "/" + os.uname()[0]
else:
Bug#630651: update-notifier: Tooltip error when an apt preferences file is unreadable.
Package: update-notifier Version: 0.99.3debian8 Severity: minor I have a file in /etc/apt/preferences.d/, pinning a certain package to -1 to prevent installation. This file is owned by root:root, and has 0600 as its permissions. I noticed today, that the toolip for the update-notifier is far longer than it usually is. This is how it reads: , | An error occurred, please run Package Manager from the right-click | menu or apt-get in a terminal to see what is wrong. | | The error message was: 'Error: Opening the cache (E:Could not open | file /etc/apt/preferences.d/ign-Vsk0V3 - open (13: Permission | denied))'This usually means that your installed packages have unmet | dependencies. ` There's a few problems with this tooltip: First of all, the formatting is a bit off: there's no newline after the quoted error message. Second, the cache has nothing to do with my preferences file, I believe. Nor does it have anything to do with unmet dependencies. I'm not quite sure where the error message in the tooltip comes from, whether it is apt or a script that update-notifier uses - nevertheless, the tooltip could be formatted and worded better. I'd remove the last sentence, to be honest, but that might be just me. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages update-notifier depends on: ii gconf2 2.28.1-6 GNOME configuration database syste ii gksu2.0.2-5 graphical frontend to su ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgdu0 2.30.1-2 GObject based Disk Utility Library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libgudev-1.0-0 164-3GObject-based wrapper library for ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libx11-62:1.3.3-4X11 client-side library ii notification-daemon 0.5.0-2 daemon to displays passive pop-up ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii update-manager-gnome0.200.5-1GNOME application that manages sof ii update-notifier-common 0.99.3debian8Files shared between update-notifi Versions of packages update-notifier recommends: ii anacron2.3-14cron-like program that doesn't go pn apport-gtk (no description available) ii software-properties-gtk0.60.debian-3 manage the repositories that you i ii synaptic 0.70~pre1+b1 Graphical package manager Versions of packages update-notifier suggests: pn ubuntu-system-service (no description available) -- no debconf information -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630650: The parameter net.ipv4.ip_forward = 0 does not work, still allows network traffic to 192.168.0.x 130.11.xx/16 unlike
Package: base Severity: critical Tags: security -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630000: d-i cannot receive an IP address from Mac OS X
tags 63 + patch thanks And here is quilt patch for 1.17.1-8. -- Kenshi Muto km...@debian.org udhcpc-emit-correct-secs-field.patch Description: Binary data
Bug#630649: nautilus-share: not add user in samba
Package: nautilus-share Version: 0.7.2-14 Severity: important allow shared directory, but not allow open when ask pass -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nautilus-share depends on: ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgnomeui-0 2.24.3-1 The GNOME libraries (User Interfac ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libnautilus-extension12.30.1-3 libraries for nautilus components ii nautilus 2.30.1-3 file manager and graphical shell f ii samba-common 2:3.5.8~dfsg-1 common files used by both the Samb ii samba-common-bin 2:3.5.8~dfsg-1 common files used by both the Samb nautilus-share recommends no packages. Versions of packages nautilus-share suggests: ii samba 2:3.5.8~dfsg-1 SMB/CIFS file, print, and login se -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: > Some implementations of gethostbyname, given the name "com" or > "mycomputer" will attempt to look it up in the DNS with just such a > query, thus wasting upstream bandwidth and leaking internal network > information. hm, so? a heuristic based solely on the number of labels in the qname is a rather blunt tool here. far better to fix the misconfigured client than to guess at what the stub resolver might have meant. > It's sometimes useful to pre-empt that, so there's a configuration > option. It's not the default behaviour. NXDOMAIN is wrong here, > NODATA would be better, but historically dnsmasq was fielding queries > from stub resolvers, so nobody every noticed the difference. i disagree. the existence of an option that pre-empts queries for one-label qnames (and the comment at the top of the example config file encouraging one to turn it on) harms interoperability. i'd recommend deprecating and removing the domain-needed option altogether but if you're not going to do that i'd at least make the filtering logic conditional. from looking at the source it appears qtype=NS is exempted from the filter, maybe you could invert the logic and make it apply only to qtype=A and perhaps qtype=. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630648: hplip: Wrong udev rules makes HP Laserjet P1102 unusable
Package: hplip
Version: 3.11.5-1
Severity: important
Tags: patch
After the last update of udev the current rules for the hp printers in
/etc/udev/rules.d results in a /usr/lib/cups/backend/hp failed error. The
printer is set to inactive an hp-toolbox gives a 5012 Error which says, that no
connection to the printerdevice is possible. Of course it is impossible to
print anything. hp-setup was unable to find the device except the bus, device
and id is manually given.
The solution for this problem is the replacment of the old rules for udev, with
new ones, that uses attr and attrs instead of sysfs. I found a file in the
official tarball of the hplib source, that can replace all old rulefiles. After
replacing the rules, my printer works fine like before
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages hplip depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii coreutils 8.5-1 GNU core utilities
ii cups 1.4.6-6Common UNIX Printing System(tm) -
ii cups-client 1.4.6-6Common UNIX Printing System(tm) -
ii hplip-cups3.11.5-1 HP Linux Printing and Imaging - CU
ii hplip-data3.11.5-1 HP Linux Printing and Imaging - da
ii libc6 2.13-4 Embedded GNU C Library: Shared lib
ii libcups2 1.4.6-6Common UNIX Printing System(tm) -
ii libdbus-1-3 1.4.8-3simple interprocess messaging syst
ii libhpmud0 3.11.5-1 HP Multi-Point Transport Driver (h
ii libsane 1.0.22-3 API library for scanners
ii libsane-hpaio 3.11.5-1 HP SANE backend for multi-function
ii libssl1.0.0 1.0.0d-2 SSL shared libraries
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
ii policykit-1 0.101-4framework for managing administrat
ii python2.6.6-14 interactive high-level object-orie
ii python-dbus 0.84.0-1 simple interprocess messaging syst
ii python-imaging1.1.7-2+b1 Python Imaging Library
ii python-pexpect2.3-1 Python module for automating inter
ii python-support1.0.13 automated rebuilding support for P
ii wget 1.12-3.1 retrieves files from the web
Versions of packages hplip recommends:
ii avahi-daemon 0.6.30-3 Avahi mDNS/DNS-SD daemon
ii sane-utils1.0.22-3 API library for scanners -- utilit
Versions of packages hplip suggests:
pn hplip-doc (no description available)
pn hplip-gui (no description available)
ii python-notify 0.1.1-2+b3 Python bindings for libnotify
ii system-config-printer 1.2.3-3graphical interface to configure t
# HPLIP udev rules file for HP printer and all-in-one products.
#
# The 40-hplip.rules file replaces the 55-hpmud.rules on newer distros with
udev ACL support.
# For older distros that use HAL ACL support use the 55-hpmud.rules.
#
ACTION!="add", GOTO="hpmud_rules_end"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="pid_test"
SUBSYSTEM!="usb_device", GOTO="hpmud_rules_end"
LABEL="pid_test"
# Check for AiO products (0x03f0xx11).
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??11", GROUP="lp", ENV{ID_HPLIP}="1"
# Check for Photosmart products without wildcard since cameras and scanners
also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="c302", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_100
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3802", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_1115
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3402", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_1215
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3202", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_1218
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3302", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_130
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3902", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_1315
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3602", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_140_series
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="1002", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_230
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3502", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_240_series
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="1102", GROUP="lp", ENV{ID_HPLIP}="1"
# photosmart_320_series
ATTRS{idVendor}=="03f0", ATTRS{idProdu
Bug#630409: sphinx: Please backport docstring parsing
* Nikolaus Rath , 2011-06-15, 12:57:
==
FAIL: test_autodoc.test_generate
--
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/nose/case.py", line 187, in runTest
self.test(*self.arg)
File "/home/nikratio/tmp/sphinx/tests/test_autodoc.py", line 486, in
test_generate
assert_processes([('function', 'time.asctime')], 'function', 'asctime')
File "/home/nikratio/tmp/sphinx/tests/test_autodoc.py", line 351, in
assert_processes
assert_works(objtype, name, **kw)
File "/home/nikratio/tmp/sphinx/tests/test_autodoc.py", line 345, in
assert_works
assert len(_warnings) == 0, _warnings
AssertionError: ["error while formatting arguments for time.asctime:
is not a Python function"]
--
I stared at this for quite a while, but I don't understand what's going on.
This hunk looks fishy:
| @@ -847,8 +893,8 @@
| def format_args(self):
| if inspect.isbuiltin(self.object) or \
| inspect.ismethoddescriptor(self.object):
| -# can never get arguments of a C function or method
| -return None
| +# cannot introspect arguments of a C function or method
| +pass
| try:
| argspec = inspect.getargspec(self.object)
| except TypeError:
If it is intentional that format_args raises an exception on builtins
etc., then the whole if statement could be removed. If this is not the
case, the change is incorrect.
I think we have to wait for upstream to fix this bug, or just accept
upstream's default. Would the later be possible?
I'd rather reluctant to enable it by default.
Note that this patch really only becomes effective if Sphinx did not
find any other way to retrieve a signature,
This is not my understanding. AFAICS it always tries to extract
signature form docstrings and only falls back to introspection, not the
other way round.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620988: py.test -- new release available
Package: python-py Version: 1.3.4-2 Followup-For: Bug #620988 Hi ! It looks like pylib is now in version 1.4.3[1], and that the py.test part has become a separate project[2][3][4], as did pycmd[5]. I am a mere user of py.test, and I do not have a lot of packaging experience (close to none, to be honest), but if need help to package those extra sources, I gladly volunteer myself :-). Cheers, Simon Chopin [1] https://bitbucket.org/hpk42/py/src/9950bf9d684a [2] http://readthedocs.org/docs/pylib/en/1.4.3/ [3] https://bitbucket.org/hpk42/pytest [4] http://pytest.org/ [5] https://bitbucket.org/hpk42/pycmd -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-py depends on: ii python2.6.6-14 interactive high-level object-orie ii python-pkg-resources 0.6.16-1 Package Discovery and Resource Acc ii python-support1.0.13 automated rebuilding support for P python-py recommends no packages. Versions of packages python-py suggests: pn python-pytest-xdist(no description available) ii subversion 1.6.17dfsg-1 Advanced version control system -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630619: [imagemagick] Will fix asap
Package: imagemagick Version: 8:6.6.0.4-3+b1 Will fix asap. i have cherry picket the fix from new revisions. Will post a version in mentors in a few minutes. Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630647: Finnish translation uses "%1$d" syntax not supported by grub_printf
Package: grub-common Version: 1.98+20100804-14 Severity: minor File: /usr/share/locale/fi/LC_MESSAGES/grub.mo Tags: l10n -- Steps to reproduce: 0. Have a partition containing an ext2 or ext3 file system that has been written to. (In case it matters, my disk has a GUID partition table.) 1. Get to the GRUB command prompt, in grub-pc or grub-emu. 2. Execute "set lang=fi". 3. Type "ls (hd0," or similar, substituting the name of the disk. Do not press Enter. 4. Press the Tab key. -- Actual results: GRUB displays something like: grub> ls (hd0, Mahdollisia osioita ovat: Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? - Viimeinen muokkausaika $d.$d.$d $d:$d:$d $s, UUID 2097e2f5-7cc4-4fc0-84bc-7780ae74edd5 Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm? Note the "$d.$d.$d $d:$d:$d $s" part. (The question marks appear in grub-emu; I don't remember whether they do in grub-pc too.) -- Expected results: GRUB should have instead displayed a date and a time. Like this, for example: grub> ls (hd0, Mahdollisia osioita ovat: Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? - Viimeinen muokkausaika 15.6.2011 07:17:24 Wednesday, UUID 2097e2f5-7cc4-4fc0-84bc-7780ae74edd5 Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm? (Localizing "Wednesday" is not in the scope of this bug report.) -- Cause: po/fi.po in the source tree does: #: normal/misc.c:88 #, c-format msgid "- Last modification time %d-%02d-%02d %02d:%02d:%02d %s" msgstr "- Viimeinen muokkausaika %3$d.%2$d.%1$d %4$d:%5$d:%6$d %7$s" However, grub_vsnprintf_real in kern/misc.c does not support numbered argument conversion specifications like "%1$d". Only this one translation in po/fi.po has the bug. There are dollar signs in po/zh_CN.po too but they have been commented out. -- Change request: Please either change the C code to support numbered arguments, or change the translation not to use them. The easiest fix would be to make the Finnish msgstr use the same "%d-%02d-%02d %02d:%02d:%02d %s" format as the msgid. Although the year-month-day format is not widely used in Finland, it would surely be better than not seeing the date at all. -- System Information: Debian Release: 6.0.1 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-common depends on: ii base-files 6.0squeeze1 Debian base system miscellaneous f ii dpkg1.15.8.10Debian package management system ii gettext-base0.18.1.1-3 GNU Internationalization utilities ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libdevmapper1.02.1 2:1.02.48-5 The Linux Kernel Device Mapper use ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages grub-common recommends: pn os-prober (no description available) Versions of packages grub-common suggests: pn grub-emu (no description available) pn multiboot-doc (no description available) pn xorriso(no description available) -- no debconf information pgppgiyYp1wVw.pgp Description: PGP signature
Bug#630646: Selecting Hibernate for "When the power button is pressed" takes no effect
Package: gnome-shell Version: 3.0.2-1 Severity: normal 1. Click your name on the top bar and select System Settings. 2. Open Power. 3. Select Hibernate for "When the power button is pressed". When one actually uses the power button, the dialogue doesn't contain a Hibernate option: Power Off The system will power off automatically in 60 seconds. Cancel | Restart | Power Off -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-1-686 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gs 0.7.5-2 simple configuration storage syste ii gconf2 2.32.3-2 GNOME configuration database syste ii gir1.2-atk-1.0 2.0.0-1 The ATK accessibility toolkit (GOb ii gir1.2-clutter-1.0 1.6.14-1 GObject introspection data for the ii gir1.2-freedesktop 0.10.8-1 Introspection data for some FreeDe ii gir1.2-gconf-2.02.32.3-2 GNOME configuration database syste ii gir1.2-gdkpixbuf-2.02.23.3-3 GDK Pixbuf library - GObject-Intro ii gir1.2-gkbd-3.0 3.0.0.1-1GObject introspection data for the ii gir1.2-glib-2.0 0.10.8-1 Introspection data for GLib, GObje ii gir1.2-gnomebluetooth-1.0 3.0.0-1 Introspection data for GnomeBlueto ii gir1.2-gtk-3.0 3.0.10-1 GTK+ graphical user interface libr ii gir1.2-json-glib-1.00.13.2-1 GLib JSON manipulation library (in ii gir1.2-mutter-3.0 3.0.2.1-1GObject introspection data for Mut ii gir1.2-networkmanager-1.0 0.8.9997-1 GObject introspection data for Net ii gir1.2-pango-1.01.28.3-6 Layout and rendering of internatio ii gir1.2-polkit-1.0 0.101-4 GObject introspection data for Pol ii gir1.2-telepathyglib-0.12 0.15.1-1 GLib Telepathy connection manager ii gir1.2-telepathylogger-0.2 0.2.10-1 Telepathy logger service - introsp ii gir1.2-upowerglib-1.0 0.9.11-1 GObject introspection data for upo ii gjs 0.7.14-1 Mozilla-based javascript bindings ii gnome-bluetooth 3.0.0-1 GNOME Bluetooth tools ii gnome-icon-theme-symbolic 3.0.0-1 GNOME Desktop icon theme (symbolic ii gnome-settings-daemon 3.0.2-1 daemon handling the GNOME session ii gsettings-desktop-schemas 3.0.1-1 GSettings deskop-wide schemas ii libatk1.0-0 2.0.0-1 The ATK accessibility toolkit ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libcairo-gobject2 1.10.2-6 The Cairo 2D vector graphics libra ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libcamel1.2-19 2.32.3-1 Evolution MIME message handling li ii libcanberra00.24-1 a simple abstract interface for pl ii libclutter-1.0-01.6.14-1 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-4 simple interprocess messaging syst ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libdconf0 0.7.5-2 simple configuration storage syste ii libdrm2 2.4.25-3 Userspace interface to kernel DRM ii libebook1.2-10 3.0.0-1 Client library for evolution addre ii libecal1.2-83.0.0-1 Client library for evolution calen ii libedataserver1.2-143.0.0-1 Utility library for evolution data ii libedataserverui-3.0-0 3.0.0-1 GUI utility library for evolution ii libffi5 3.0.9-3 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libgconf2-4 2.32.3-2 GNOME configuration database syste ii libgdk-pixbuf2.0-0 2.23.3-3 GDK Pixbuf library ii libgirepository-1.0-1 0.10.8-1 Library for handling GObject intro ii libgjs0b0.7.14-1 Mozilla-based javascript bindings ii libgl1-mesa-glx [libgl1]7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgnome-desktop-3-03.0.2-2 Utility library for loading .deskt ii libgnome-menu2 2.30.3-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.34-1Core GStreamer libraries and eleme ii libgtk-3-0 3.0.10-1 GTK+ graphical user interface libr ii libical00.44-3 iCale
Bug#630534: libpam-modules: could not identify user
Am Mittwoch, den 15.06.2011, 23:19 +0200 schrieb Arthur de Jong: > On Wed, 2011-06-15 at 01:05 +0200, f...@fkoop.de wrote: > > I configured nsswitch.conf in the following way: > > > > passwd: compat ldap > > group: compat ldap > > shadow: compat ldap > > Is there a particular reason you use compat here? I would recommend > using: >files ldap > unless you also use NIS. > I tried with both with the same results. Before I had the problems (starting about 2 days ago) I remembered that there was an entry called "compat ldap", that's basically while I used it. But as I do not use NIS , I will change that to "files ldap". > > If I use the command "getent passwd" I get all of the passwd entries > > of the local system and additionally the information about the users > > stored on the ldap server. Any idea how I can further debug the > > situation? > > If you run "getent shadow" as root do you also get all users? Shadow > information needs to be present for pam_unix to work currently. > No entries for shadow in ldap. Is that the reason why it stopped working? If so, is that documented somewhere? I wasn't aware that I need to add shadow information in ldap to be able to use my setup, which has worked for several months before. > If you're using nslcd, could you provide the contents > of /etc/nslcd.conf. Here it is: # /etc/nslcd.conf # nslcd configuration file. See nslcd.conf(5) # for details. # The user and group nslcd should run as. uid nslcd gid nslcd # The location at which the LDAP server(s) should be reachable. uri ldap://192.168.8.3/ # The search base that will be used for all queries. base dc=fkoop,dc=de # The LDAP protocol version to use. ldap_version 3 # The DN to bind with for normal lookups. #binddn cn=annonymous,dc=example,dc=net #bindpw secret # SSL options #ssl off #tls_reqcert never # The search scope. #scope sub > > Also, are you using nscd or unscd? Some users seem to have problems with > that. Does "getent passwd fkoop" produce the output you expect? > I am using nscd and yes, "getent passwd fkoop" produces the expected output. -- Mit freundlichen Grüßen Felix Koop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Hi Roger! Thanks for answering in such detail. I'll try to comment on a few points. Am 15.06.2011 22:46, schrieb Roger Leigh: > On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote: > > The FHS defines the persistence/lifetime for /tmp and /var/tmp. > It does not make any recommendations about size. Yep, that's also how I read and understand the FHS. > Historical practice is that /tmp is small, and /var/tmp is > rather larger. When using Sun/Solaris systems back around 2000, > /tmp was always a tmpfs (it's the default), and /var/tmp was > disc. Solaris tmpfs didn't have size limits (filling it would > hang the system--I remember an undergrad being told off for > trying to download a RedHat ISO image to /tmp and killing the > system). On these systems files in /tmp were cleaned hourly, > and files in /var/tmp weekly. Files needing longer-term storage > went in /var/preserve (cleaned every few months) or on other > storage. As a fun fact, I made the opposite experience. At university (where $HOME was shared via NFS and had rather strict quotas) students where told to use /tmp for larger downloads. But then, this was not on a Solaris system. > In the IRC discussion, it was mentioned that some DVD authoring > applications were using /tmp to create/store 4GiB disc images. > Also, backup software used /tmp to store multi-gigabyte backups > during its operation. I would argue that any application expecting > to be able to store such large files in /tmp has wholly unrealistic > expectations. If I look at todays installers for Linux distros, like openSUSE, Redhat, Ubuntu or Debian, the default option creates a large /tmp, as it is a subdirectory of /. I don't know of any Linux distribution which uses tmpfs for /tmp. /tmp on a separate partition is an option which not all installers offer and needs to be chosen explicitly. So while we don't guarantee any minimum sizes for /tmp, applications expecting a large /tmp is not completely unrealistic. I acknowledge that my concern is more targetted at a typical desktop/laptop user, which certainly has different usage of software than a server installation. > Initial setup: > I would like to see the Debian installer support setup of /tmp to > permit > - disabling of /tmp on tmpfs > - setting of a tmpfs size other than 20% core > - allocation of sufficient backing store (swap) during partitioning > If we wanted to guarantee a minimum tmpfs size here, we could ensure > that there's sufficient swap to up the limit from 20% to something > more, or an absolute value rather than a percentage. Having RAMTMP=no and letting d-i enable it if it finds a minimum amount of ram would be a good compromise imho. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#630645: yabause does not run
Package: yabause Justification: renders package unusable Severity: grave *** Please type your report below this line *** After installing the package the frontent of the emulator starts. You can also edit the settings and give a valid bios, that runs perfect in the windows version. But when you try to start nothing happens. When you try to click on open iso you get the attached error message. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash <>
Bug#630644: valgrind: strspn needs suppression with recent glibc
Package: valgrind
Version: 1:3.6.1-5
Severity: minor
Tags: patch
I get false positives with a simple use of strspn:
$ cat >foo.c <<'EOF'
#include
int main(void)
{
char buf[32];
strcpy(buf, "foo");
if (strspn(buf, "o"))
return 0;
return 1;
}
EOF
$ gcc -g -o foo foo.c
$ valgrind ./foo
...
==5854== Conditional jump or move depends on uninitialised value(s)
==5854==at 0x4B3623E: __strspn_sse42 (strspn-c.c:142)
==5854==by 0x400509: main (foo.c:8)
...
Looks like it was reported elsewhere with a patch a few months ago:
https://bugs.kde.org/show_bug.cgi?id=270925
I tried the version of valgrind in experimental, but it shows the same
behavior.
-Peff
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages valgrind depends on:
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
ii libc6-dbg 2.13-7 Embedded GNU C Library: detached d
Versions of packages valgrind recommends:
ii gdb 7.2-1 The GNU Debugger
Versions of packages valgrind suggests:
pn alleyoop (no description available)
pn kcachegrind(no description available)
pn valkyrie (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... Probably best not to look at "filterwin2k" then. Not the finest hour. Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 15.06.2011 21:56, schrieb Alex Hermann: On Wednesday 15 June 2011, Josua Dietze wrote: Why not use the "/usr/share/usb_modeswitch" folder, alongside the package? IMHO I think the folder change is not a good idea. The /usr/share folder is supposed to be under package manager control, not user control. I think overriding packaged configurations do belong in /etc. The current package (with this bug fixed) fits my use case perfectly and I think it also fits the Debian way of configuring software. You may have a point there; I'm not familiar enough with the package conventions. OdyX has just confirmed that fact :-) An override config file should have higher priority than shipped config of course. O.K., so let's assume a user puts a changed/added config file into /etc/usb_modeswitch.d. It is preferred over the files in the package. One day there is a package update, and the new/changed configuration now comes included with the new package, probably improved over the "manual" file or with new parameters. What should happen then? The priority would have to be reversed ... Or the package install routine should notice the conflict and ask about a user decision. For a moment I thought about checking file mod time. But it's very error-prone too. It's getting a wee bit messy, I'm afraid. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant "DNSSEC-conformant recursive nameserver" here, not "validating recursive nameserver". the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for ".com" hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a "not found" answer is returned. um, i think i know what a "plain name, without dots or domain parts" is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name "\x03com\x00" (presentation format: "com.") because it has only a single label? that is beyond broken. Some implementations of gethostbyname, given the name "com" or "mycomputer" will attempt to look it up in the DNS with just such a query, thus wasting upstream bandwidth and leaking internal network information. It's sometimes useful to pre-empt that, so there's a configuration option. It's not the default behaviour. NXDOMAIN is wrong here, NODATA would be better, but historically dnsmasq was fielding queries from stub resolvers, so nobody every noticed the difference. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Le mercredi, 15 juin 2011 22.33:29, Josua Dietze a écrit : > Am 14.06.2011 12:06, schrieb Didier Raboud: > > Thanks for your time and skills ! > > Just want to let you know that I'm on the job now and following this > exchange. Hi Josua, nice to see you ring in ! > Originally, the packed config file was not intended for default use on > desktop systems. It kind of amazed me to see this happening on today's > resource-loaded devices. Eh, disk space being cheap doesn't mean we can waste it for free. :-) > Well, now we have it and it makes sense to consider a mix of packed and > unpacked configurations, particularly when adding new device data or > changing existing entries. I don't like the folder splitting though; the > unpacked/edited files should be close to the other configurations. Why not > use the > "/usr/share/usb_modeswitch" folder, alongside the package? While I understand your feelings, unfortunately, the [FHS] forbids this: /usr/share is for "read-only architecture-independent shared user data", while /etc is for "host-specific system-wide configuration files". I think configuration files overrides fall in the second category. > I propose to drop the check for the old config folder > (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. No no no. :-> > Also, I think we can agree that in the now possible case of duplicate > configurations (one unpacked, one packed) the unpacked file should have the > higher priority. Sure; that sounds logical. > What do you think? The most important thing IMHO is to limit the use of overrides to the minimum: working configurations should be merged to the tarball, to benefit the FLOSS community at large. Cheers, OdyX [FHS] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: > Simon Kelley wrote: > > Robert Edmonds wrote: > > >Robert Edmonds wrote: > > >>so unbound forwarding to 4.2.2.1 works, but unbound forwarding to > > >>dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not > > >>fully transparent when forwarding between a validating forwarder and a > > >>validating recursive nameserver. > > > > > >ugh, i meant "DNSSEC-conformant recursive nameserver" here, not > > >"validating recursive nameserver". the level3 open recursives (4.2.2.X) > > >don't perform validation. > > > > > > > A quick query on the dnsmasq configuration in use here: is the > > --domain-needed flag set in /etc/dnsmasq.conf? I think that's > > causing the problem because the DS query for ".com" hits the filter. > > There are already exceptions on this filter for SOA and NS queries, > > the DNSSEC era requires that DS queries are added to that list. > > > > Assuming I've diagnosed this right, removing --domain-needed is a > > quick and simple workaround. > > from the man page: > >-D, --domain-needed > Tells dnsmasq to never forward queries for plain names, > without dots or domain parts, to upstream nameservers. If > the name is not known from /etc/hosts or DHCP then a "not > found" answer is returned. > > um, i think i know what a "plain name, without dots or domain parts" is, > but dnsmasq is a DNS server and deals with wire-format domain names, > right? does dnsmasq seriously respond with NXDOMAIN to queries for the > wire-format name "\x03com\x00" (presentation format: "com.") because it > has only a single label? that is beyond broken. ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630608: [bash] Everything Segfaults After lib6 -7 Upgrade
reassign 630608 libc6 2.13-7 quit Hi David, David Baron wrote: > After upgrading lib6 to current Sid (-7), everything, I mean everything > segfaults. System will boot up very normally but as soon as I log in, the fun > begins. > > There are numerous error messages from the bashrc or conf. Then, once again, > everything segfaults. Big red switch time. > > Since everything in bootup ran normally, and only when I enter a sh do I get > the problem, I am filing this on bash. Re-route if I am mistaken. Could you send some error messages, for example by taking a photograph of the screen? Also if you remember the order of events and when exactly the segfaults started, that would be very helpful. Thanks for reporting, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
> "Neil" == Neil Williams writes: > Error handling is the main reason. Unpacking might fail, the archives > might be the only source of data. > Could you have a look at the current SVN revision and let me know how > that matches your tests? I'm going to have a look at it and test this stuff on friday. >> That's exactly the problem: inconsistent versions in the archive or >> archive updates while multistrap runs. > That sounds like a broken archive. > I haven't implemented the versioned source call - I remain unconvinced > that a valid archive would cause the download of a source package of a > different version to the binary package. Are you assuming a non-changing archive? As soon as the archive changes non-atomically (with locking applied by the client) I think we're doomed. As we're building images from debian sid, changes will be pretty common. I'm not sure how many times 'multistrap' performs 'apt-get update'. Even if it only does it once, the source and binary package indices are distinct files, and they are retrieved by distinct transaction from the ftp/http server, so I see no way that you can guarantee consistency during mirror pushes. The only atomicity you have is for updating a single index file via 'mv'. The following scenario: * mirror gets updated, probably first new files put into the pool, then the new indices follow, then even later, it's going to delete the files no longer referenced by the indices. * Concurrently I run 'multistrap' which runs 'apt-get update', fetching dists/sid/main/binary-amd64/Packages.bz2 and sid/main/source/Sources.bz2 . * Now I get Packages.bz2 from before the mirror update, and Sources.bz2 from after the mirror update. Sources.bz2 is going to have some packages updated to newer versions, and won't correspond 100% to binaries from Packages.bz2, thus violating the GPL Of course I guess the error rate will not be too high, at least not over a normal high-rate internet connection. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpjbDIxwAMg7.pgp Description: PGP signature
Bug#630453: the tutorial's license don't pass the "free island" test
Hello David, thank you for your fast response! You probably have heard of the Debian guidelines about free software (DFSG), they try to define most clearly the frontier between free and non-free software. In real life, things are not either black or white: black and white are united by a continuous series of grey tones. The "desert island test" is one of the touchstones we use to decide whether something is free or non-free. Here is a simple version of this test: please imagine that you live in a desert island, and that you got the software X, possibly enclosed in a floating bottle. Then you examine the software, and the license says that you must communicate with its author to be authorized to use this software (for any usage which is possible in the case of free software: running it, reading its source, modifying it). If the license compells you to communicate with the author, it is no more DFSG-free. You license still contains one phrase which does not pass this test: "If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer." The words "it's requested" are compelling. Hence this tutorial falls into the category of non-DFSG-free documents. Please consider some rewording, for example: s/it's requested that you/you are strongly encouraged to/ For how many people would the modified version of the licence change their behavior? I believe that there are plenty of people who do not take serously the licenses: those won't read your license, either in its compelling form or in its milder form. However which such a rewording, your license would definitely belong to the category of FDSG-free documents. Timo, Berndt, what is your mind about this? Best regards, Georges. Kicad a écrit : > Hi, > > I have deleted the offending line from the current version of the > document, which was updated this year. Does this resolve the issue? > > You can find copies of the modified document here: > http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf > http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt > > Kind Regards, > David > > On 15/06/2011 7:24 AM, Georges Khaznadar wrote: > >Hi, > > > >thank you for your fast reply Timo. Let us wait some time for David's > >response. > > > >Best regards,Georges. > > > >Timo Juhani Lindfors a écrit : > >>Hi, > >> > >>Georges Khaznadar writes: > >>>is it possible to have a single source package, giving two output packages > >>>in different sections like main and non-free? > >>> > >>>my idea is that it is not allowed, > >>this is not possible indeed since non-free stuff is not ok in the source > >>package either. > >> > >>>so I should withdraw the conflicting > >>>file from kicad's source, to build a package kicad-X.XX+dfsg, and upload > >>>a package kicad-tutorial to the NEW queue. > >>Sounds possible. I would rather see the license fixed though. I already > >>started updating the tutorial with screenshots from a more recent kicad > >>before I noticed the first page banner. > >> > >>-Timo > >> > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: Digital signature
Bug#630534: libpam-modules: could not identify user
On Wed, 2011-06-15 at 01:05 +0200, f...@fkoop.de wrote: > I configured nsswitch.conf in the following way: > > passwd: compat ldap > group: compat ldap > shadow: compat ldap Is there a particular reason you use compat here? I would recommend using: files ldap unless you also use NIS. > If I use the command "getent passwd" I get all of the passwd entries > of the local system and additionally the information about the users > stored on the ldap server. Any idea how I can further debug the > situation? If you run "getent shadow" as root do you also get all users? Shadow information needs to be present for pam_unix to work currently. If you're using nslcd, could you provide the contents of /etc/nslcd.conf. Also, are you using nscd or unscd? Some users seem to have problems with that. Does "getent passwd fkoop" produce the output you expect? -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: > Robert Edmonds wrote: > >Robert Edmonds wrote: > >>so unbound forwarding to 4.2.2.1 works, but unbound forwarding to > >>dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not > >>fully transparent when forwarding between a validating forwarder and a > >>validating recursive nameserver. > > > >ugh, i meant "DNSSEC-conformant recursive nameserver" here, not > >"validating recursive nameserver". the level3 open recursives (4.2.2.X) > >don't perform validation. > > > > A quick query on the dnsmasq configuration in use here: is the > --domain-needed flag set in /etc/dnsmasq.conf? I think that's > causing the problem because the DS query for ".com" hits the filter. > There are already exceptions on this filter for SOA and NS queries, > the DNSSEC era requires that DS queries are added to that list. > > Assuming I've diagnosed this right, removing --domain-needed is a > quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a "not found" answer is returned. um, i think i know what a "plain name, without dots or domain parts" is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name "\x03com\x00" (presentation format: "com.") because it has only a single label? that is beyond broken. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619067: gallery2: Cannot add photos to albums
On Sun, Mar 20, 2011 at 10:08:54PM +, Chris Carr wrote: > Package: gallery2 > Version: 2.3.1.dfsg-1 > Severity: normal > > I haven't visited my gallery2 install for a year or so, but my ~5000 photos > are > still there and looking fine. Unfortunately, if I click on Add Items in any > album, I get this: > > Error Detail - > Error (ERROR_BAD_PATH) : Invalid path: modules/remote/ItemAddGalleryRemote.inc I have exactly the same situation here. It says in README.Debian: The Debian gallery2 package does not include the uploadapplet, slideshowapplet, remote, or panorama modules nor the DB2 storage support. This support can be re-enabled using the module downloader built into Gallery2. And the issue is that gallery2 is trying to use the remote module. So go to site admin, then select "plugins" from the left menu, "Get More Plugins" and install the remote plugin. Then it works! Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629956: apt: apt-cache fails with current fakeroot
Hi, Clint Adams wrote: > On Wed, Jun 15, 2011 at 02:41:01PM +0200, Martin Pitt wrote: >> I tracked this down to apt-cache now failing to work under fakeroot: >> >> $ fakeroot apt-cache policy coreutils >> E: Could not open file /var/cache/apt/pkgcache.bin - open (13: Permission >> denied) >> E: Failed to truncate file - ftruncate (9: Bad file descriptor) >> E: The package lists or status file could not be parsed or opened. [...] >> It's a bit hard to say whether this is a bug in apt, or whether >> fakeroot shouldn't claim that access() works when it doesn't. Clint >> seems to have anticipated that in [2] already. Yikes, thanks for a heads up. One approach would be to say that running a typical test suite is not something fakeroot can fully support, and the behavior of fakeroot should be tuned for whatever is done outside the testsuite. Unfortunately, both of the motivating examples were testsuites, so that doesn't really give an answer. access() seems to be used in build processes in two ways: - on one hand, it can be used as the git test suite uses it, to tell if a process has too much permission to test permissions problems (i.e., in order to say "this environment is too crazy --- let's _skip_ some tests"); - on the other hand, it can be used as in Martin's example test suite, to opportunistically say "If I have permission to make something --- e.g., a cache --- in the system a little better, let me actually do that". In an ideal world, the latter is a bug. Permissions can change between time of check and time of use, so if the operation requiring permission is not essential then later access errors should induce warnings, not errors. But we live in the real world. Maybe it would be best to revert the change in sid and introduce it in experimental, to get a better sense of whether the weight of the impact goes one way or another. Anyway, Clint, please feel free to revert the change. I'll think more. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628357: tct: possible patch to solve FTBFS
Okay, I read some older bug reports on tct: BTW: The clean target of the tct Debian package is broken, the strange upstream mechanism (reconfig) conflicts with debian/rules and debian/patches/01-conglomeration.patch. IMO we should sort this out... in http://bugs.debian.org/532342 So maybe before uploading a fix for #628357 this should probably be cleaned up to? Regards Salvatore signature.asc Description: Digital signature
Bug#630643: adduser: Cancelling with Ctrl+C still adds entries to /etc/{passwd,group}
Package: adduser Version: 3.112+nmu2 Severity: normal Cancelling adduser part way through the creation of a new user results in entries being written to /etc/passwd and /etc/group. This behaviour is a) not what is normally expected when using Ctrl+C to cancel a command, and b) results in a potentially unconfigured but still existant user and group on a system. The script should be modified to only write to passwd/group files *after* a user confirms with 'Y'. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages adduser depends on: ii debconf [debconf-2.0 1.5.39 Debian configuration management sy ii passwd 1:4.1.4.2+svn3283-3 change and administer password and ii perl-base5.12.3-7+b1 minimal Perl system adduser recommends no packages. Versions of packages adduser suggests: ii liblocale-gettext-perl1.05-6+b1 Using libc functions for internati ii perl-modules 5.12.3-7 Core Perl modules -- debconf information: adduser/homedir-permission: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630542: yui-compressor: mangles strings containing backslash
Hi Jakub, Le mercredi 15 juin 2011 01:22:12, Jakub Wilk a écrit : > Package: yui-compressor > Version: 2.4.6+debian1-1 > Severity: grave > > $ cat tmp.js > x = "\\"; > > $ yui-compressor tmp.js; echo > x="\"; Thanks for you feedback, I can confirm that this break badly with jQuery. It seems regression testsuite in yui-compressor is not sufficient to check this case. Can you provide me a working compressed-jQuery so I can compare and check there is no others regressions ? For now, you can just use previous release (2.4.6-1) from testing. > (Severity grave, because this badly breaks jQuery, and possibly lots of > other code.) ACK. Cheers, -- Damien signature.asc Description: This is a digitally signed message part.
Bug#629936: oss4-base: works now
Package: oss4-base Followup-For: Bug #629936 This was fixed in build 2004. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, 'experimental'), (300, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) 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 oss4-base depends on: ii libc6 2.13-4Embedded GNU C Library: Shared lib ii linux-sound-base 1.0.23+dfsg-4 base package for ALSA and OSS soun Versions of packages oss4-base recommends: pn pm-utils (no description available) Versions of packages oss4-base suggests: ii oss4-dkms [oss4-modules] 4.2-build2004-1 Open Sound System - DKMS module so -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
On Wednesday 15 June 2011, Josua Dietze wrote: > Why not use the > "/usr/share/usb_modeswitch" folder, alongside the package? > > I propose to drop the check for the old config folder > (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. > Also, I think we can agree that in the now possible case of duplicate > configurations (one unpacked, one packed) the unpacked file should have > the higher priority. > > What do you think? IMHO I think the folder change is not a good idea. The /usr/share folder is supposed to be under package manager control, not user control. I think overriding packaged configurations do belong in /etc. The current package (with this bug fixed) fits my use case perfectly and I think it also fits the Debian way of configuring software. An override config file should have higher priority than shipped config ofcourse. Alex (not related to, nor speaking on behalf of, Debian; just long-term user). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630424: Maybe a Problem with "tip22"
Hi, On Tue, Jun 14, 2011 at 02:22:17AM -0700, Edwin Kwan wrote: > Hi, > > The screen shot in Attilio's bug report was done by me on my Indy. > I am not experienced in this beginning of the universe kind of code. > But I found the following clues which may be useful. I can reproduce the problem here now. A the same kernel+initrd that works with 0.3.12 doesn't with 0.3.13 (unlucky number it seems). I try come up with a patch during the next couple of days. BTW can I directlry fetch the initrd and kernel that was used to build: http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-mips/current/images/r4k-ip22/netboot-boot.img I thought these used to be on the mirrors but can't seem to find them. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 14.06.2011 12:06, schrieb Didier Raboud: Thanks for your time and skills ! Just want to let you know that I'm on the job now and following this exchange. Originally, the packed config file was not intended for default use on desktop systems. It kind of amazed me to see this happening on today's resource-loaded devices. Well, now we have it and it makes sense to consider a mix of packed and unpacked configurations, particularly when adding new device data or changing existing entries. I don't like the folder splitting though; the unpacked/edited files should be close to the other configurations. Why not use the "/usr/share/usb_modeswitch" folder, alongside the package? I propose to drop the check for the old config folder (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. Also, I think we can agree that in the now possible case of duplicate configurations (one unpacked, one packed) the unpacked file should have the higher priority. What do you think? Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
On Wed, 15 Jun 2011 17:49:50 +0200 David Kuehling wrote: > > Neil Williams writes: > > On Wed, 18 May 2011 15:09:44 +0200 > > David Kuehling wrote: > > > Think about this more carefully. The situation is that multistrap is > > stateless and something can have happened which means that the run > > when the packages are actually downloaded failed at a later stage > > (e.g. in the hooks or setupscript) and then got fixed. So a later run > > of multistrap still needs to go through the status file (because the > > .debs have been unpacked and deleted) to check if some source packages > > still need to be downloaded. apt-get install will check the status > > file and report that it the packages are already at the newest > > version, without downloading anything, so the list has to come from > > somewhere else. i.e. the list of downloaded debs is untrustworthy and > > must be regarded as incomplete. > > Ok, if this is the case, then why do we have to collect source packages > (dsclist) at 3 places in multistrap.conf . Won't it be sufficient to > just do it once, when parsing the status file? Error handling is the main reason. Unpacking might fail, the archives might be the only source of data. Could you have a look at the current SVN revision and let me know how that matches your tests? > >> The patch also fixes another bug, not yet reported: multistrap could > >> have fetched source packages versions that differ from the binary > >> package versions. > > > That is more about differences in aptsources and debootstrap lines > > than anything to do with specifying the version. I don't think your > > patch actually works here. apt-get source will get the latest, just as > > apt-get install will get the latest. What changes is whether the call > > is made when aptsources are active or when bootstrap sources are > > active. It needs to be bootstrap sources. I'd need to have a real > > example of where apt-get install will download a different version to > > what apt-get source will download for the same sources - that would be > > a bug in apt, not multistrap. (Multistrap creates deb-src lines for > > each source specified, so the versions are expected to be the same > > from deb to deb-src or else there are problems with the archive.) > > That's exactly the problem: inconsistent versions in the archive or > archive updates while multistrap runs. That sounds like a broken archive. I haven't implemented the versioned source call - I remain unconvinced that a valid archive would cause the download of a source package of a different version to the binary package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpYd785Swt9j.pgp Description: PGP signature
Bug#630642: oss4-base: Does not include upstream utilities soundon/soundoff
Package: oss4-base Version: 4.2-build2004-1 Severity: normal Upstream provides soundon and soundoff utilities that unload and reload the OSS modules enabling system suspend and resume. The debian OSS packages do not include these, and the README.Debian does not mention what replaces them. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, 'experimental'), (300, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) 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 oss4-base depends on: ii libc6 2.13-4Embedded GNU C Library: Shared lib ii linux-sound-base 1.0.23+dfsg-4 base package for ALSA and OSS soun Versions of packages oss4-base recommends: pn pm-utils (no description available) Versions of packages oss4-base suggests: ii oss4-dkms [oss4-modules] 4.2-build2004-1 Open Sound System - DKMS module so -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote: > On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote: > > [Michael Biebl] > > > the default for new installations is to use RAMTMP=yes. > > > > Hm, do not remember doing this change. Anyone know when it happened? > > This was done as part of the /run work a couple of months back. > > This was done following the discussion about default size limits > for the various tmpfses in use (/run, /run/lock, /run/shm, and > /tmp) on the debian-devel list, and also on #debian-devel. At > the time, the consensus appeared to be generally in favour of > the change. I'll follow up to the other messages in this one mail. Discussion on -devel (all in the same thread): http://lists.debian.org/debian-devel/2011/04/msg00554.html http://lists.debian.org/debian-devel/2011/04/msg00615.html http://lists.debian.org/debian-devel/2011/04/msg00703.html Note that the dicussion at the time was not initially proposing to make it the default, merely a configurable option, but consenus appeared to change in favour of making it the default as well. I don't have any IRC logs from the time in question I'm afraid. It might have been mentioned in other threads as well. The FHS defines the persistence/lifetime for /tmp and /var/tmp. It does not make any recommendations about size. /tmp contents are not guaranteed to be preserved across reboots /var/tmp contents are preserved across reboots (but may still be cleaned after a certain time duration). Historical practice is that /tmp is small, and /var/tmp is rather larger. When using Sun/Solaris systems back around 2000, /tmp was always a tmpfs (it's the default), and /var/tmp was disc. Solaris tmpfs didn't have size limits (filling it would hang the system--I remember an undergrad being told off for trying to download a RedHat ISO image to /tmp and killing the system). On these systems files in /tmp were cleaned hourly, and files in /var/tmp weekly. Files needing longer-term storage went in /var/preserve (cleaned every few months) or on other storage. There are three possibilities for /tmp: - as a subdirectory of the root filesystem - as a separately mounted filesystem - as a tmpfs All three have pros and cons. 1) Subdirectory of the root filesystem This can be a very large filesystem if you install using just one large filesystem, or with /home separate. But it's not guaranteed. Example: rootfs contains only / and /usr: % df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/ravenclaw-root 9611492 8364556758696 92% / % df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/hufflepuff-root 19223252 7026936 11219832 39% / Allowing for the 5% reserved blocks, the first doesn't have much free space to accommodate /tmp at all. The second has many gigabytes free though (despite being a much smaller system). The point I'm trying to make here is that there are no guarantees at all about how much free space the root filesystem has to accomodate /tmp. And changes in usage post-install may greatly reduce its capacity. 2) Separately mounted filesystem This needs manual setup: a filesystem needs making, and this needs mounting in /etc/fstab. Its size is exactly as large as the admin chooses. 3) As a tmpfs The default size is 20% of the core memory. This may vary significantly depending upon the amount of memory installed in the system: % mount | grep /tmp tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=1639592k) % df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 163959260 1639532 1% /tmp % mount | grep /tmp tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=206248k) % df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 206248 0206248 0% /tmp This is using the same two examples as above. The systems have 8 GiB and 1 GiB core memory, respectively. Customisation: just add an fstab entry like this: tmpfs /tmp tmpfs nosuid,nodev,size=8g,mode=1777 0 0 (note, this is all documented) This requires that you have the memory and/or swap to back the size specified. The bug: The RAMTMP feature as implemented is working exactly as designed. It is not buggy in itself. The question is whether it should be the default or not. Expectations: What is the minimum size that an application should expect /tmp to be, and how much of that space should an application expect to be available to satisfy its needs? Tricky question. The simple fact of the matter is, however, we don't make /any/ guarantees regarding minimum size and available space. Depending upon the partitioning scheme used, and the free space on the partition containing /tmp, there may be GiB of free space, or little or no space at all. Other applications and users may use all the space leaving
Bug#608808: ITA: pacpl -- multi-purpose audio converter/ripper/tagger script
retitle 608808 ITA: pacpl -- multi-purpose audio converter/ripper/tagger script owner 608808 ! thanks Hi, I wish to maintain this package. I use it, and I want that it stay in Debian. Progress will follow. xakz. -- Maxime Chatelle, human from earth, 01000 | cm94IGxvdmVyCg== gpl-kpr gpg: 79E0 25F5 06C5 5C7F F57C BADD 13EE 911A 8A1A 9DE9 pgpuJtQVoCwfj.pgp Description: PGP signature
Bug#630641: gem2deb: duplicate install of files in lib/
Package: gem2deb Version: 0.2.4 Severity: important Hi, for ruby-xmlparser (found in the pkg-ruby-extras repo, not uploaded yet because of that problem), gem2deb installs the files in lib/ to /usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/ and /usr/lib/ruby/vendor_ruby/1.8/x86_64-linux/. This might be related to the fact that extconf.rb is in the root dir. Lucas -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) 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 gem2deb depends on: ii build-essential 11.5 Informational list of build-essent ii debhelper 8.1.3helper programs for debian/rules ii devscripts 2.10.72 scripts to make the life of a Debi ii perl5.10.1-20Larry Wall's Practical Extraction ii ruby1.8 1.8.7.334+svn31904-1 Interpreter of object-oriented scr ii ruby1.8-dev 1.8.7.334+svn31904-1 Header files for compiling extensi ii ruby1.9.1 1.9.2.180+svn31745-1 Interpreter of object-oriented scr ii ruby1.9.1-dev 1.9.2.180+svn31745-1 Header files for compiling extensi ii rubygems1.8 1.6.2-1 package management framework for R gem2deb recommends no packages. gem2deb suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619272: [Pkg-oss4-maintainers] Bug#619272: oss4-dkms: Current kernel in archive is 2.6.39 which is still not supported.
On 15 June 2011 21:51, Romain Beauxis wrote: > This is fixed in 4.2-build2004-1 which was uploaded yesterday. > Yes, tried installing the oss packages before the updated package was on my mirror. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630604: LB_PARENT_ARCHIVE_AREAS default handling is wrong
tag 630604 pending
thanks
On 06/15/2011 04:18 PM, Colin Watson wrote:
> --parent-archive-areas seems to be broken, because the default for
> LB_PARENT_ARCHIVE_AREAS checks whether LB_ARCHIVE_AREAS is already set,
> not whether LB_PARENT_ARCHIVE_AREAS is already set. Patch attached.
applied, thanks.
> (Or is --parent-archive-areas deprecated? I notice that it isn't
> documented. But then, why does the LB_MODE=progress case do
> LB_PARENT_ARCHIVE_AREAS="${LB_PARENT_ARCHIVE_AREAS:-main}"?)
the derivatives handling is rather experimental and only minimally
tested yet. even, there might be intrusive changes, so it's not yet
advertised and documented. that will come with the next couple of uploads.
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628288: FTBFS: [javac] /build/user-lucene2_2.9.4+ds1-1-amd64-JNLFNr/lucene2-2.9.4+ds1/contrib/db/bdb/src/java/org/apache/lucene/store/db/DbDirectory.java:201: cannot find symbol
Package: lucene2 Severity: normal The correct patch was provided in #621398, I have also informed you to wait for libdb-java (>= 5.1.4), so you get the correct version with 'db.jar'. Please apply the former patch and it will fix this error. And really please do Build-Depend just on libdb-java, so we don't have to open new bug for every Berkeley DB transition we do. Thanks, -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630325: [ovs-dev] Bug#630325: Bug#630325: openvswitch: FTBFS on big-endian architectures
On Tue, Jun 14, 2011 at 10:05:35PM -0700, Ben Pfaff wrote:
> On Wed, Jun 15, 2011 at 02:04:39PM +0900, Simon Horman wrote:
> > On Tue, Jun 14, 2011 at 07:56:52PM -0700, Ben Pfaff wrote:
> > > On Wed, Jun 15, 2011 at 10:51:24AM +0900, Simon Horman wrote:
> > > > Unfortunately I'm not familiar enough with the output to determine
> > > > the problem without digging much further. Perhaps you have some ideas.
> > > >
> > > > The detailed output from sparc is below.
> > > > I believe that the output is similar if not the same
> > > > on the other three architectures.
> > >
> > > Yes, I looked at this today. I'll send out a fix for it tomorrow.
> > >
> > > It's a bug in the testsuite, I think, not in OVS itself.
> >
> > Understood.
> >
> > Could you CC me or this bug on the fix? Then I can push it into
> > an upload to Debian.Org and the buildds can verify the change.
>
> Of course. Will do.
Simon, looking closer, this was fixed on branch-1.1 by the following
commit, made on April 18. (The fix is to sort the output of
dump-flows.) This fix is already in OVS 1.1.1. This bug is reported
against OVS 1.1.0, so it should be obsoleted by the OVS version
currently in Debian. Indeed, when I look at the current buildd status
at https://buildd.debian.org/status/package.php?p=openvswitch&suite=sid
I don't see any relevant failures.
I think we can close this.
Thanks,
Ben.
--8<--cut here-->8--
From: Ben Pfaff
Date: Mon, 18 Apr 2011 10:11:43 -0700
Subject: [PATCH] ofp-util: Properly handle "tun_id"s in tun_id_from_cookie
flows.
Just setting the tun_id field isn't enough--it's also necessary to set
the tun_id_mask. Otherwise the call to cls_rule_zero_wildcarded_fields()
at the end of ofputil_cls_rule_from_match() will zero out the tun_id again.
This was broken by commit 8368c090cab "Implement arbitrary bitwise masks
for tun_id field" back in January. (This makes me wonder whether we can
drop support for tun_id_from_cookie now.)
Reported-by: Dan Wendlandt
---
lib/ofp-util.c |2 +-
tests/ofproto.at |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index cc448bc..5c95270 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -136,7 +136,7 @@ ofputil_cls_rule_from_match(const struct ofp_match *match,
wc->nw_dst_mask = ofputil_wcbits_to_netmask(ofpfw >> OFPFW_NW_DST_SHIFT);
if (flow_format == NXFF_TUN_ID_FROM_COOKIE && !(ofpfw & NXFW_TUN_ID)) {
-rule->flow.tun_id = htonll(ntohll(cookie) >> 32);
+cls_rule_set_tun_id(rule, htonll(ntohll(cookie) >> 32));
}
if (ofpfw & OFPFW_DL_DST) {
diff --git a/tests/ofproto.at b/tests/ofproto.at
index 9506756..fc7ff57 100644
--- a/tests/ofproto.at
+++ b/tests/ofproto.at
@@ -48,10 +48,14 @@ AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS], [0],
[NXST_FLOW reply:
])
AT_CHECK([echo 'in_port=1,actions=0' | ovs-ofctl add-flows br0 -])
AT_CHECK([ovs-ofctl add-flow br0 in_port=0,actions=1])
-AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS | STRIP_DURATION], [0], [dnl
-NXST_FLOW reply:
+dnl Tests for a bug in which ofproto ignored tun_id in tun_id_from_cookie
+dnl flow_mod commands.
+AT_CHECK([ovs-ofctl add-flow -F tun_id_from_cookie br0
tun_id=1,actions=mod_vlan_vid:4])
+AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS | STRIP_DURATION | sort], [0],
[dnl
cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=1
actions=output:0
cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=65534
actions=output:1
+ cookie=0x1, duration=?s, table_id=0, n_packets=0, n_bytes=0,
tun_id=0x1 actions=mod_vlan_vid:4
+NXST_FLOW reply:
])
AT_CHECK([ovs-ofctl del-flows br0])
AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS], [0], [NXST_FLOW reply:
--
1.7.4.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506992: libvtk5-dev: linking against VTK using cmake broken because of multiarch
forcemerge 506992 630559 severity 506992 serious usertags 506992 multiarch tags 506992 sid wheezy thanks Hi there, Bug #630559 is effectively a duplicate of the much-earlier-filed 506992. It is also effectively a release-critical bug, because these hard-coded paths to dependent libraries that have moved as a result of multiarch will now cause any reverse-dependency of vtk to fail to build in unstable. It is /possible/ to solve this by having vtk rebuilt against the libraries in their new paths; however, that's not a very permanent solution, as each of the dependent libs will be moved to multiarch paths one by one over time, which makes for a lot of unnecessary rebuilds of vtk. To avoid this bug from popping back open again, I recommend enacting the complete fix of not exporting dependent library information via cmake when linking. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant "DNSSEC-conformant recursive nameserver" here, not "validating recursive nameserver". the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for ".com" hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 07.06.2011 01:45, schrieb Christian Kastner: I rebuilt the package with (eventually) all patches dropped, unfortunately to no avail: /dev/ttyUSB[0-2] and /dev/gsmmodem are still not present at boot, and there is no log file in /var/log/ with EnableLogging=1. The main inconvenience is the problem that it's hard to get any log if you plug before booting. The file system is mounted read-only first, so switching may succeed but there is no logging at all. Are you sure the switching itself is not happening? Did you check the device ID after booting with the stick? Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630569: [php-maint] Bug#630569: php5-pgsql and postgresql-9.0 seem to collude never to close idle persistent connections
reassign 630569 postgresql-8.4, postgresql-9.0, php5-pgsql thanks On Wed, Jun 15, 2011 at 12:32:35PM +0200, Ondřej Surý wrote: > My first question would be if you can repeat same behaviour under unstable > (and/or wheezy). Before going forward to wheeze, I first tried to reproduce it on clean squeeze because this is affecting my production machines... Unfortunately, I'm seeing the same problem with PostgreSQL 8.4 which is in stable. :( As I mentioned earlier, this is what happens on a separate machine that has been largely upgraded to squeeze, but left with the lenny pgsql server: % dpkg -s libapache2-mod-php5 php5-pgsql postgresql-8.3 | grep Version Version: 5.3.3-7+squeeze1 Version: 5.3.3-7+squeeze1 Version: 8.3.14-0lenny1 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 7 7 7 7 7 7 7 7 7 7 7 7 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 7 7 7 7 7 7 7 7 7 7 7 7 So, the spooling works normally and no excess connections are being left behind. Whereas on a squeeze machine: % dpkg -s libapache2-mod-php5 php5-pgsql postgresql-8.4 | grep Version Version: 5.3.3-7+squeeze1 Version: 5.3.3-7+squeeze1 Version: 8.4.7-0squeeze2 % sudo apache2ctl graceful % ps -C postgres | tail -n +2 | wc -l 5 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 6 7 8 9 10 11 12 13 14 15 16 17 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 18 19 20 21 22 23 24 24 24 24 24 24 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 24 24 24 24 24 24 24 24 24 25 25 25 After that it levels off. And, just to confirm: % sudo -u postgres psql template1 -c 'select datname,usename,current_query from pg_stat_activity;' | sort | uniq -c | sort -n 1 1 datname | usename |current_query 1 template1 | postgres | select datname,usename,current_query from pg_stat_activity; 1 (21 rows) 1 +--+- 20 db1| web | -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625922: Failures with ST2000DL003-9VT166
I upgraded my raid disks to 4 ST32000644NS (Seagate Constellation 2TB) and I haven't had an issue since. I have also moved the cheaper ST2000DL003-9VT166 disks to a Windows XP box (in a non raid environment) and haven't seen a problem in days now. There are plenty of references online now popping up saying that green disks are not designed or supported in a raid environment. Weather or not that's because of a physical issue, or a software issue, im not sure. Paul -- To unsubscribe, send mail to 625922-unsubscr...@bugs.debian.org. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
Hi again Ben, >> >> I've got me RAM replaced a while ago and no sign og the flloding yet, so I >> guess no further testing >> will be posible on my side. :( > > So we don't know whether those were genuine ECC error reports...? > These are the only references reported by dmesg now so, I guess (as you both suggested) was related to faulty RAM modules. [3.769065] EDAC MC: Ver: 2.1.0 May 18 2011 [3.781850] EDAC amd64_edac: Ver: 3.2.0 May 18 2011 [3.781932] EDAC amd64: ECC is enabled by BIOS. [3.781991] EDAC MC: Rev F or later detected [3.782061] EDAC MC0: Giving out device to 'amd64_edac' 'RevF': DEV :00:18.2 [3.782091] EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV ':00:18.2' (POLLED) Feel free to review the patch under you consideration. Despite my new RAM, I'm open for testing if needed. Thanks again. Regards, -- Dario Minnucci Phone: +34 902884117 | Fax: +34 902024417 | Support: (+34) 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 signature.asc Description: OpenPGP digital signature
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: > so unbound forwarding to 4.2.2.1 works, but unbound forwarding to > dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not > fully transparent when forwarding between a validating forwarder and a > validating recursive nameserver. ugh, i meant "DNSSEC-conformant recursive nameserver" here, not "validating recursive nameserver". the level3 open recursives (4.2.2.X) don't perform validation. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630639: [INTL:sv] Swedish strings for ntfs-3g debconf
package: ntfs-3g severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother http://sis.bthstuden.se sv.po Description: Binary data
Bug#619272: [Pkg-oss4-maintainers] Bug#619272: oss4-dkms: Current kernel in archive is 2.6.39 which is still not supported.
This is fixed in 4.2-build2004-1 which was uploaded yesterday. Romain 2011/6/14 Michal Suchanek : > Package: oss4-dkms > Version: 4.2-build2003-1.1 > Followup-For: Bug #619272 > > > oss4-dkms sitll does not build with curent kernel. > > Setting up oss4-base (4.2-build2003-1.1) ... > Setting up oss4-dkms (4.2-build2003-1.1) ... > Loading new oss4-4.2-build2003 DKMS files... > First Installation: checking all kernels... > Building only for 2.6.39-1-amd64 > Building initial module for 2.6.39-1-amd64 > > Error! Bad return status for module build on kernel: 2.6.39-1-amd64 > (x86_64) > Consult the make.log in the build directory > /var/lib/dkms/oss4/4.2-build2003/build/ for more information. > dpkg: error processing oss4-dkms (--configure): > subprocess installed post-installation script returned error exit > status 10 > > cat /var/lib/dkms/oss4/4.2-build2003/build/make.log > DKMS make.log for oss4-4.2-build2003 for kernel 2.6.39-1-amd64 (x86_64) > make: Entering directory `/usr/src/linux-headers-2.6.39-1-amd64' > CC [M] /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.o > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function > ‘alloc_fop’: > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:956: error: > ‘struct file_operations’ has no member named ‘ioctl’ > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:960: warning: > assignment from incompatible pointer type > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function > ‘oss_pci_read_devpath’: > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1634: warning: > return discards qualifiers from pointer target type > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function > ‘oss_fp_check’: > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1858: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1862: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: > comparison of distinct pointer types lacks a cast > /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1869: warning: > comparison of distinct pointer types lacks a cast > make[3]: *** [/var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.o] > Error 1 > make[2]: *** [_module_/var/lib/dkms/oss4/4.2-build2003/build/core] > Error 2 > make[1]: *** [sub-make] Error 2 > make: *** [all] Error 2 > make: Leaving directory `/usr/src/linux-headers-2.6.39-1-amd64' > > > > -- System Information: > Debian Release: wheezy/sid > APT prefers stable > APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, > 'experimental'), (300, 'stable-i386'), (300, 'oldstable'), (280, > 'testing-i386'), (270, 'unstable-i386'), (150, 'experimental-i386'), (65, > 'oldstable-i386') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) > 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 oss4-dkms depends on: > ii 2.1.1.2-6 Dynamic Kernel Module Support > Fram > ii 2.6.39+35 Header files for Linux 2.6-amd64 > ( > ii 2.6.26-13lenny2 Header files for Linux > 2.6.26-1-am > ii 3.local Header files related to Linux > kern > ii 2.6.32-34squeeze1 Header files for Linux > 2.6.32-5-am > ii 2.6.32-30~bpo50+1 Header files for Linux > 2.6.32-bpo. > ii 2.6.34-1~experimenta Header files for Linux > 2.6.34-1-am > ii 2.6.34-rc4-amd64-10. Header files related to Linux > kern > ii 2.6.35-0-amd64-10.00 Header files related to Linux > kern > ii 2.6.36-r600fence-amd Header files related to Linux > kern > ii 2.6.36-rc4-r600fence Header files related to Linux > kern > ii 2.6.37-2 Header files for Linux > 2.6.37-2-am > ii 2.6.38-1 Header files for Linux > 2.6.38-1-am > ii 2.6.38-5 Header files for Linux > 2.6.38-2-am > ii 2.6.39-1+b1 Header files for Linux > 2.6.39-1-am >
Bug#630638: pidgin-sipe: FTBFS with pdigin 2.8.0-1 in unstable
Package: pidgin-sipe Version: 1.11.2-1 Severity: serious Tags: patch Justification: fails to build from source I was trying to rebuild pidgin-sipe against the latest pidgin in unstable and it failed with the following error : . mv -f .deps/libsipe_backend_la-purple-debug.Tpo .deps/libsipe_backend_la- purple-debug.Plo /bin/bash ../../libtool --tag=CC --mode=compile x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Werror -Wall -Wextra -Werror=declaration- after-statement -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpurple -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./../api -DLOCALEDIR=\"/usr/share/locale\" -Wall -g -O2 -MT libsipe_backend_la-purple-dnsquery.lo -MD -MP -MF .deps/libsipe_backend_la- purple-dnsquery.Tpo -c -o libsipe_backend_la-purple-dnsquery.lo `test -f 'purple-dnsquery.c' || echo './'`purple-dnsquery.c libtool: compile: x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Werror -Wall -Wextra -Werror=declaration-after-statement -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpurple -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./../api -DLOCALEDIR=\"/usr/share/locale\" -Wall -g -O2 -MT libsipe_backend_la-purple-dnsquery.lo -MD -MP -MF .deps /libsipe_backend_la-purple-dnsquery.Tpo -c purple-dnsquery.c -fPIC -DPIC -o ..libs/libsipe_backend_la-purple-dnsquery.o In file included from purple-dnsquery.c:25:0: /usr/include/libpurple/dnssrv.h:115:51: error: unknown type name 'PurpleAccount' In file included from purple-dnsquery.c:25:0: /usr/include/libpurple/dnssrv.h:150:51: error: unknown type name 'PurpleAccount' purple-dnsquery.c: In function 'sipe_backend_dns_query': purple-dnsquery.c:60:28: error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors make[4]: *** [libsipe_backend_la-purple-dnsquery.lo] Error 1 make[4]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2/src/purple' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Using a patch from archlinux I found at http://aur.archlinux.org/packages.php?ID=16170&comments=all&detail=0 it was able to build -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin-sipe depends on: ii libc62.13-7 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4 common error description library ii libglib2.0-0 2.28.6-2GLib library of C routines ii libgmime-2.4-2 2.4.25-1MIME message parser and creator li ii libgssapi-krb5-2 1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries - k ii libk5crypto3 1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries - C ii libkrb5-31.9.1+dfsg-1+b1 MIT Kerberos runtime libraries ii libnspr4-0d 4.8.8-1 NetScape Portable Runtime Library ii libnss3-1d 3.12.10-1 Network Security Service libraries ii libpurple0 2.8.0-1 multi-protocol instant messaging l ii libxml2 2.7.8.dfsg-3GNOME XML library pidgin-sipe recommends no packages. pidgin-sipe suggests no packages. -- no debconf information diff -drupN pidgin-sipe-1.11.2/src/purple/purple-dnsquery.c pidgin-sipe-1.11.2-new/src/purple/purple-dnsquery.c --- pidgin-sipe-1.11.2/src/purple/purple-dnsquery.c 2010-11-03 05:13:51.0 +0100 +++ pidgin-sipe-1.11.2-new/src/purple/purple-dnsquery.c 2011-06-11 00:14:57.0 +0200 @@ -22,6 +22,10 @@ #include "glib.h" +#include "version.h" +#if PURPLE_VERSION_CHECK(2,8,0) +#include "account.h" +#endif #include "dnssrv.h" #include "sipe-backend.h" diff -drupN pidgin-sipe-1.11.2/src/purple/purple-plugin.c pidgin-sipe-1.11.2-new/src/purple/purple-plugin.c --- pidgin-sipe-1.11.2/src/purple/purple-plugin.c 2010-11-03 05:13:51.0 +0100 +++ pidgin-sipe-1.11.2-new/src/purple/purple-plugin.c 2011-06-10 23:58:20.0 +0200 @@ -506,6 +506,10 @@ static PurplePluginProtocolInfo prpl_inf NULL, /* get_moods */ NULL, /* set_public_alias */ NULL, /* get_public_alias */ +#if PURPLE_VERSION_CHECK(2,8,0) + NULL, /* add_buddy_with_invite */ + NULL, /* add_buddies_with_invite */ +#endif #endif #endif #endif diff -drupN pidgin-sipe-1.11.2/src/purple/purple-private.h pidgin-sipe-1.11.2-new/src/purple/purple-private.h --- pidgin-sipe-
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
On Wed, 2011-06-15 at 21:38 +0200, Dario Minnucci wrote: > Hi Ben, > > On 06/15/2011 09:13 PM, Ben Hutchings wrote: > > On Wed, 2011-06-15 at 07:50 +0200, Dario Minnucci wrote: > >> Hi again, > >> > >> > >> I've found a reference to this error [0] providing and a possible patch is > >> provided. > >> > >> Regards, > >> > >> [0] https://patchwork.kernel.org/patch/67658/ > > > > I've reopened the bug and will check how it got fixed in mainline Linux > > (not sure whether that patch was applied or not). > > > > Ben. > > > > > I've got me RAM replaced a while ago and no sign og the flloding yet, so I > guess no further testing > will be posible on my side. :( So we don't know whether those were genuine ECC error reports...? Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
clone 629290 -1 reassign -1 dnsmasq retitle -1 dnsmasq: not DNSSEC transparent severity -1 important thanks Maik Zumstrull wrote: > On Wed, Jun 15, 2011 at 21:16, Robert Edmonds wrote: > > > you're most likely running unbound in the default debian config which > > enables DNSSEC validation. if you comment out the > > "auto-trust-anchor-file" line in /etc/unbound/unbound.conf and restart > > unbound, does it start working with your dnsmasq server? > > Yes. For the record, with validation enabled: > > No forwarding: works > Forwarding to 8.8.8.8: fails > Forwarding to 4.2.2.1: works > Forwarding to dnsmasq which forwards to 8.8.8.8: fails > Forwarding to dnsmasq which forwards to 4.2.2.1: fails > > So, breakage at dnsmasq and 8.8.8.8, I think, the latter officially > being a known issue. so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#616150: Workaround found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Stefan, thank you for the confirmation, that the issue is still present in gnucash 1:2.4.6-3. You wrote: > Feel free to ask if I can assist in anything. Can you please send me the output of the command 'locale' on your system? Thanks in advance and regards, Micha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk35DCAACgkQWN0/4pnhQbSCOgCfWBiHQkLIFEwA+gbhmrZACKa7 qZsAnRdMt66vsdgu5SfmfZcSj+ejhA76 =gr2n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
Hi Ben, On 06/15/2011 09:13 PM, Ben Hutchings wrote: > On Wed, 2011-06-15 at 07:50 +0200, Dario Minnucci wrote: >> Hi again, >> >> >> I've found a reference to this error [0] providing and a possible patch is >> provided. >> >> Regards, >> >> [0] https://patchwork.kernel.org/patch/67658/ > > I've reopened the bug and will check how it got fixed in mainline Linux > (not sure whether that patch was applied or not). > > Ben. > I've got me RAM replaced a while ago and no sign og the flloding yet, so I guess no further testing will be posible on my side. :( Thanks for your interest anyway. Regards, -- Dario Minnucci Phone: +34 902884117 | Fax: +34 902024417 | Support: (+34) 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
