Bug#1057450: apt-xapian-index: systemd fails to start apt-xapian-index.service
Package: apt-xapian-index Version: 0.54 Severity: important Dear Maintainer, systemd fails to start apt-xapian-index.service, with the following error: dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: File "/usr/share/apt-xapian-index/plugins/relations.py", line 130, in index dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: self._index_rel(pfx, val, document) dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: File "/usr/share/apt-xapian-index/plugins/relations.py", line 114, in _index_rel dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: doc.add_term(pfx + name.split(None, 1)[0]) dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: ~~~^^^ dic 05 10:35:07 capitanata update-apt-xapian-index[2172331]: IndexError: list index out of range which appears to hint at a bug in the python script. I guess one can still use a previously created apt-xapian index, but while the systemd service fails, it will not get automatically updated. If useful, I'm willing to help testing this. Thanks, best regards Giacomo Mulas -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-xapian-index depends on: ii python3 3.11.6-1 ii python3-apt 2.7.0+b1 ii python3-debian 0.1.49 ii python3-xapian 1.4.22-1+b1 apt-xapian-index recommends no packages. Versions of packages apt-xapian-index suggests: ii python3-xdg 0.28-2 -- no debconf information
Bug#427639: netcdfg-dev: why no fortran 90 support via gfortran?
Package: netcdfg-dev Version: 3.6.1-1 Severity: normal I had to recompile the package from source to enable fortran90 support via gfortran, why is it not enabled by default? It only required some trivial editing of debian/rules to get it to compile on x86_64 (i.e. setting the fortran90 compiler appropriately). Thanks, bye Giacomo Mulas -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (1001, 'stable'), (500, 'proposed-updates'), (99, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-ck2-dsf-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages netcdfg-dev depends on: ii libc6-dev [libc-dev]2.3.6.ds1-13 GNU C Library: Development Librari ii libnetcdf++33.6.1-1 An interface for scientific data a ii libnetcdf3 3.6.1-1 An interface for scientific data a netcdfg-dev recommends no packages. -- no debconf information -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427639: netcdfg-dev: why no fortran 90 support via gfortran?
On Tue, 5 Jun 2007, Matej Vela wrote: severity 427639 wishlist close 427639 netcdf/1:3.6.2-1 merge 219592 427639 thanks Giacomo Mulas <[EMAIL PROTECTED]> writes: I had to recompile the package from source to enable fortran90 support via gfortran, why is it not enabled by default? It only required some trivial editing of debian/rules to get it to compile on x86_64 (i.e. setting the fortran90 compiler appropriately). I believe this is fixed in experimental. Warren, do you think 1:3.6.2-1 is ready for unstable? Indeed it's fixed in experimental, I simply downloaded the source package and it compiled clean and unchanged on etch. I also already compiled and linked against it a rather demanding quantum chemistry code (octopus) and it appears to work all right. Thanks for having fixed this even before asking :) Bye Giacomo -- _____ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#818279: openresolv: resolvconf incorrectly removes spaces between multiple domain names in search_domains
Package: openresolv Version: 3.7.3-1 Severity: normal Dear Maintainer, with the most recent version of openresolv a new bug was introduced. I have search_domains="oa-cagliari.inaf.it dsf.unica.it ca.infn.it " in my resolvconf.conf file, and this used to work flawlessly previously. With the latest release, however, the contents of $search_domains are internally run through the strip_trailing_dots() function before going to the generated resolv.conf file, and in this process spaces separating domains are lost, with the final resolv.conf line reading like search oa-cagliari.inaf.itdsf.unica.itca.infn.it irap.omp.eu You see that the contents of $search_domains are useless because of missing spaces, while the local domain obtained via dhcp is present, correct, and correctly separated. I am fully confident that fixing this will be trivial for someone that knows how the resolvconf script works internally. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.2-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Configuration Files: /etc/network/if-up.d/000resolvconf [Errno 2] File o directory non esistente: u'/etc/network/if-up.d/000resolvconf' /etc/resolvconf.conf changed: resolv_conf=/etc/resolv.conf name_servers=127.0.0.1 dnsmasq=NO pdnsd=NO unbound=NO dnsmasq_resolv=/var/run/dnsmasq/resolv.conf pdnsd_conf=/etc/pdnsd.conf unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf search_domains="oa-cagliari.inaf.it dsf.unica.it ca.infn.it " named_service=bind9 named_options=/etc/bind/named.conf.resolvconf named_zones=/etc/bind/named-zones.resolvconf -- no debconf information
Bug#761050: openresolv sets local bind to always forward requests, even when local bind is authoritative
Hi, sorry for the late reply On Tue, 16 Jun 2015, Herbert Parentes Fortes Neto wrote: The upstream said: "Not really an openresolv bug as I see it. For example 192.168.x.x can route to 10.x.x.x even if both sets are not publicly route-able. In-fact some Spanish ISPs do this for their Internet TV." I regret to say that upstream did not understand my bug report (perhaps I did not explain clearly). I never claimed that requests to resolve unroutable IPs should never be forwarded; I did claim (and maintain) that IF the local bind is set up to be authoritative on a domain (which happens to be an unroutable block of IPs for me, but does not have to be), then openresolv should not override that by always forwarding queries in any case. So the problem is not about forwarding queries involving unroutable addresses (even if that happens in my case) but about forwarding queries that can have (and therefore should have) an authoritative answer from the local bind, without going any further. If I did not explain clearly, please let me know and I will try to explain better. If you confirm wontfix, I will find a way to tweak my local configuration of bind + openresolv to work around this for myself, but I do believe the current behaviour is wrong in principle and in practice, so it should be fixed in a more general way. Bye Giacomo -- _____ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.1506221214050.16...@capitanata.oa-cagliari.inaf.it
Re: [Pkg-utopia-maintainers] Bug#813803: Bug#813803: network-manager: Network-manager update to 1.1.90-4 in unstable broken if resolvconf enabled
On Fri, 5 Feb 2016, Michael Biebl wrote: As you can see, resolvconf returns a non-zero exit code, even though it apparently has properly updated /etc/resolv.conf That non-zero exit code is generated afaics, because resolvconf tries to restart non-existing services and propagates that error to the caller. It should handle that more carefully. This is a bug in openresolv. I'm therefor cloning this bug report and reassign it to openresolv. Thanks Michael. I looked a bit more into it, and I found that apparently it is possible to disable individual openresolv subscribers and/or to tell openresolv what is the name of a service to be restarted in the configuration file. I _think_ I carefully set it up now so that it only tries to restart existing services, and with the appropriate names (e.g. bind9 for named in my case). Therefore, the problem appears to be in openresolv shipping a default configuration which is almost always broken, that requires considerable tinkering to make it work properly (which I had done), and even more tinkering to also make it return the appropriate exit code (which was not at all apparent until network manager broke due to it). Also, the way return codes are concocted and returned by resolvconf is not properly documented as far as I can tell. Return codes are never mentioned in the resolvconf man page. I suggest that resolvconf, upon installation, open a debconf window asking the user which subscribers (s)he wants enabled, enabling only those and disabling the others. At very least, it should give a very visible warning upon installation telling the user that hand configuration is required, and which man pages and files have to be edited. Some examples for common configurations would be helpful. Also, I set up a custom script in /etc/NetworkManager/dispatcher.d/ that sets up configurations for e.g. smtp servers, print servers etc. for each connection. It would be a really welcome improvement to Network Manager and/or resolvconf if this could be made easier for the end user. I attach my Network Manager dispatcher script as an example. This would be more like a wishlist bug on either Network Manager or resolvconf, or both. Or you could place a simplified version of the custom script in /usr/share/doc/networkmanager so that people know how to replicate this. The best way to implement it would probably be with NetworkManager offering package managers of services a simple way of dropping a script in dispatcher.d and setting up environment variables with the connection-dependent information they need to set up things (like e.g. NM_SMTPSERVER=example.debian.org ...). Of course, if connection-dependent authentication credentials are necessary, a safer method for passing them to the service should be devised than passing them in env variables available to anyone. I set up smtp auth credentials in the exim configuration file /etc/exim/passwd.client, for example, and they are available only to the root user and Debian-exim group. Anyway, just a suggestion to think about. Thanks, bye Giacomo -- _____ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _#!/bin/sh -e # Script to dispatch NetworkManager events # # Runs ifupdown scripts when NetworkManager fiddles with interfaces. # See NetworkManager(8) for further documentation of the dispatcher events. if [ -z "$1" ]; then echo "$0: called with no interface" 1>&2 exit 1; fi # Fake ifupdown environment export IFACE="$1" export LOGICAL="$1" export ADDRFAM="NetworkManager" export METHOD="NetworkManager" export VERBOSITY="0" # Run the right scripts case "$2" in up|vpn-up) case "$CONNECTION_UUID" in af7e7a64-2e4e-486d-a581-90347dd93dcc|02c5d61b-980f-4ce9-b17c-6e690eea9454) cp /etc/exim4/update-exim4.conf.conf-dsf /etc/exim4/update-exim4.conf.conf update-exim4.conf /etc/init.d/exim4 reload cp /etc/cups/cups-browsed.conf-default /etc/cups/cups-browsed.conf systemctl try-restart cups-browsed lpadmin -d HP_Color_LaserJet_3000 ;; 8b8dc31f-bc42-44ce-9e7f-0209b5a70aa7) cp /etc/exim4/update-exim4.conf.conf-oac /etc/exim4/update-exim4.conf.conf update-exim4.conf /etc/init.d/exim4 reload cp /etc/cups/cups-browsed.conf-default /etc
