Bug#1041731: Hyphens in man pages
On 2023-10-15 16:08:32, Wookey wrote: > I think you can consider me representative of the typical maintainer > who's intereaction with *roff languages almost entirely takes the > form: 'Oh bloody hell I really ought to write a man page for this > because upstream is too youthful to have done so - now how the hell > does roff/nroff/groff work again' (no I'm not sure which it is I'm > actually using, nor how any of this machinery really works, nor where > to look for good practice, so I mostly copy existing stuff and DDG for > answers, which is less than ideal when it comes to details like this). At least you're not lazy. I am, so what I did many times is add a build-depends on pandoc, and write the man page in rst or md. I think that's a worse solution (pandoc is really heavy), but at least, I don't have to go back to *roff. regards, iustin
Bug#1020246: Not an active maintainer, but
On 2023-06-24 16:58:15, Ilias Tsitsimpis wrote: > Control: forwarded -1 https://github.com/ndmitchell/hoogle/issues/359 > > Hi Iustin, > > On Sun, Apr 23, 2023 at 11:25PM, Iustin Pop wrote: > > AFAIK, both armel and armfh are low-powered/"slow" arches, but i386 is > > surprising. Maybe due to memory limits? > > > > I wonder if tests shouldn't simply be restricted to amd64, arm64, ppc64el > > and > > s390x? This should give it enough of architecture heterogeneity to catch > > any problems that simply do not appear on amd64 (mainstream arch) (yes, > > I've been bitten by this in one package of mine). > > > > This would be a cheap fix (one entry in the control file). Thoughts? > > (Anyone?) It seems this bug is the only one that prevents it from > > entering testing (and it's a leaf package). > > Unfortunately it's not just the tests that fail, hoogle is currently > completely broken on all 32-bit architectures. We need to either fix it, > or remove hoogle from these architectures. Ooh, interesting. I agree with Neil's last comment in the upstream bug - Hoogle was even years ago when I last built it a memory/CPU hog, so I think restricting to 64 bit is better than not having it. My 2c. iustin
Bug#1020246: Not an active maintainer, but
AFAIK, both armel and armfh are low-powered/"slow" arches, but i386 is surprising. Maybe due to memory limits? I wonder if tests shouldn't simply be restricted to amd64, arm64, ppc64el and s390x? This should give it enough of architecture heterogeneity to catch any problems that simply do not appear on amd64 (mainstream arch) (yes, I've been bitten by this in one package of mine). This would be a cheap fix (one entry in the control file). Thoughts? (Anyone?) It seems this bug is the only one that prevents it from entering testing (and it's a leaf package). regards, iustin
Bug#1029302: python-mox: obsolete, rc-buggy, should be removed
On 2023-01-20 22:24:39, Timo Röhling wrote: > Hi, > > python3-mox has no reverse dependencies, last upstream activity is from > 2018, the package is RC-buggy and there are plenty of Python mock > libraries available already. Thanks for checking - I was going to do so this weekend. For the last release, there were still about 8 packages (IIRC - could be wrong, of course), so didn't ask for removal back then. As you say, this is old tech. The only and really only reason to keep it was for reverse deps. I'll have to check how to make the ROM official, haven't done that in a looong while :) thanks, iustin
Bug#508376: Many years later...
Many years later, any chance of changing the default? Or nobody runs mail servers maybe? Just saw the same behaviour on one of my machines, and was surprised at the duplicate contents. thanks, iustin
Bug#1012026: I believe this was actually the radeon driver
Upon further investigation, I believe this crash is actually due to #1009325 in the radeon driver. At least, after updating the radeon driver and xserver-xorg-core to sid latest, this doesn't occur anymore.
Bug#1019846: Backports for borgmatic?
Source: borgmatic Version: 1.6.3-1 Severity: wishlist Hi, While borg has backports, I don't see any for borgmatic. But looking at the release history for it (borgmatic), I can see some new features that I think are worth having in stable (as a backport), e.g.: - 1.5.15 with 425: Run arbitrary Borg commands with new "borgmatic borg" action (greatly simplifies interacting with repositories, IMO). - 1.5.23 with #394: Compact repository segments and free space with new "borgmatic compact" action. Borg 1.2+ only. Also run "compact" by default when no actions are specified, as "prune" in Borg 1.2 no longer frees up space unless "compact" is run. (borg 1.2 is in backports, and without this, space will leak) - 1.6.2 with #523: Reduce the default consistency check frequency and support configuring the frequency independently for each check Now, I see upstream as very active and not sure what the policy for backports should be (one-off? continuous update? etc.), but I think it would be good to have some consistency between borg's backports policy and borgmatic's. It might be that if borg 2.0 gets into sid and then via backports into bullseye, borgmatic in bullseye will completely stop working with it. thanks! iustin -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.61-teal0 (SMP w/24 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1019347: Please package new upstream which includes the fix
>From what I see, upstream version 1.7.1 fixes this (https://github.com/borgmatic-collective/borgmatic/releases/tag/1.7.1): #574: Fix for potential data loss (data not getting backed up) when the "patterns" option was used with "source_directories" (or the "~/.borgmatic" path existed, which got injected into "source_directories" implicitly). The fix is for borgmatic to convert "source_directories" into patterns whenever "patterns" is used, working around a potential Borg bug: borgbackup/borg#6994 Could you please package that (or the newer 1.7.2) to work around this? thanks! iustin
Bug#1012026: X segfaults in OsLookupColor+0x135 after upgrade to 2:21.1.3-2+b1
Package: xserver-xorg-core Version: 2:21.1.3-2+b1 Severity: important After upgrading to 2:21.1.3-2+b1, X consistently segfaults with the stacktrage in the attached log. Downgrading selected packages as follows: xserver-xorg-input-evdev=1:2.10.6-2 xserver-xorg-input-mouse=1:1.9.3-1 xserver-xorg-video-dummy=1:0.3.8-1+b1 xserver-xorg-video-radeon=1:19.1.0-2 xserver-xorg-core=2:1.20.14-1 fixes the problem, and this is how I've kept them pinned for a few months, hoping a new version comes along that solves this, but it hasn't happened, so filing this bug report. This is on a fully-updated sid machine, with custom built kernel (right now, 5.15.43). -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Sep 5 2015 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Feb 12 11:32 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 2 -rw-r--r-- 1 root root 302 Nov 14 2016 10-monitor.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.15.43-teal0 (iusty@teal) (gcc (Debian 11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP Sun May 29 01:06:22 CEST 2022 Xorg X server log files on system: -- -rw-r--r-- 1 iusty iusty 12692 May 29 01:25 /home/iusty/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 root root 33876 May 29 01:25 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 616.975] X.Org X Server 1.21.1.3 X Protocol Version 11, Revision 0 [ 616.979] Current Operating System: Linux teal 5.15.43-teal0 #1 SMP Sun May 29 01:06:22 CEST 2022 x86_64 [ 616.979] Kernel command line: BOOT_IMAGE=/vmlinuz-5.15.43-teal0 root=/dev/mapper/vg845dc-root ro iommu=pt [ 616.981] xorg-server 2:21.1.3-2+b1 (https://www.debian.org/support) [ 616.982] Current version of pixman: 0.40.0 [ 616.984]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 616.984] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 616.989] (==) Log file: "/var/log/Xorg.0.log", Time: Sun May 29 01:25:42 2022 [ 616.990] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 616.992] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 616.992] (==) No Layout section. Using the first Screen section. [ 616.992] (==) No screen section available. Using defaults. [ 616.992] (**) |-->Screen "Default Screen Section" (0) [ 616.992] (**) | |-->Monitor "" [ 616.992] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 616.992] (==) Automatically adding devices [ 616.992] (==) Automatically enabling devices [ 616.992] (==) Automatically adding GPU devices [ 616.992] (==) Automatically binding GPU devices [ 616.992] (==) Max clients allowed: 256, resource mask: 0x1f [ 616.992] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 616.992]Entry deleted from font path. [ 616.992] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 616.992] (==) ModulePath set to "/usr/lib/xorg/modules" [ 616.992] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 616.992] (II) Loader magic: 0x556719de3f20 [ 616.992] (II) Module ABI versions: [ 616.992]X.Org ANSI C Emulation: 0.4 [ 616.992]X.Org Video Driver: 25.2 [ 616.992]X.Org XInput driver : 24.4 [ 616.992]X.Org Server Extension : 10.0 [ 616.992] (--) using VT number 4 [ 616.992] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 616.992] (II) xfree86: Adding drm device (/dev/dri/card0) [ 616.992] (II) Platform probe for /sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0 [ 616.994] (--) PCI:*(8@0:0:0) 1002:6779:1043:03da rev 0, Mem @ 0xe000/268435456, 0xfcf2/131072, I/O @ 0xd000/256, BIOS @ 0x/131072 [ 616.994] (II) LoadModule: "glx" [ 616.994] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 616.994] (II) Module glx: vendor="X.Org
Bug#972758: ABI breakage without soname bump
On 2020-10-23 15:32:48, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote: > > If we want to support the interim versions that have never been in a > > stable release, then I think the only way is to bump the minmum > > version in liburing shlibs and symbols files to 0.7, then rebuild the > > couple of packages built with 0.6 against 0.7, and then add Breaks in > > liburing against the old dependent package versions using the previous > > liburing releases. > > Well, seemingly there are people who run old sid, and then only > “apt update ; apt install plocate” -- which will pull in newer plocate > but not liburing1 :-) Yes, but those people know (or should know) that this is somewhat risky, always. I do that sometimes, but I'm not surprised when things do break. > But all that _must_ be supported as per Policy is upgrades from stable to > stable, I believe? Not entirely sure how strict it is. It helps that > liburing1 has never been in stable (only stable-bpo). +1 here, stable-to-stable should be enough.
Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
On 2020-10-10 13:34:16, Bernhard Übelacker wrote: > Dear Maintainer, > tried to have a look at this one, found the segfault [1], > and can point to the place where the pointer gets overwritten [2]. > Unfortunately Valgrind or ASAN gave me not more details. Thanks for this information. To me, this is clearly a bug in ghostscript, which is just incidentally triggered by a PDF shipped by doc-rfc. It could be just as well a PDF downloaded from the internet :/ As such, I think it is correct that this is a serious bug on ghostscript, but not in doc-rfc, so I will mark it not found in that package. Of course, I'm biased since I'm the maintainer of doc-rfc, but I think it's a fair assesment. thanks, iustin
Bug#960809: inet6 static method privext setting is "incomplete"
Package: ifupdown Version: 0.8.35+b1 Severity: normal Tags: ipv6 >From reading interfaces(5) for inet6/static, I had assumed that specifying "privext 2" (or even 1) on a such an interface definition would result in the behaviour of having both the statically-defined address and the temporary/privacy ones. However, the 'mngtmpaddr' flag is not set on the added address, which means that the kernel will not manage (create/update/etc.) the temporary addresses. Hence, the sysctl is then meaningless, as the kernel has no "template" address from which to create one. I've worked around my interface definition with a 'post-up ip a change … mgntmpaddr', which seems to work and gives me the 2 addresses. It might be that I misunderstand the inet6.defn file syntax however, so if the error is on my part, let me know - I'll try to improve the docs. My interface definition iface xxx inet6 static address … netmask 64 accept_ra 2 privext 2 -- Package-specific info: --- /etc/network/interfaces: # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface auto lo iface lo inet loopback up ip -6 r add unreachable 2001:1620:0f07:f000::/52 up ip -6 r add unreachable 2406:da00:ff00::0/48 #auto lan-ext iface lan-ext inet dhcp auto enp7s0f0 iface enp7s0f0 inet static network 10.1.167.0 address 10.1.167.28 netmask 255.255.255.0 broadcast 10.1.167.255 gateway 10.1.167.8 #up ip r add unreachable 10.1.167.7 up ip r add unreachable 10.1.167.1 #up ip r add unreachable 10.1.167.5 up ip r add 10.1.1.0/24 via 10.1.167.7 up ip r add 10.1.2.0/24 via 10.1.167.7 up ip r add 10.2.0.0/16 via 10.1.167.7 up ip r add 10.3.0.0/16 via 10.1.167.7 up ip r add 10.7.0.0/16 via 10.1.167.7 up ip r add 192.168.0.0/16 via 10.1.167.27 up ip r add 192.168.37.0/24 via 10.1.167.8 down ip r del unreachable 10.1.167.1 #down ip r del unreachable 10.1.167.5 up ip a add 192.168.8.2/32 dev enp7s0f0 down ip a del 192.168.8.2/32 dev enp7s0f0 up ip a add 10.1.167.32/32 dev enp7s0f0 up ip a add 10.1.167.33/32 dev enp7s0f0 down ip a del 10.1.167.32/32 dev enp7s0f0 down ip a del 10.1.167.33/32 dev enp7s0f0 iface enp7s0f0 inet6 static #address 2001:1620:0f07:1::28 address 2a02:168:7b0d:a1::28 netmask 64 accept_ra 2 privext 2 #post-up ip a add 2a02:168:7b0d:a1::28/64 dev enp7s0f0 #auto vlan1 #iface vlan1 inet static #vlan-raw-device enp7s0f0 #network 192.168.2.0 #address 192.168.2.28 #netmask 255.255.255.0 #broadcast 192.168.2.255 #auto tap0 iface tap0 inet static address 192.168.10.1 netmask 255.255.255.0 network 192.168.10.0 broadcast 192.168.10.255 tunctl_user uml-net #tunctl_user iusty #auto tap1 iface tap1 inet static address 192.168.11.1 netmask 255.255.255.0 network 192.168.11.0 broadcast 192.168.11.255 tunctl_user iusty #auto tap1 iface tap2 inet static address 192.168.10.10 netmask 255.255.255.252 network 192.168.10.8 broadcast 192.168.10.11 tunctl_user iusty #auto tap3 iface tap3 inet static address 192.168.8.1 netmask 255.255.255.252 network 192.168.8.0 broadcast 192.168.8.3 tunctl_user rtorrent auto uml0 iface uml0 inet static address 192.168.24.1 netmask 24 #bridge_ports tap20 tap21 bridge_ports none bridge_maxwait 0 bridge_maxfd 0 #pre-up tunctl -u iusty -t tap20 #pre-up tunctl -u iusty -t tap21 #auto uml1 iface uml1 inet static address 192.168.24.1 netmask 255.255.255.0 bridge_ports none bridge_maxwait 0 bridge_maxfd 0 # for virtualbox #auto dummy0 iface dummy0 inet static address 192.168.24.1 netmask 255.255.255.0 iface dummy0 inet6 static address 2001:1620:0f07:f000::28 netmask 64 up ip l set dummy0 arp on iface wlan0 inet static hostapd /etc/hostapd/hostapd.conf address 192.168.36.1 netmask 255.255.255.0 --- up and down scripts installed: /etc/network/if-down.d: total 4 -rwxr-xr-x 1 root root 372 Mar 17 2014 openvpn -rwxr-xr-x 1 root root 800 Jan 9 2017 postfix /etc/network/if-post-down.d: total 4 lrwxrwxrwx 1 root root 29 Apr 30 10:06 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 138 Apr 5 17:44 chrony -rwxr-xr-x 1 root root 1433 Jan 2 2019 vlan /etc/network/if-pre-up.d: total 10 lrwxrwxrwx 1 root root 29 Apr 30 10:06 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 344 Jun 7 2010 ethtool -rwxr-xr-x 1 root root 137 Aug 16 2016 uml-utilities -rwxr-xr-x 1 root root 4224 Feb 21 2019 vlan /etc/network/if-up.d: total 20 -rwxr-xr-x 1 root root 138 Apr 5 17:44 chrony -rwxr-xr-x 1 root root 1685 Sep 22 2014 ethtool -rwxr-xr-x 1 root root 677 Nov 26 2017 ip -rwxr-xr-x 1 root root 729 Dec 18 2016 miredo -rwxr-xr-x 1 root root 4937
Bug#949228: python{,3}-mox: Missing dependency on python{,3}-six
On 2020-01-18 15:38:18, Adrian Bunk wrote: > Package: python3-mox > Version: 0.7.8-3 > Severity: serious > Control: affects -1 python-mox > > ? python3 > Python 3.7.6 (default, Dec 19 2019, 09:25:23) > [GCC 9.2.1 20191130] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import mox > Traceback (most recent call last): > File "", line 1, in > File "/tmp/python-mox-0.7.8/mox.py", line 72, in > import six > ModuleNotFoundError: No module named 'six' > >>> > $ python > Python 2.7.17 (default, Oct 19 2019, 23:36:22) > [GCC 9.2.1 20191008] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import mox > Traceback (most recent call last): > File "", line 1, in > File "mox.py", line 72, in > import six > ImportError: No module named six > >>> > $ > > > Adding "python-six, python3-six" to the test dependencies fixed the tests, > but didn't address the actual problem that the packages need these > dependencies (which caused the test failure). … and this is what hid this problem from the autopkgtest - the tests have the dependencies, so nothing showed that the package itself is broken. Thanks, will fix. iustin
Bug#954533: This is likely libssl1.1 problem
This happens in othe packages - well, not the FTBFS, but the error, like getmail. It's been reported in other distros as well, e.g. see https://bugs.archlinux.org/task/65976. Maybe re-assign to libssl1.1?
Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci
On 2019-12-22 11:27:25, Salvatore Bonaccorso wrote: > Control: tags -1 + pending > > Hi Andrea, > > On Sun, Dec 22, 2019 at 08:46:42AM +0100, Andrea Palazzi wrote: > > Package: firmware-realtek > > Version: 20190717-2 > > Followup-For: Bug #935969 > > > > Hi, > > > > What's keeping this bug from being fixed, given that there's a patch > > available? > > Is there something that I can do to help? > > > > Also, shouldn't it be an important bug, since it makes unusable the wifi in > > systems with boars using the rtw88 firmware? > > It would need a slightly different approach, because the rules.gen is > generated. Sjoerd Simons proposed the changes in > https://salsa.debian.org/kernel-team/firmware-nonfree/merge_requests/10 > . > > The packaging itself needs more changes to be finalized, but the > support is now commited. That's great to hear, but any chance of uploading a -3 version? This is still broken for such devices (and thus prevents using a backported kernel, for example). thanks, iustin
Bug#946036: Broken by boost dropping Python 2 support
Package: ledger Version: 3.1.2+dfsg1-1 Severity: grave What happens: $ ledger ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory $ $ dpkg -L libboost-python1.67.0 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libboost_python37.so.1.67.0 /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.67.0 /usr/share /usr/share/doc ... Boost changelog: boost1.67 (1.67.0-14) unstable; urgency=medium ... * Drop py2 builds. (Closes: #936227) ... -- Dimitri John Ledkov Thu, 28 Nov 2019 07:17:15 + Not sure whether this was properly expressed via build-depends and just ignored by boost maintainers, or was missing as explicit dependency, but right now ledger is broken, so FYI. Feel free to re-assign/move/etc. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.1-teal3 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ledger depends on: ii libboost-filesystem1.67.0 1.67.0-15 ii libboost-iostreams1.67.0 1.67.0-15 ii libboost-python1.67.0 1.67.0-15 ii libboost-regex1.67.0 1.67.0-15 ii libboost-system1.67.0 1.67.0-15 ii libc6 2.29-3 ii libgcc11:9.2.1-21 ii libgmp10 2:6.1.2+dfsg-4 ii libicu63 63.2-2 ii libmpfr6 4.0.2-1 ii libpython2.7 2.7.17-1 ii libstdc++6 9.2.1-21 ledger recommends no packages. Versions of packages ledger suggests: ii elpa-ledger3.1.2~pre3+g5067e408-2 pn python-ledger -- no debconf information
Bug#938107: Quick update
Just for the record, this does build a python 3 module, removing the python 2 one is just a matter of rdeps being migrated.
Bug#938073: Quick update
Just for the record, this does build a python 3 module, removing the python 2 one is just a matter of rdeps being migrated.
Bug#937929: Quick update
Just for FYI, this now exports a Python 3 module, droppin the Python 2 one is just a matter of rdeps.
Bug#936604: getmail: Python2 removal in sid/bullseye
On 2019-11-14 00:24:15, Osamu Aoki wrote: > On Wed, Nov 13, 2019 at 03:31:04PM +0100, Iustin Pop wrote: > > On 2019-11-13 15:06:54, Thomas Goirand wrote: > > > On 11/12/19 4:37 PM, Osamu Aoki wrote: > > > > The related binary packages are available in 2 binary names (depending > > > > on release) > > > > getmail4 (version=4,5) popcon installed ~2000 > > > > getmail (version=3,5) popcon installed ~1000 > > > > > > > > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1 > > > > > > > > I think this qualifies for "py2keep". > > > > > > IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail, > > > which is still available in Debian (and with 4 times the number of > > > installed package in popcon...). So I see no reason to keep getmail > > > then. Maybe tell this to upstream, and they may think another time. > > > > Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK) > > the only tool that works for gmail with ASPs disabled (i.e. with OAUTH). > > > > Heck, I'd be very willing to maintain Py3 patches myself, because I need > > this tool. > > Please take over packaging from me then. You are welcome. I would gladly help with co-maintenance, but taking over packaging would be my least preferred option. Thanksfully, it seems the upstream is willing to move to Python 3, so I think situation is pretty good, actually. thank you!
Bug#936604: getmail: Python2 removal in sid/bullseye
On 2019-11-13 15:06:54, Thomas Goirand wrote: > On 11/12/19 4:37 PM, Osamu Aoki wrote: > > The related binary packages are available in 2 binary names (depending on > > release) > > getmail4 (version=4,5) popcon installed ~2000 > > getmail (version=3,5) popcon installed ~1000 > > > > https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1 > > > > I think this qualifies for "py2keep". > > IMO, this qualifies for RM-RoM. getmail is an alternative to fetchmail, > which is still available in Debian (and with 4 times the number of > installed package in popcon...). So I see no reason to keep getmail > then. Maybe tell this to upstream, and they may think another time. Uh, no. Functionality-wise, they're quite different. getmail is (AFAIK) the only tool that works for gmail with ASPs disabled (i.e. with OAUTH). Heck, I'd be very willing to maintain Py3 patches myself, because I need this tool. regards, iustin
Bug#942537: Please package newer version
On 2019-10-21 10:01:43, Sven Hoexter wrote: > On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote: > > Hi, > > > > 2) You can also update it to fio 3.16 and upload that. I would be okay > > > with an NMU. > > > > I currently look into this option. Since we set it up on Salsa in the > > Debian group, I can update the package. But let me see if it builds here. > > I just uploaded 3.16 and pushed everything to salsa. Had to add a small > oneline fix from upstream to get the gfio stuff to build. The patch can > be removed with 3.17+. > > Hope that helps for now, didn't do any polishing of typos. Thank you very much!
Bug#941562: python-mox: diff for NMU version 0.7.8-1.1
On 2019-10-13 18:30:54, Sandro Tosi wrote: > > > all of this so that i will be able to upgrade nsscache from python2 to > > > python3: > > > it requires pymox for tests. > > > > Honestly last I looked at mox, the mock library shipped with python was > > as good, so maybe a better thing would be to port the unittests. But, > > that's a separate thing. > > i agree upstream projects should move to mock but not all of them are there > yet. > > > > It would also be great if you'd consider migrating your python packages to > > > the DPMT team :) > > > > I'd have to learn what needs to be done first, but given this is already > > under debian with righs for all DDs, what would DPMT bring on top? > > i think the most important reason is mentioned in the policy: > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > > ``` > by packaging available modules that may be useful and > providing a central location for packages maintained by a team, hence > improving responsiveness, integration, and standardization. > ``` > > in the case of the py2 removal process, it would be extremely helpful > to have as many packages as possible in the team, so that we could > have a more standardize approach to upload packages to remove their > py2 packages. of course, it's your choice where you want to maintain > your packages, i just think for a python module, that place is DPMT Ack, understood. Migrating is an option, but low on my priority list :) BTW, the NMU introduced a bug in the autopkgtest so testing migration was blocked (yay!). I've just uploaded 0.7.8-2 to fix this, but again, thanks a lot for finding the new upstream and updating the package, appreciated. iustin
Bug#942537: Please package newer version
On 2019-10-18 08:00:28, Martin Steigerwald wrote: > Hi Iustin. > > Am Donnerstag, den 17.10.2019, 21:14 +0200 schrieb Iustin Pop: > > Package: fio > > Version: 3.12-2 > > Severity: wishlist > > > > I reported earlier this year a bug against fio > > (https://github.com/axboe/fio/issues/738) only to find that it was > > long > > fixed upstream, actually. Sid has 3.12, upstream is at 3.16. Could you > > please package a newer version? > > I have no time to attend to fio at the moment as I am overloaded with > other things and really need to take care of myself now. This will > likely not change for the next at least two weeks, probably longer. Hey, we're all volunteers here, no worries at all! > However… I upgraded the packaging repo for 3.15 quite some time ago > already¹. I did not ask Sven Hoexter, my sponsor, to upload it > immediately cause I was waiting for a merge request regarding: > > fio FTCBFS: builds for the build architecture > > https://bugs.debian.org/929579 Ouch. Custom cross-compile? > From here there are several options: > > 1) Sven or you review the fio 3.15 package and upload it. In case there > are any fixes, please not tough, that I may not have time to apply them > at the moment. > > 2) You can also update it to fio 3.16 and upload that. I would be okay > with an NMU. > > 3) You build the fio 3.15 package yourself or I can make the packages I > build available to you. > > If 3.15 would be enough for now, I think option 1 would be a good way to > go. > > Thank you for your understanding. Thank you as well for the fast reply! I'll try to take a look at the package itself in the next few weeks, my time is also limited, and reply to this bug. thanks! iustin
Bug#942537: Please package newer version
Package: fio Version: 3.12-2 Severity: wishlist I reported earlier this year a bug against fio (https://github.com/axboe/fio/issues/738) only to find that it was long fixed upstream, actually. Sid has 3.12, upstream is at 3.16. Could you please package a newer version? thanks! iustin -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.71-tea1 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fio depends on: ii init-system-helpers 1.57 ii libaio1 0.3.112-5 ii libc62.29-1 ii libgfapi06.5-1 ii libibverbs1 24.0-2 ii libnuma1 2.0.12-1+b1 ii librados212.2.11+dfsg1-2.1+b2 ii librbd1 12.2.11+dfsg1-2.1+b2 ii librdmacm1 24.0-2 ii python2.72.7.16-4 ii zlib1g 1:1.2.11.dfsg-1+b1 fio recommends no packages. Versions of packages fio suggests: pn gfio ii gnuplot-qt [gnuplot] 5.2.7+dfsg1-3 pn python-scipy -- no debconf information
Bug#941562: python-mox: diff for NMU version 0.7.8-1.1
On 2019-10-01 20:31:21, Sandro Tosi wrote: > Package: python-mox > Version: 0.5.3-5 > Severity: normal > Tags: patch pending > > > Dear maintainer, > > I've prepared an NMU for python-mox (versioned as 0.7.8-1.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. Hi! Wow, you did all the work, no need to delay. I'll just leave it to enter the archive as-is. > pymox is still needed by a handful of packages, and it looks like someone > picked up upstream duties at https://github.com/ivancrneto/pymox so i prepared > an NMU to upgrade the packge to 0.7.8, which includes python3 support. I was sure this was going to be Removal soon, but if it has a new upstream, by all means. > all of this so that i will be able to upgrade nsscache from python2 to > python3: > it requires pymox for tests. Honestly last I looked at mox, the mock library shipped with python was as good, so maybe a better thing would be to port the unittests. But, that's a separate thing. > feel free to re-version it at -1 and upload it directly, and i'll cancel the > NMU. This is now entering the archive in 2 days, I'll leave as such :) > It would also be great if you'd consider migrating your python packages to > the DPMT team :) I'd have to learn what needs to be done first, but given this is already under debian with righs for all DDs, what would DPMT bring on top? thanks! iustin
Bug#918249: doc-rfc: please switch to ps2txt for testsuite
On 2019-01-04 21:26:03, Iustin Pop wrote: > On 2019-01-04 20:16:40, Gianfranco Costamagna wrote: > > thanks for having a look! I was wondering about something more subtle and > > behind the scenes :) > > btw for some reasons the ci is not running the testsuite on > > unstablehttps://ci.debian.net/packages/d/doc-rfc/probably because testing > > is sad? > > I don't know, I tried the -2 I committed on git on debomatic and the > > autopkgtestsuite was good :) > > Hrmm, I thought I'd get an email about this, but no, seems I have to > look manually at ddpo. One more thing to add to my notes… > > I'll try to sort this out soon, before the soft freeze. Not sure I can > finish everything this weekend. This is very weird. My procedure for uploading a new package includes running an autopkgtest manually, and I see now that this fails (on the version I uploaded), I don't know why I missed it before the most recent upload. Unfortunately I don't have a fully automated 'build-check-upload' pipeline, so most likely human error/oversight. In any case, I'll be more careful in the future. New version is uploading right now. thanks, iustin
Bug#918249: doc-rfc: please switch to ps2txt for testsuite
On 2019-01-04 20:16:40, Gianfranco Costamagna wrote: > thanks for having a look! I was wondering about something more subtle and > behind the scenes :) > btw for some reasons the ci is not running the testsuite on > unstablehttps://ci.debian.net/packages/d/doc-rfc/probably because testing is > sad? > I don't know, I tried the -2 I committed on git on debomatic and the > autopkgtestsuite was good :) Hrmm, I thought I'd get an email about this, but no, seems I have to look manually at ddpo. One more thing to add to my notes… I'll try to sort this out soon, before the soft freeze. Not sure I can finish everything this weekend. iustin
Bug#918249: doc-rfc: please switch to ps2txt for testsuite
On 2019-01-04 19:45:26, Gianfranco Costamagna wrote: > Source: doc-rfc > Version: 20181229-1 > Severity: serious > tags: patch > > Hello, the following Ubuntu patch [1] does the switch from pstotext (really > unmaintained, and out from testing), > to ps2txt, part of src:ghostscript. > > I'm filing this bug as "serious", because it means that the autopkgtestsuite > is not runnable with a "testing" codebase > (since pstotext is out from buster) > > [1] > https://launchpadlibrarian.net/364763538/doc-rfc_20170121-1_20170121-1ubuntu1.diff.gz > > I'm also committing the fix for this bug on git, feel free to upload it (or > ask me to do it)! Ouch, I completely forgot about this issue, really sorry. doc-rfc has so many wishlist bugs but I got into the bad habit of not actually looking at the bug list. Thanks, I'll make an upload over the weekend. iustin
Bug#916428: Can confirm closing sockets fixes the issue
The patch to use sendall() instead of send() doesn't fix things for me. I can confirm that applying additionally 0001-qemu-close-sockets-after-being-done-with-them.patch does fix the problem (don't know if sendall() is needed or not). signature.asc Description: PGP signature
Bug#890720: Request for new debian-switzerland list
On 2018-02-17 23:48:38, Didier 'OdyX' Raboud wrote: > I hereby invite commun...@lists.debian.ch subscribers to voice their > interest/support on the Debian bug for the creation of that list. +1, and +1 for 'debian-switzerland'. iustin signature.asc Description: PGP signature
Bug#854422: Packaged and waiting in NEW
This is packaged now, and waiting in the NEW queue. signature.asc Description: PGP signature
Bug#886888: monitoring-plugins-basic: check_smtp bug with custom command and SSL
Package: monitoring-plugins
Version: 2.2-3
Severity: important
Tags: patch
Hi,
The check_smtp command has a bug when both SSL is enable and check
command (-C) are passed.
The code for check commands is:
while (n < ncommands) {
xasprintf (_str, "%s%s", commands[n], "\r\n");
my_send(cmd_str, strlen(cmd_str));
…
And this works when SSL is not used, because n in initialized at the
start of main, and not used until this block. However, when SSL is
enabled, n is assigned the size of the server's second EHLO response (I
think in bytes), which will usually be significantly higher than the
command passed. As such, no commands are executed and no responses are
checked, which - silently - defeats the desired checks and results in a
success value.
I've attached a trivial patch which simply initializes n before it is
used, and marked as important because of the silent data loss and
triviality of fixing this. Would appreciate if you can apply and forward
upstream.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.75-teal0 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages monitoring-plugins depends on:
ii monitoring-plugins-basic 2.2-3
ii monitoring-plugins-standard 2.2-3
monitoring-plugins recommends no packages.
Versions of packages monitoring-plugins suggests:
ii icinga2 2.7.0-1
ii nagios-plugins-contrib 21.20170222
-- no debconf information
Description: Fix check_smtp handling of custom commands with SSL
Author: Iustin Pop <ius...@debian.org>
--- a/plugins/check_smtp.c
+++ b/plugins/check_smtp.c
@@ -293,6 +293,7 @@
printf("%s", buffer);
}
+ n = 0;
while (n < ncommands) {
xasprintf (_str, "%s%s", commands[n], "\r\n");
my_send(cmd_str, strlen(cmd_str));
Bug#862669: check_whois is confused by multiple entries in whois output
Package: nagios-plugins-contrib
Version: 21.20170222
Severity: normal
Hi,
The whois output on my domain looks like this:
# registry expiry date: 2019-12-06t22:49:48z
# registrar registration expiration date:
This means that the script first assign the valid date to expiry, then
overwrites it with the empty field. I think it would be a much better
idea to only overwrite $expires with the extracted value if non-empty,
i.e. changing code of the type:
} elsif (/expires:\s+([-\w\s]+)/) {
$expires = $1;
into:
} elsif (/expires:\s+([-\w\s]+)/) {
$expires = $1 if $1;
I forgot all perl I know, so I don't know if this is idiomatic or not,
but something along these line for all the 'if' branches in the output
parsing would be useful. Even better would be to only accept valid
dates, and not all non-empty text.
(debsums errors because I fixed this issue in my installation)
thanks!
iustin
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.18-teal0 (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
Init: systemd (via /run/systemd/system)
nagios-plugins-contrib depends on no packages.
Versions of packages nagios-plugins-contrib recommends:
ii bind9-host 1:9.10.3.dfsg.P4-12.1
ii binutils 2.28-2
pn freeipmi-tools
ii libc6 2.24-9
ii libdata-validate-domain-perl 0.10-1
ii libdata-validate-ip-perl 0.27-1
ii libdate-manip-perl 6.57-1
pn libdbd-mysql-perl
ii libio-socket-ssl-perl 2.044-1
ii libipc-run-perl0.94-1
ii liblocale-gettext-perl 1.07-3+b1
pn liblwp-useragent-determined-perl
ii libmail-imapclient-perl3.38-1
pn libmemcached11
pn libmemcachedutil2
pn libmonitoring-plugin-perl | libnagios-plugin-perl
ii libnet-cups-perl 0.63-1
ii libnet-dns-perl1.07-1
pn libnet-dns-sec-perl
ii libnet-smtp-ssl-perl 1.04-1
ii libnet-smtp-tls-perl 0.12-3
pn libnet-smtpauth-perl
ii libnet-snmp-perl 6.0.1-2
ii libnet-ssleay-perl 1.80-1
pn libreadonly-perl
pn libredis-perl
ii libtimedate-perl 2.3000-2
pn libvarnishapi1
pn libwebinject-perl
ii libxml-simple-perl 2.22-1
ii libyaml-syck-perl 1.29-1+b2
ii lsof 4.89+dfsg-0.1
pn nagios-plugins-basic
ii openssl1.1.0e-1
ii perl-base [libsocket-perl] 5.24.1-2
pn perl:any
ii python 2.7.13-2
pn python-pymongo
ii ruby 1:2.3.3
ii snmp 5.7.3+dfsg-1.7
ii whois 5.2.15
Versions of packages nagios-plugins-contrib suggests:
pn backuppc
pn cciss-vol-status
pn expect
pn libsys-virt-perl
ii moreutils 0.60-1
pn mpt-status
ii nagios-plugin-check-multi 0.26-3
pn percona-toolkit
ii perl-doc 5.24.1-2
ii python2.7 2.7.13-2
pn smstools
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/nagios/plugins/check_whois (from
nagios-plugins-contrib package)
signature.asc
Description: PGP signature
Bug#854422: ITP: multitime -- an to time which runs a command multiple times and gives detailed stats
On 2017-02-06 16:46:55, Matt Zagrabelny wrote:
> Is the subject missing a word?
>
> "an *extension* to time..." ?
Yes, for some reason my mailer ate the word, I corrected it in the body
of the email but forgot to fix the subject.
I also struggled to find a short short-description, suggestions welcome
(see below for the latest attempt).
thanks,
iustin
> On Mon, Feb 6, 2017 at 4:37 PM, Iustin Pop <ius...@debian.org> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Iustin Pop <ius...@debian.org>
> >
> > * Package name: multitime
> > Version : 1.3
> > Upstream Author : Laurence Tratt <lau...@tratt.net>
> > * URL : http://tratt.net/laurie/src/multitime/
> > * License : BSD
> > Programming Lang: C
> > Description : a time-like tool which does multiple runs
> >
> > Unix's time utility is a simple and often effective way of measuring
> > how long a command takes to run ("wall time"). Unfortunately, running
> > a command once can give misleading timings: the process may create a
> > cache on its first execution, running faster subsequently; other
> > processes may cause the command to be starved of CPU or IO time;
> > etc. It is common to see people run time several times and take
> > whichever values they feel most comfortable with. Inevitably, this
> > causes problems.
> >
> > multitime is, in essence, a simple extension to time which runs a
> > command multiple times and prints the timing means, standard
> > deviations, mins, medians, and maxes having done so. This can give a
> > much better understanding of the command's performance.
signature.asc
Description: PGP signature
Bug#854422: ITP: multitime -- an to time which runs a command multiple times and gives detailed stats
Package: wnpp
Severity: wishlist
Owner: Iustin Pop <ius...@debian.org>
* Package name: multitime
Version : 1.3
Upstream Author : Laurence Tratt <lau...@tratt.net>
* URL : http://tratt.net/laurie/src/multitime/
* License : BSD
Programming Lang: C
Description : a time-like tool which does multiple runs
Unix's time utility is a simple and often effective way of measuring
how long a command takes to run ("wall time"). Unfortunately, running
a command once can give misleading timings: the process may create a
cache on its first execution, running faster subsequently; other
processes may cause the command to be starved of CPU or IO time;
etc. It is common to see people run time several times and take
whichever values they feel most comfortable with. Inevitably, this
causes problems.
multitime is, in essence, a simple extension to time which runs a
command multiple times and prints the timing means, standard
deviations, mins, medians, and maxes having done so. This can give a
much better understanding of the command's performance.
Bug#849383: Postgres connections plugin broken with Postgres 9.6
Package: munin-plugins-core Version: 2.0.28-1 Severity: normal Tags: upstream Hello, It seems that the munin Postgres plugin is broken with Postgres 9.6; this has already been reported upstream (https://github.com/munin-monitoring/munin/issues/746) and has already been fixed (https://github.com/munin-monitoring/munin/commit/458883de0a0b420f1f3aa804c8ecfddd22ad03ca), although I don't know if the patch has made it into a stable release (it's quite new, from November 15). Could you please cherry-pick this patch onto the current version? Stretch does have PG 9.6, so it'd be good to have it fixed. thanks! iustin -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.35-teal0 (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 Init: systemd (via /run/systemd/system) Versions of packages munin-plugins-core depends on: ii munin-common 2.0.28-1 ii perl 5.24.1~rc4-1 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: ii conntrack 1:1.4.4+snapshot20161117-4 ii libcache-cache-perl 1.08-2 pn libdbd-mysql-perl ii libnet-dns-perl 1.06-1 ii libnet-netmask-perl 1.9022-1 ii libnet-telnet-perl 3.04-1 ii libxml-parser-perl 2.44-2+b1 ii python 2.7.11-2 ii ruby1:2.3.3 ii ruby2.2 [ruby-interpreter] 2.2.4-1 -- no debconf information signature.asc Description: PGP signature
Bug#831726: Opinion on bug 831726 Very confusing prompt regarding administrative database passwords
On 2016-08-15 21:37:31, Justin B Rye wrote: > Paul Gevers wrote: > > Thanks, looks good to me. > > > > But how about: > > By default, these passwords are not stored, so you will be prompted for > > them each time. > > ^ > > Good idea, I think we can afford the extra 11 bytes. :) Thanks all for the fast response on this, much appreciated. iustin
Bug#831726: Very confusing prompt regarding administrative database passwords
Source: dbconfig-common Severity: normal Hi, I'm installing db-common for the first time, so I'm not familiar with its configuration or even what is its purpose (installing as a dependency). During installation, I'm presented with a debconf prompt, which says: "By default […] These passwords will be stored in debconf's configuration database only for as long as they are needed. This behavior can be disabled, in which case the passwords will remain in the debconf database […] though this is less secure and thus not the default setting.". Then the prompt follows: "Keep "administrative" database passwords? Yes/No". This is very confusing. The prompt talks about default setting vs. non-default, but then follows with a 'yes/no'. Is yes the default? or No? The prompt is also confusing as it asks about "keeping" the passwords, but the initial explanation says that both options keep the password, just for different amounts of time. I would suggest asking "keep passwords in debconf (unsecure) yes/no" or something similar. regards, iustin -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.15-ruru0 (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 Init: systemd (via /run/systemd/system)
Bug#825394: systemd kill background processes after user logs out
On 2016-05-30 22:19:48, John Paul Adrian Glaubitz wrote: > Hi! > > > don't think the right response should be to just fix it one way > > for everyone, especially not since those people in charge of hundreds > > of systems have exactly one vote, similar to those who just develop > > for their own home workstation. > > I'm sorry, but this is a very bad argument. People who are in charge > of hundreds of systems almost never use the default settings but use > something like FAI, Puppet or ansible to configure their systems > exactly the way they need them. No one is installing hundreds of > computers manually with the d-i images like you would do on a single > machine, that would just be nuts. And in these scenarios, changing > the default settings of configuration files in packages is a daily > routine and nothing special. So, this change has *zero* negative > impact for these users. As long as they know about it. In an ideal world, yes, every such admin would read in detail all release notes. In the real world, you've just added more trouble for the (usually overworked) admins. > As for the usefulness of this change: I used to work at the IT departmant > of a large university in the past and I have some experience in this regard. > In fact, this particular change in systemd solves a *very* common problem in > these setups which are leftover processes on the computers in the student > computer > pools as around at least a dozen different users are logging in and out again > on these machines per day with many different processes still staying around, > and, > no, this is not particularly a GNOME problem - it's a general problem which > is usually solved with a cron job which kills leftover processes regularly. It's true that for shared machines this makes sense. But not for individual workstations, e.g. in a company which deploys Linux as the default OS for engineers. > Some people here suggested that, instead of adding such a functionality to > the session manager, affected projects should just fix their software which > effectively translates to "People should write bug-free software" which > is, of course, an unrealistic goal and therefore not really adding to > the discussion in any fruitful manner. Sure, but nobody in this bug proposed that. > Thus, the systemd approach is actually sane and exactly what most admins of > larger setups with many users want. And it's not that the systemd developers > did not provide an opt-out solution. As it was clearly documented in the > release notes, users are free to disable this feature or use systemd-run > to explicitly prevent a process from being killed upon logout which is > *exactly* what every admin wants: Processes should be killed upon logout > by default and anything that should remain running should request an > explicit permission from the session management. There is really no other > good way to tackle this problem. Admins will neither be able to prevent > buggy software (since users could just write and run their own buggy > software) nor is it practical to keep a long black list with runaway > processes which are being killed upon logout. Again, you're looking at it from the point of view of shard machines. In the case however where we're talking about individual machines, this becomes a counter-argument. Similarly here in this bug people proposed whitelists of processes which should not be killed, a similarly bad measure. > It's honestly very frustrating to read bug reports like these as they > are usually written by people who lack the necessary background or refuse > to accept that their particular use case is not the common use case. This can be argued from the other side as well. Exactly the same argument. What makes _your_ argument the right one? They are two sides of the same problem. > And I > have more the impression that these bug reports are merely written to > stir up emotions because, again, the systemd developers dared to touch > something in the Linux software stack which has not been touch for years > while solving yet another long-existing problem. A reasonable person wouldn't > even mind about such changes. They would either just disable the feature > completely or use the provided mechanisms to white-list individual processes > which takes less time than writing up such a bug report and stirring up > emotions. No, that's not the case. The problem is that, unilaterally, systemd authors/systemd packaging team decided to change the default. IMHO, a reasonable and less conflictual path forward would have been to advertise this feature, allow the needed software changes to propagate to the most common programs affected (screen, tmux, etc.) and only later make the switch to it. The other issue is that, and here maybe it's only my experience, unintended leftover processes usually only consume resources, but unintentionally killed processes can result in data loss. Thus, this setting is on the more dangerous default. I'm
Bug#824712: RFH: smokeping
On 2016-05-21 23:29:20, Iustin Pop wrote: > On 2016-05-18 18:22:55, Antoine Beaupré wrote: > > I need help maintaining the smokeping package. I do not really use it > > anymore and i'd be happy to help people to sponsor it. There's a bunch > > of obscure bugs all over the place, and while I think the package > > mostly works, it's just a wild guess since well, I'm not using it > > right now. > > Hi Antoine, > > How would you prefer to get help? I'll try to do a bit of BTS cleanup, > but for code changes, is it fine to do direct VCS commits, or would you > prefer git pull requests? > > I do use smokeping, so I'm happy to help as time allows. Sorry, I didn't see the other comments in the bug. I've yesterday a round of BTS cleanups. iustin signature.asc Description: PGP signature
Bug#760945: postinst overwrites permissions set by admin, destroys configuration for slaves
On 2014-09-09 13:29:28, Sven Hartge wrote:
> Package: smokeping
> Version: 2.6.9-1
> Severity: normal
>
> Hi!
>
> In the postinst the following commands are executed:
>
> ,
> | chown smokeping:smokeping /var/lib/smokeping
> | chown smokeping:smokeping /etc/smokeping/smokeping_secrets
> | chmod 640 /etc/smokeping/smokeping_secrets
> `
>
> This unconditionally destroys any custom permissions the admin may have
> set. Overwriting the permissions for /etc/smokeping/smokeping_secrets is
> especially desastrous because this file needs to be read by the www-data
> user (or group) to allow slaves to connect correctly.
>
> Right now the only option is to use POSIX-ACLs to allow www-data to read
> that file because if you just use "chgrp www-data" this change will get
> overwritten the next time the package is updated.
Since there's no mechanism (AFAIK) for automatically handling custom
permissions for conffiles, and both the admin and the package fight over
this, the first solution that comes to mind is to add debconf questions
for owner and mode, and always use debconf/the package to manage the
permissions. This would solve both problems (conflicts and custom
permissions).
A simpler alternative but not that flexible would be to add only one
question ("support slaves"), which would different, but still hard-coded
permissions.
Thoughts?
iustin
signature.asc
Description: PGP signature
Bug#788003: smokeping package fails to run with fping
On 2015-06-07 18:22:29, Bernd Naumann wrote: > Package: smokeping > Version: 2.6.8-2 > > When I install `smokeping` via `apt-get` the daemon fails to start, > cause of > """ > Starting latency logger daemon: smokepingERROR: > /etc/smokeping/config.d/Probes, line 5: ERROR: FPing 'binary' does not > point to an executable > """ > > This is quiet a minor bug: > > $ grep fping /etc/smokeping/config.d/Probes > binary = /usr/bin/fping > $ which fping > /usr/local/sbin/fping > > This should be fixed easily. This sounds wrong. `/usr/local/sbin/fping' tells me that you have fping installed locally from sources, not from a debian package (which would install it in /usr/bin). Are you sure you installed smokeping and its recommends? regards, iustin signature.asc Description: PGP signature
Bug#824712: RFH: smokeping
On 2016-05-18 18:22:55, Antoine Beaupré wrote: > I need help maintaining the smokeping package. I do not really use it > anymore and i'd be happy to help people to sponsor it. There's a bunch > of obscure bugs all over the place, and while I think the package > mostly works, it's just a wild guess since well, I'm not using it > right now. Hi Antoine, How would you prefer to get help? I'll try to do a bit of BTS cleanup, but for code changes, is it fine to do direct VCS commits, or would you prefer git pull requests? I do use smokeping, so I'm happy to help as time allows. regards, iustin signature.asc Description: PGP signature
Bug#824219: Missing dependency on libcgi-pm-perl
Package: dhelp Version: 0.6.21+nmu6 Severity: normal My autopkg tests which use dhelp are failing, and I can confirm this is a fresh chroot install: $ apt-get install dhelp (installs recommends as well) $ dhelp foobar Can't locate CGI.pm in @INC (you may need to install the CGI module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.2 /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/lib/cgi-bin/dsearch line 27. BEGIN failed--compilation aborted at /usr/lib/cgi-bin/dsearch line 27. Indeed, dquery imports CGI, but there's no dependency declared on it. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.21-ruru0 (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 Init: systemd (via /run/systemd/system) Versions of packages dhelp depends on: ii doc-base 0.10.7 ii libdata-page-perl 2.02-1 ii libhtml-parser-perl 3.72-1 ii liblocale-gettext-perl1.07-1+b1 ii libtemplate-perl 2.24-1.2+b2 ii liburi-perl 1.71-1 ii perl-modules-5.22 [perl-modules] 5.22.2-1 ii poppler-utils 0.38.0-3 ii pstotext 1.9-6+b1 ii ruby 1:2.3.0+4 ii ruby-bdb 0.6.6-2+b3 ii ruby-debian 0.3.9+b6 ii ruby-gettext 3.1.7-1 ii ruby2.1 [ruby-interpreter]2.1.5-4 ii ruby2.2 [ruby-interpreter]2.2.4-1 ii ruby2.3 [ruby-interpreter]2.3.1-1 ii swish++ 6.1.5-3 ii ucf 3.0036 Versions of packages dhelp recommends: ii chromium [www-browser] 50.0.2661.94-1 ii firefox-esr [www-browser] 45.1.1esr-1 ii html2text 1.3.2a-18+b1 ii lynx [www-browser] 2.8.9dev9-1 ii w3m [www-browser] 0.5.3-27 Versions of packages dhelp suggests: pn catdvi pn httpd-cgi pn info2www pn man2html -- no debconf information
Bug#811650: FTBFS with GCC 6: multiple errors
On 2016-01-19 16:38:00, Martin Michlmayr wrote: > Package: protobuf > Version: 2.6.1-1.3 > Severity: important > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-6 gcc-6-cannot-convert > > This package fails to build with GCC 6. GCC 6 has not been released > yet, but it's expected that GCC 6 will become the default compiler for > stretch. > > Note that only the first error is reported; there might be more. You > can find a snapshot of GCC 6 in experimental. To build with GCC 6, > you can set CC=gcc-6 CXX=g++-6 explicitly. Thanks for the bug report. Given the kind of failures I see in the log, it's unlikely that this will get fixed unless we move to a newer upstream (3.x) since the needed changes seem a bit invasive. Hopefully new upstream works better with gcc-6, but we haven't finished packaging that yet. regards, iustin signature.asc Description: PGP signature
Bug#805072: protobuf: FTBFS on sparc64 - apparently tries to build x86 code
On 2015-11-24 11:39:08, Robert Edmonds wrote: > David Matthew Mattli wrote: > > So now it checks for either SOLARIS_64BIT_ENABLED or __LP64__ to > > determine whether the sparc platform is 64bit. With this change the package > > builds on my sparc64 system and it shouldn't affect any other archs. > > > > I've attached a patch to implement this change. > > Hi, David: > > Thank you for this patch, but it looks like a very similar patch was > applied upstream against protobuf 3: > > https://github.com/google/protobuf/pull/780 > > (Upstream is no longer developing the 2.x branch.) > > I'm not sure when protobuf 3 is going to hit unstable, but if this bug > is critical for the sparc64 efforts I think we might be able to make I'll include this patch in the upcoming 2.6.1-2 upload. Upstream has rejected that pull request, as they had a different (better?) change to support sparc64. Given that I don't know all the implications of that patch (https://github.com/google/protobuf/commit/97fa4ca1565d216d102af9510b17966c28c7a52a), I'll just apply this patch until we package 3.x (that commit is included after 3.0.0 beta 1). thanks! iustin signature.asc Description: PGP signature
Bug#775013: mt-st: Pass command-line options to the modprobe call
On 2015-01-10 01:39:52, Artur Rona wrote: > Package: mt-st > Version: 1.1-6 > Tags: patch > Usertags: origin-ubuntu ubuntu-patch vivid > > In Ubuntu, we've applied the attached patch to achieve the following: > >* debian/mt-st.modprobe: > - Pass command-line options to the modprobe call. > > We thought you might be interested in doing the same. Thanks. The patch makes a lot of sense, however I'm going to close it in the next upload by removing entirely the modprobe.conf file; as such, mt-st won't interfere anymore at all with modprobe. regards, iustin signature.asc Description: PGP signature
Bug#823278: RM: ratproxy -- ROM; Unmaintained, low popcon count
Package: ftp.debian.org Severity: normal Hi, Please remove ratproxy from the archive. Last upstream release was in 2009, and the upstream has not migrated the project from code.google.com after that site has been shut down, so I consider this a dead project. Popcon count is 26, which is very very low. thanks, iustin signature.asc Description: PGP signature
Bug#809750: Please package newer ckermit
Package: ckermit Version: 302-5 Severity: wishlist Hi, I looks like ckermit 304 was released about two years ago. Could you please update it? And if possible, also bump dependency on libssl1.0.0 to libssl1.0.2, that would make my day (debsecan flags libssl1.0.0 as still having unresolved security issues). thanks, iustin -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.15-teal0 (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 Init: systemd (via /run/systemd/system) Versions of packages ckermit depends on: ii debconf [debconf-2.0] 1.5.58 ii libc6 2.21-6 ii libcomerr2 1.42.13-1 ii libgssapi-krb5-2 1.13.2+dfsg-4 ii libk5crypto3 1.13.2+dfsg-4 ii libkrb5-3 1.13.2+dfsg-4 ii libncurses56.0+20151024-2 ii libpam0g 1.1.8-3.1 ii libssl1.0.01.0.2d-1 ii libtinfo5 6.0+20151024-2 Versions of packages ckermit recommends: ii openbsd-inetd [inet-superserver] 0.20140418-2 ii openssh-client [ssh-client] 1:7.1p1-5 ckermit suggests no packages. -- debconf information excluded signature.asc Description: PGP signature
Bug#798258: http_loadtime plugin mis-detects presence of time binary
Package: munin-plugins-core Version: 2.0.25-1 Severity: normal The jessie version of munin-node/http_loadtime plugin contains the following code: #!/bin/bash … time_bin=`which time` if [ "$1" = "autoconf" ]; then result="yes" command -v $time_bin 2>&1 >/dev/null || result=1 … etc. This contains a bug: if the time binary is not installed, $time_bin will be empty, but "command -v" doesn't fail. Hence the plugin mistakenly believes that the time binary is installed, leading to failures later when it tries to pass the "--quiet" option to the time builtin command. The bug is present in sid as well. Beside fixing the issue here, it would be good if the package suggests the time command. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.6-ruru0 (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 Init: systemd (via /run/systemd/system) Versions of packages munin-node depends on: ii gawk 1:4.1.1+dfsg-1 ii init-system-helpers 1.23 ii libnet-server-perl 2.008-2 ii lsb-base 4.1+Debian14 ii munin-common 2.0.25-2 ii munin-plugins-core 2.0.25-2 ii perl 5.20.2-6 ii procps 2:3.3.10-4 Versions of packages munin-node recommends: ii libnet-snmp-perl 6.0.1-2 ii munin-plugins-extra 2.0.25-2 Versions of packages munin-node suggests: ii acpi 1.7-1 ii ethtool 1:3.16-1 ii hdparm9.43-2 ii libcrypt-ssleay-perl 0.58-1+b2 ii libdbd-pg-perl3.5.1-1 pn liblwp-useragent-determined-perl ii libnet-irc-perl 0.79-1 ii libtext-csv-xs-perl 1.19-1 ii libwww-perl 6.13-1 ii libxml-simple-perl2.20-1 ii lm-sensors1:3.4.0-1 ii logtail 1.3.17 ii munin 2.0.25-2 pn munin-plugins-java pn mysql-client ii net-tools 1.60-26+b1 ii python2.7.9-1 ii ruby 1:2.1.5.1 ii smartmontools 6.3+svn4002-2+b3 -- Configuration Files: /etc/munin/munin-node.conf changed [not included] /etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: u'/etc/munin/plugin-conf.d/munin-node' -- no debconf information signature.asc Description: Digital signature
Bug#798177: "Use default paths for lease files" breaks dhcpd
Package: isc-dhcp-server Version: 4.3.3-2 Severity: important Hi, The changelog for "isc-dhcp (4.3.3-2) unstable" says: "* Use default paths for lease files." I don't know what the actual change was here, but the result is that dhcpd expects the lease file to live in /var/db/dhcpd.leases, which is not where the lease file was before and is not policy compliant. Policy aside, it breaks the startup, since the init script still touches /var/lib/dhcp/dhcpd.leases. Note: # grep leases /etc/init.d/isc-dhcp-server touch /var/lib/dhcp/dhcpd.leases # strings $(which dhcpd)|grep -F .leases /var/db/dhcpd6.leases /var/db/dhcpd.leases The change in git simply removes the configure options for --with-srv and --with-cli lease, noting that it fixes bug 758882. I don't see how that will fix r/w files in /var, since the default lease files are still in /var. Please investigate and update the change. The server lease file was in the right place, the client one might need to be put somewhere else, but right now the fix breaks more than it solves. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.6-ruru0 (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 Init: systemd (via /run/systemd/system) Versions of packages isc-dhcp-server depends on: ii debconf [debconf-2.0] 1.5.57 ii debianutils4.5.1 ii libc6 2.19-19 ii libdns-export100 1:9.9.5.dfsg-12 ii libisc-export951:9.9.5.dfsg-12 ii lsb-base 4.1+Debian14 ii policycoreutils2.3-1 Versions of packages isc-dhcp-server recommends: ii isc-dhcp-common 4.3.3-2 Versions of packages isc-dhcp-server suggests: pn isc-dhcp-server-ldap -- Configuration Files: /etc/dhcp/dhcpd.conf changed [not included] /etc/logcheck/ignore.d.server/isc-dhcp-server [Errno 13] Permission denied: u'/etc/logcheck/ignore.d.server/isc-dhcp-server' -- debconf information: * isc-dhcp-server/interfaces: isc-dhcp-server/config_warn: signature.asc Description: Digital signature
Bug#797244: A display manager should not kill user processes on logout!
Source: lxdm
Version: 0.5.1-1
Severity: important
So I wanted to try alternative display managers, and I gave LXDM a
try. To my surprise, it does this in /etc/lxdm/PostLogout:
# Kills all your processes when you log out.
ps --user $USER | awk 'NR 1 {print $1}' | xargs -t kill
This is… wrong. It kills my running fetchmail process, kills all
processes I launched in a screen session exactly in order to survive
logout, etc.
Why does LXDM by default do this? It should be at least a)
configurable, and b) not the default.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.6-ruru0 (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
Init: systemd (via /run/systemd/system)
Bug#792528: dict-foldoc: please make the build reproducible
On 2015-07-15 20:26:43, Reiner Herrmann wrote: Source: dict-foldoc Version: 20150318-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: locale X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! We noticed another variation in dict-foldoc. A different date is embedded depending on the language/locale. The attached patch fixes this by using the C locale. Ah, interesting! Thanks for the patch. Will apply, but not right away - the build for this package quite heavy so I'll batch it with some other work. thanks! iustin signature.asc Description: Digital signature
Bug#787184: ITP: haskell-js-jquery -- bundles the minified jQuery code into a Haskell package
Package: wnpp Severity: wishlist Owner: Iustin Pop ius...@debian.org * Package name: haskell-js-jquery Version : 1.11.3-1 Upstream Author : Neil Mitchell ndmitch...@gmail.com * URL : https://github.com/ndmitchell/js-jquery * License : BSD Programming Lang: Haskell Description : bundles the minified jQuery code into a Haskell package This package bundles the minified jQuery code into a Haskell package, so it can be depended upon by Cabal packages. The first three components of the version number match the upstream jQuery version. The haskell library is designed to meet the redistribution requirements of downstream users, and to reduce duplication of bundled code in Debian. Will be maintained as part of debian-haskell team. signature.asc Description: Digital signature
Bug#787185: ITP: haskell-js-flot -- bundles the minified Flot code into a Haskell package
Package: wnpp Severity: wishlist Owner: Iustin Pop ius...@debian.org * Package name: haskell-js-flot Version : 0.8.3 Upstream Author : Neil Mitchell ndmitch...@gmail.com * URL : https://github.com/ndmitchell/js-flot * License : BSD Programming Lang: Haskell Description : bundles the minified Flot code into a Haskell package This package bundles the minified Flot code (a jQuery plotting library) into a Haskell package, so it can be depended upon by Cabal packages. The first three components of the version number match the upstream Flot version. The package is designed to meet the redistribution requirements of downstream users, and to reduce the number of duplicate copies of embedded code. Will be maintained as part of debian-haskell team. signature.asc Description: Digital signature
Bug#776397: dict-foldoc: please make the build reproducible
On 2015-01-27 17:08:28, Chris Lamb wrote: Source: dict-foldoc Version: 20140720-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi, While working on the reproducible builds effort [1], we have noticed that dict-foldoc could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, dict-foldoc can be built reproducibly in our current experimental framework. Thanks, applied, will be in the next upload. iustin signature.asc Description: Digital signature
Bug#464631: [ietf-act...@ietf.org: [www.ietf.org/rt #46275] Broken contents in text format of rfc2616, but not int the pdf format]
It seems that (ages ago) I forgot to forward the reply from IETF on this issue: - Forwarded message via RT ietf-act...@ietf.org - Date: Tue, 20 Mar 2012 11:30:28 -0700 From: xxx via RT ietf-act...@ietf.org To: ius...@debian.org Subject: [www.ietf.org/rt #46275] Broken contents in text format of rfc2616, but not int the pdf format Reply-To: ietf-act...@ietf.org RT-Ticket: www.ietf.org/rt #46275 Managed-by: RT 3.6.5 (http://www.bestpractical.com/rt/) RT-Originator: ste...@amsl.com Hi Iustin, I reported this to the RFC Editor, and they said: Unfortunately, we can't update the document, as published RFCs don't change. This was already reported and verified as an error (http://www.rfc-editor.org/errata_search.php?rfc=2616eid=652). If you have any further questions on this please contact rfc-edi...@rfc-editor.org. End forward As discussed in 2012, I'll apply a local patch. iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783722: jessie-pu: package ganeti/2.12.3-0+deb8u1
On 2015-04-29 18:45:56, Apollon Oikonomopoulos wrote: Hi, On 16:37 Wed 29 Apr , Adam D. Barratt wrote: Unstable and stable currently have the same version of ganeti; as a rule of thumb, unless there's a really good reason then we always want fixes to have been proven in unstable before being backported to stable - that applies for small fixes, but certainly for a change of the size proposed. What's the plan for getting unstable updated? I originally intended to upload 2.12.3 to unstable today and then prepare 2.12.3-1~deb8u1, precisely to get more testing. Unfortunately, unstable moved on to GHC 7.8 right after the freeze ended, which introduced some backwards-incompatible changes causing ganeti 2.12 to FTBFS on sid. I know upstream is working on GHC 7.8 support, but it is not yet clear how long it will take and whether the fix will target 2.12 or a later stable release. Not the best possible situation I have to admit. FYI, upstream seems to have fixed this on the 2.15 branch, and manually applying some of the changed done by Niklas (search on git.ganeti.org for 7.8, see especially commits b78a2c3013c16395c48e055de82c4f93d9b41c38, 083776b9dbd7e704357841e6a8a4fce6802199fc and 1ad14f38083d7d7702154f791070a92e241320e0) gets the build progressing quite far, until the lens 4.4 changes which removed defaultRules (see https://code.google.com/p/ganeti/issues/detail?id=981). Applying on top commits cfd9c8a82550df4e29ebeee2158f1d7fb864d531 and 14a85a6fa426e3088423923094cd6d574fe91d3f results in the build failing only due to -Werror, which can be patched out (and there are fixes for that as well in git). So the upstream git tree contains all changes needed, but spread around different branches. It should be easy for upstream to make a new 2.12 release, but it's even more simple for Debian to patch 2.12 in-place by cherry-picking these patches, they are rather trivial. I make my tests based on 2.12.0 source as retrieved by apt-get source. Not sure if 2.12.3 contains further fixes or changes that would make this more difficult. Just FYI :) regards, iustin signature.asc Description: Digital signature
Bug#670129: Late update on dhelp…
Looking at what dhelp does, it seems that this is actually a pstotext issue: pstotext -output /tmp/1277.txt rfc1277.ps pstotext: internal error 202 The -debug output doesn't seem to shed any light on the issue, so I considered just reassigning (at least for further triage). But investigating further, this is a very peculiar PostScript file - produced by dvips very old version, and incompatible with modern softare: 'gv' seems to view the postscript file - at least partially, navigation seems broken and you can cycle through the document endlessly, evince only sees one page. As such, I'll patch the build process to rewrite the file in-place (using ps2ps2). thanks, iustin signature.asc Description: Digital signature
Bug#776176: doc-rfc is outdated
On Sun, Jan 25, 2015 at 05:14:09AM +0300, Evgeny Kapun wrote: Package: doc-rfc Severity: wishlist The latest version of doc-rfc package is dated February 2012. It's almost three years since then, and more than 900 more RFCs has been published during this period. I think that this package needs an update, and that it should be updated at least every few months. Thanks for the report. Yes, I should update this package more often (I was planning to before the freeze, but unfortunately didn't get to it). This kind of package presents the difficulty that, as there are no clear upstream releases, it's always out of date. Probably once per quarter is a good release schedule, I'll try make a system to do that. iustin signature.asc Description: Digital signature
Bug#774315: RFP: haskell-disk-free-space -- Retrieve information about disk space usage.
On Wed, Dec 31, 2014 at 12:32:00PM -0400, Joey Hess wrote: Package: wnpp Severity: wishlist * Package name: haskell-disk-free-space * URL : http://hackage.haskell.org/package/disk-free-space * License : BSD3 git-annex currently contains its own implementation of a portable disk free space and size checking library. In a future version, I'd like to drop this code, and instead use the new disk-free-space from hackage. It will work on at least Linux, OSX, and Windows. Probably on the BSDs, but I have not checked. So, it would be nice to get this into Debian before-hand. There's another package (statvfs) on hackage that does something similar, although it's not portable. To my surprise, both of these import statvfs as unsafe, which (for a C function that results in a syscall is surprising), so I filled https://github.com/redneb/disk-free-space/issues/1. Curious: if your code is already portable, why not split that out if it already works in the real world? thanks! iustin signature.asc Description: Digital signature
Bug#758870: nfs-common: nfs v4: uid/gid lookup fails for some of the users
On Fri, Sep 05, 2014 at 11:19:35AM +0200, Piet Plomp wrote: Hi Iustin, On 2014-09-04 19:11, Iustin Pop wrote: [...] Just another datapoint: this is different from my case. No new users created, randomly new files get -1 for a while, after which the correct UID is listed. No, this is not different: all new users get new files, which have never been served by the nfs server before. With me, a while might last forever for some identities. I still don't understand what new users mean - as I said, I don't have new users. When I create files or dirs, they may be owned by the infamous -2 (4294967294), regardless _where_ I created them (i.e. through nfs or locally on the filesystem. Exactly. You report that after a while the currect uid and gid are listed. Same for me, but sadly not always, some identities get stuck on 4294967294 forever. I'm curious if we have any differences in our setups: - Do you also have a mixture of wheezy and jessie systems? Is your nfs server also on a wheezy system? Are your clients both jessie and wheezy systems? Only sid (unstable) clients. Server and some clients run custom (upstream) kernels, some clients run sid kernel. - Did you see any changes in the behaviour of the wheezy clients after the jessie clients mounted? I don't have wheezy clients, so N/A. - Do you have inet6 entries in /etc/netconfig enabled on the jessie clients (which is the default)? Yes. - Did you change /etc/idmapd.conf? Yes. I tried to add static mappings for some users, but it didn't have any positive effect. - Did you change or add any files in /etc/request-key.d/ ? (small test: rename the id_resolver file, and suddenly _all_ identities are 4294967294) No. - Is the serving filesystem XFS formatted? Interestingly, yes. Only XFS. - Is NIS involved? Or LDAP? (A small test by copying the passwd, shadow and group entries to the client system: everything is ok). No. Only 'compat' nssswitch entries. - Do you use nsswitch to resolve identities (uid/gid)? I don't understand - nsswitch is always used. Did you mean what nsswitch configuration do I have? If so, it's just 'compat'. - Does your client run a name service caching daemon (nscd or unscd)? No. - Did you see nobody/nogroup (65534/65534) identities too? Yes. Just to make sure: this is nfs v4 (v4.0) only. Mounting with nfs version 3 over tcp works fine. Not using anything but kerberised nfs v4. regards, iustin signature.asc Description: Digital signature
Bug#758870: nfs-common: nfs v4: uid/gid lookup fails for some of the users
On Thu, Sep 04, 2014 at 12:32:07PM +0200, Piet Plomp wrote: Dear all, This bug might be related to recency. I created accounts for our new students last week. Now, a listing of the home directories on the jessie systems shows about half of the _new_ accounts the identity as the infamous 4294967294. Since the new accounts were created, no reboots were done and no relevant services were restarted. The identities of older accounts are now all present. As always, id lists the correct identities in all cases. On the wheezy systems, all identities are shown correctly. Hope this helps in some way. Just another datapoint: this is different from my case. No new users created, randomly new files get -1 for a while, after which the correct UID is listed. regards, iustin signature.asc Description: Digital signature
Bug#758870: nfs-common: nfs v4: uid/gid lookup fails for some of the users
On Mon, Aug 25, 2014 at 11:47:46AM -0700, Ben Hutchings wrote: On Mon, 2014-08-25 at 14:43 +0200, Piet Plomp wrote: Hi Ben, Here are some tests: A wheezy system: For a new test I took a standard _wheezy_ system without systemd, 3.2.0-4 kernel (Debian 3.2.60-1+deb7u3). No nfs problem. I upgraded libc6 to jessie's 2.19.9: no nfs problem. Then I installed the linux-image-3.14.2-amd64 (3.14.15-2) kernel (which pulled in initramfs-tools) and rebooted: : YES there is the nfs problem! A jessie system: Another system, one of the jessie systems with older kernels installed: - kernel 3.13.10 nfs problem YES - kernel 3.14.12 nfs problem YES - kernel 3.14.15 nfs problem YES - kernel 3.2.0-4 (3.2.54 from wheezy) nfs problem NO This system uses systemd. Looks like it's a kernel problem, the problem is not introduced in 3.14.11 or 12, as I thought earlier. [...] Thanks for testing. Can you also test with Linux 3.16, which is packaged in experimental? Just FYI: I have the same problem, but as I use custom kernels built from upstream I didn't report it yet (I thought it's maybe my config or such). But I know that this was not a problem with 3.7; it appeared when I switched from 3.7 to 3.12, so it was introduced sometime between 3.8 and 3.12. regards, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756334: [Pkg-haskell-maintainers] Bug#756334: Configure script downloads files from the Internet
On Mon, Jul 28, 2014 at 11:02:53PM +0200, Evgeny Kapun wrote: My suggestion is that downloading files in a secure manner is hard, and maintainer scripts probably shouldn't be doing it. On Tue, Jul 29, 2014 at 09:27:34AM +0300, Henri Salo wrote: Do you have an alternative solution? Maybe this could be extracted directly to source package and updated with an script? Just to clarify both points above, if it's not clear from the discussion on the upstream bug: the current situation is not intended, it's just an accident resulting from the fact that upstream doesn't (yet) support an offline mode, and changes in the upstream behaviour resulted in our pre-unpacked files being ignored. Rest assured, this will get fixed, one way (better upstream support) or another (us patching upstream code so that it never downloads + pre-shipping). regards, iustin signature.asc Description: Digital signature
Bug#736594: Still missing…
Just FYI: this bug is marked as upstream fixed, but I checked and while the non-minified source code is in the git tree, it's not distributed in the upstream archive. I've sent a trivial pull request so hopefully the next upstream release will allows us to fix this bug. signature.asc Description: Digital signature
Bug#739694: Invalid file ref in documentation (man page)
severity 739694 minor thanks On Fri, Feb 21, 2014 at 01:27:56PM +0100, Mathieu Malaterre wrote: Package: mt-st man page refers to: [...] Otherwise, a default device defined in the file /usr/include/sys/mtio.h is used. [...] I believe this is inacurate as it does not exists at least on my system. Maybe instead: /usr/include/linux/mtio.h or /usr/include/x86_64-linux-gnu/sys/mtio.h The path quoted in the man page exist on my system, and is provided by libc6-dev-i386 (of all things…). It seems the actual path can be system-dependent (/usr/include/sys on x86, /usr/include/x86_64-linux-gnu on i386; the linux/mtio.h file is different, as that's a kernel header). I'll patch the man page to note that this path can vary by system. regards, iustin signature.asc Description: Digital signature
Bug#739695: Convenient copy of mtio.h in source
On Fri, Feb 21, 2014 at 01:30:23PM +0100, Mathieu Malaterre wrote: Package: mt-st It is not clear what the impact would be, but I think it would be easier to maintain this package if the mtio.h copy would not be used and instead the system installed one would be used instead. Thanks for the report. Here are the diff (as of today on wheezy): $ diff -u mtio.h /usr/include/linux/mtio.h --- mtio.h 2008-02-20 20:31:49.0 +0100 +++ /usr/include/linux/mtio.h 2014-01-11 01:15:51.0 +0100 @@ -1,9 +1,8 @@ /* * linux/mtio.h header file for Linux. Written by H. Bergman * - * Sanitized version for mt/stinit (definitions not used by these - * programs have been removed) 7 Oct 2007/Kai Mäkisara This is the part that makes me a bit suspicious - maybe there was more to using a local file than including directly (unlikely, but…). I'll try to ping the upstream, if he's still active, and get more info. But yes, using the kernel header and build-depending on linux-libc-dev makes sense. thanks, iustin signature.asc Description: Digital signature
Bug#698986: Indent to adopt mt-st
retitle 698986 ITA: mt-st -- Linux SCSI tape driver aware magnetic tape control owner 698986 ! thanks Since I need mt-st for some tasks and the package is orphaned, I'll adopt it and maintain it (at least for a while). signature.asc Description: Digital signature
Bug#739693: Add homepage for mt-st
On Fri, Feb 21, 2014 at 01:25:44PM +0100, Mathieu Malaterre wrote: Package: mt-st It would be nice to have the Homepage set in d/control and/or in the debian/watch file. For example: The watch file already has correct information (see https://qa.debian.org/cgi-bin/watch?pkg=mt-st_1.1-5). I'll add the Homepage field in the next upload. thanks, iustin signature.asc Description: Digital signature
Bug#754593: mt erase is a full (long) erase, document it as such
Package: mt-st Version: 1.1-5 Severity: minor Tags: patch Attached is a patch which improves the man page to say that 'mt erase' is a full erase (not a quick one, erasing just the file/end-of-tape marks). -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.12-ruru0 (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 mt-st depends on: ii libc6 2.18-7 mt-st recommends no packages. mt-st suggests no packages. -- Configuration Files: /etc/stinit.def changed [not included] -- no debconf information Author: Iustin Pop ius...@debian.org Description: Improve manual page for the erase subcommand --- a/mt.1 +++ b/mt.1 @@ -104,7 +104,9 @@ .I count setmarks at current position (only SCSI tape). .IP erase -Erase the tape. +Erase the tape. Note that this is a long erase, which on modern +(high-capacity) tapes can take many hours, and which usually can't be +aborted. .IP status Print status information about the tape unit. (If the density code is no translation in the status output, this does not affect working of the signature.asc Description: Digital signature
Bug#753884: splitindex: wrong summary in man page
Package: texlive-latex-extra Version: 2014.20140626-1 Severity: minor Dear maintainer(s), While searching for something unrelated, I saw this: $ man -k split … splitindex (1) - manual page for splitindex 0.2a … Looking at the man page itself: $ man splitindex … NAME splitindex - manual page for splitindex 0.2a This is not what the summary (if that's the correct term) should describe, but rather the purpose of the program. Probably copying the 2nd line in the description paragraph would be good enough. Thank you, Iustin Pop -- Package-specific info: ## List of ls-R files -rw-r--r-- 1 root root 1531 Jul 5 20:31 /var/lib/texmf/ls-R -rw-rw-r-- 1 root staff 80 Jul 3 2012 /usr/local/share/texmf/ls-R lrwxrwxrwx 1 root root 29 May 30 11:00 /usr/share/texmf/ls-R - /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 May 31 16:45 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 May 31 16:45 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 838 Jun 13 11:47 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 5375 Jul 5 20:31 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 May 31 16:45 /usr/share/texmf/web2c/updmap.cfg - /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3245 Jul 5 20:31 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Apr 13 2009 mktex.cnf -rw-r--r-- 1 root root 838 Jun 13 11:47 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf 1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.4-ruru0 (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 texlive-latex-extra depends on: ii dpkg 1.17.10 ii preview-latex-style11.87-1 ii tex-common 5.02 ii texlive-base 2014.20140528-3 ii texlive-binaries 2014.20140528.34243-2 ii texlive-latex-recommended 2014.20140528-3 ii texlive-pictures 2014.20140528-3 Versions of packages texlive-latex-extra recommends: ii texlive-latex-extra-doc 2014.20140528-2 Versions of packages texlive-latex-extra suggests: ii libfile-which-perl 1.09-1 ii python-pygments 1.6+dfsg-1 Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.53 ii dpkg 1.17.10 ii ucf3.0029 Versions of packages tex-common suggests: ii debhelper 9.20140228 Versions of packages texlive-latex-extra is related to: ii tex-common5.02 ii texlive-binaries 2014.20140528.34243-2 -- debconf information excluded signature.asc Description: Digital signature
Bug#752819: Maintainer patch 40-help seems to add bugs
Package: xtitle Version: 1.0.2-6 Severity: normal Hi, I'm looking at xtitle, and I see some code that doesn't make sense: [ ! $arget ] target=$default (note the mispelling of the $target variable in the condition. And: case $target in *i*|*t*) something=something ;; esac without $something being used later. Basically this code is no-op. Upon further investigation, these are not an upstream problems, but rather were introduced in 40-help.patch, but that patch seems badly named - it seems rather to rewrite half of the script. I just want to flag that that patch probably needs some attention. Whether the patch itself is needed at all, is another discussion… regards, iustin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.4-ruru0 (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 xtitle depends on: ii kterm [x-terminal-emulator] 6.2.0-46.1 ii rxvt-unicode [x-terminal-emulator] 9.20-1 ii xterm [x-terminal-emulator] 304-1 xtitle recommends no packages. xtitle suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#731095: Please consider switching tablesorter to alternate upstream
On Mon, Feb 03, 2014 at 12:37:22PM -0500, Jerome Charaoui wrote: Le 2014-02-02 17:09, Iustin Pop a écrit : On Thu, Jan 30, 2014 at 08:54:17PM -0500, Jerome Charaoui wrote: Several packages in Debian depend on libjs-jquery-tablesorter. Are you confident that switching to a fork wouldn't negatively impact these packages? I'm definitely not confident of this, as I'm not familiar with the javascript packaging/versioning/upgrades policy. Hence why I asked the maintainer to _investigate_ this situation, as they have better knowledge than me on this front, not to simply switch over. I was asking in regards to the tablesorter plugin itself, not Debian policies, in the hope that you may be familiar with the differences between the two. Is the fork a drop-in replacement for the original plugin? Did it introduce incompatible changes, such as removing methods or properties? Etc. Ah, I see. Unfortunately, I'm not that familiar, I just found a bug a in the original upstream, and while searching on the internet I found the alternate upstream which fixed that bug, and that seemed actively maintained. I'll try to investigate the differences, but I'm not very familiar with javascript, so it'll take me a while. thanks, iustin signature.asc Description: Digital signature
Bug#731095: Please consider switching tablesorter to alternate upstream
On Thu, Jan 30, 2014 at 08:54:17PM -0500, Jerome Charaoui wrote: Several packages in Debian depend on libjs-jquery-tablesorter. Are you confident that switching to a fork wouldn't negatively impact these packages? I'm definitely not confident of this, as I'm not familiar with the javascript packaging/versioning/upgrades policy. Hence why I asked the maintainer to _investigate_ this situation, as they have better knowledge than me on this front, not to simply switch over. thanks, iustin signature.asc Description: Digital signature
Bug#731095: Please consider switching tablesorter to alternate upstream
Package: libjs-jquery-tablesorter Version: 8-2 Severity: normal Hi, The current source for the tablesorter plugin seems to be the original one at http://tablesorter.com. However, this version hasn't been updated in more than 5 years, and in the meantime a fork has appeared at https://github.com/Mottie/tablesorter that actually seems alive. Could you please investigate switching over to this one? It seems to fix many bugs and is maintained, so it might make sense to do so. Thanks! iustin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9.6-ruru (SMP w/8 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libjs-jquery-tablesorter depends on: ii libjs-jquery 1.7.2+dfsg-3 ii libjs-jquery-metadata 8-2 Versions of packages libjs-jquery-tablesorter recommends: ii javascript-common 11 libjs-jquery-tablesorter suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#721791: protobuf: please fix static initialization problem with dlopen
On Wed, Sep 04, 2013 at 02:55:07PM +0900, Nobuhiro Iwamatsu wrote: Package: protobuf Version: 2.4.1-3 Severity: important Tags: patch Hi, Version 2.4.1 of protobuf has a problem for static initialization with dlopen. This problem already reported to upstream[0]. The package mozc[1] which I am maintaining has a problem[2] which does not work in part for this problem. I create patch which revise this problem. Could you check and apply this? Hi thanks for the report. Unfortunately I'm a bit behind on the maintenance of protobuf - it should also be updated to 2.5… As I see, upstream has not commented on this, so I suspect new upstream version still has it. I'll see about uploading a fixed version, thanks! iustin signature.asc Description: Digital signature
Bug#721791: protobuf: please fix static initialization problem with dlopen
On Wed, Sep 04, 2013 at 09:14:38PM +0200, Iustin Pop wrote: On Wed, Sep 04, 2013 at 02:55:07PM +0900, Nobuhiro Iwamatsu wrote: Package: protobuf Version: 2.4.1-3 Severity: important Tags: patch Hi, Version 2.4.1 of protobuf has a problem for static initialization with dlopen. This problem already reported to upstream[0]. The package mozc[1] which I am maintaining has a problem[2] which does not work in part for this problem. I create patch which revise this problem. Could you check and apply this? Hi thanks for the report. Unfortunately I'm a bit behind on the maintenance of protobuf - it should also be updated to 2.5… As I see, upstream has not commented on this, so I suspect new upstream version still has it. One more thing: do you have a simple example that can reproduce this? It would be great to add that to the list of simple tests I run before uploading the package… thanks again, iustin signature.asc Description: Digital signature
Bug#713754: [Pkg-ganeti-devel] Bug#713754: Bug#713754: ganeti: FTBFS: htools/Ganeti/HTools/ExtLoader.hs:56:15: Not in scope: `catch'
On Sat, Jun 22, 2013 at 06:52:38PM -0400, Ben Lipton wrote: htools/Ganeti/HTools/ExtLoader.hs:56:15: Not in scope: `catch' make[2]: *** [htools/htools] Error 1 This seems to be a result of the removal of catch from the prelude, which apparently happened in ghc 7.6.1: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html#id9281134 My attempt at patching this is attached. FYI, no need for this. Experimental already has 2.6.2-2 with this fixed, it should only be a matter of migrating 2.6 from experimental to sid. regards, iustin signature.asc Description: Digital signature
Bug#713754: [Pkg-ganeti-devel] Bug#713754: Bug#713754: ganeti: FTBFS: htools/Ganeti/HTools/ExtLoader.hs:56:15: Not in scope: `catch'
On Sun, Jun 23, 2013 at 10:10:30AM -0400, Ben Lipton wrote: On Sun, Jun 23, 2013 at 9:48 AM, Iustin Pop ius...@debian.org wrote: On Sat, Jun 22, 2013 at 06:52:38PM -0400, Ben Lipton wrote: htools/Ganeti/HTools/ExtLoader.hs:56:15: Not in scope: `catch' make[2]: *** [htools/htools] Error 1 This seems to be a result of the removal of catch from the prelude, which apparently happened in ghc 7.6.1: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html#id9281134 My attempt at patching this is attached. FYI, no need for this. Experimental already has 2.6.2-2 with this fixed, it should only be a matter of migrating 2.6 from experimental to sid. regards, iustin Ah, thanks. I thought that might be the case; I mainly worked on this as a learning experience, but then thought I should share in case it would save someone some time. Ack, not a problem. I just sent the email as I see more worthwhile to bump 2.6 from exp to sid, rather than patch 2.5; 2.6 was uploaded to sid just due to wheezy's freeze, which is now over, but I haven't had time (and won't have for another while) to work on packaging, sorry. iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707960: fixed in nfs-utils 1:1.2.8-3
On Sat, Jun 01, 2013 at 01:18:00AM +, Steve Langasek wrote: Source: nfs-utils Source-Version: 1:1.2.8-3 We believe that the bug you reported is fixed in the latest version of nfs-utils, which is due to be installed in the Debian FTP archive. * Build --with-libgssglue, which was the default prior to 1.2.8; this fixes a regression that makes rpc.gssd (and hence, all Kerberos-authenticated mounts) completely useless, because objects are being incorrectly passed between multiple gss implementations (by way of libtirpc). Closes: #707960. FYI, I just tried updating to 1.2.8-3, and still: rpc.gssd[16622]: segfault at 1 ip 7f1525fbce95 sp 7fff9f7b5d10 error 4 in libgssglue.so.1.0.0[7f1525fb9000+9000] rpc.gssd[16793]: segfault at 1 ip 7f805efa2e95 sp 7fff370e4ae0 error 4 in libgssglue.so.1.0.0[7f805ef9f000+9000] # mount /home mount.nfs4: Broken pipe -- regards, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705140: ganeti2: hypervisor conversion
On Wed, Apr 10, 2013 at 03:02:38PM +, Clint Adams wrote:
Package: ganeti2
Version: 2.5.2-1
Severity: wishlist
I'd like to be able to move a bunch of instances from a Xen cluster
to a KVM cluster.
/usr/lib/ganeti/tools/move-instance tells me
OpPrereqError: ('Selected hypervisor (xen-pvm) not enabled in the cluster
(kvm)', 'wrong_state')
It would be nice if it would either do the conversion for me or just
do what it can and then let me tweak the final bits manually.
Hi,
While we don't support this natively, there is a hack/workaround:
- gnt-backup export the instances
- edit the config file and replace the hypervisor entry
- gnt-backup import with the new hypervisor
The reason we don't have this automated right now is that we don't have
a way to map hypervisor parameters from one hypervisor to another…
Thanks for the report, this should/will be forwarded upstream.
iustin
signature.asc
Description: Digital signature
Bug#599445: marked as done (ganeti2: SYNC_SPEED is not configurable)
On Wed, Feb 13, 2013 at 04:33:18PM +, Debian BTS wrote: Your message dated Wed, 13 Feb 2013 16:17:34 + with message-id e1u5f1a-0008ai...@franck.debian.org and subject line Bug#599445: fixed in ganeti 2.6.2-1 has caused the Debian Bug report #599445, regarding ganeti2: SYNC_SPEED is not configurable to be marked as done. Changes: ganeti (2.6.2-1) experimental; urgency=low . * New upstream version (skipped 2.6.0/2.6.1 due to Wheezy freeze) * Uploading to experimental in order to avoid potential problems when updating the Wheezy package (which is 2.5.2-based) * Sync speed is not configurable in 2.6, see the disk parameters documentation (Closes: #599445) Of course this was supposed to be is *now* configurable in 2.6. Sorry for that. iustin signature.asc Description: Digital signature
Bug#693691: gzip: Enable autopkgtest, add simple gzip test
On Mon, Nov 19, 2012 at 10:07:40AM -0700, Bdale Garbee wrote: Daniel Holbach daniel.holb...@ubuntu.com writes: it'd be great to enable autopkgtest tests for gzip as it's an essential part of any system. I took the liberty to write an (admittedly) very simple autopkgtest and add it to the package. Is there some reason you're ignoring the package's existing test suite? While I hadn't been paying attention to it, now that I've read about it I certainly don't object to the concept behind dep8. But it makes no sense at all to start creating separate tests when the upstream package source already includes a credible test suite, as is the case with gzip. The current gzip debian/rules file invokes the test suite using 'make check' and the package build will not complete if any of the tests fail on the as-built executable. So, I'm not interested in merging this patch as-is. If it can be reworked to run the existing test suite on an autopkgtest testbed, then I'd be willing to merge such a patch. If that's not possible, then I suggest the design of autopkgtest be revisited so that we don't need to replicate and/or diverge from upstream test suite creation and management. I'm not aware which patch is under discussion, but note that autopkg tests are orthogonal to build tests. They are designed to test that after a package has been installed, it has been correctly installed, rather than/on top of being correctly built. I don't know if this applies to gzip, but there's is a definite separation between build and install tests at least for other software. regards, iustin signature.asc Description: Digital signature
Bug#673341: Patch for fixing the termios issues
tags 673341 +patch
thanks
I can confirm this bug too. It also breaks the kana input mode :(
Attached is a patch for fixing this, but I don't know if it breaks any
other OSes; I've done it by looking at the delta between 24-7 and 24-8.
The patch restores the following for me on Linux:
- ^D (exit)
- @/# (kana input mode)
- \ (kanji dictionary mode)
thanks,
iustin
--- b/xjdic-24/xjdfrontend.c 2012-09-11 08:35:32.0 +0900
+++ xjdic-24/xjdfrontend.c 2012-09-11 08:43:00.052106564 +0900
@@ -252,11 +252,19 @@
new.sg_flags |= CBREAK; new.sg_flags = ~ECHO;
ioctl(0, TIOCSETP, new);
#else
+#ifdef __GNU__
tcgetattr(0, orig); tcgetattr(0, new);
+#else
+ioctl(0, TCGETA, orig); ioctl(0, TCGETA, new);
+#endif
new.c_lflag = ~ICANON; new.c_lflag = ~ISIG; new.c_lflag = ~ECHO;
new.c_lflag = ~IXON;
new.c_cc[VMIN] = 1; new.c_cc[VTIME] = 0;
+#ifdef __GNU__
tcsetattr(0, TCSANOW, new);
+#else
+ioctl(0, TCSETA, new);
+#endif
#endif
myi_status=IOCTL_RAW;
}
@@ -267,8 +275,10 @@
{
#ifdef __STRICT_BSD__
ioctl(0, TIOCSETP, orig);
-#else
+#elif defined(__GNU__)
tcsetattr(0, TCSANOW, orig);
+#else
+ ioctl(0, TCSETA, orig);
#endif
myi_status = IOCTL_ORIG;
}
signature.asc
Description: Digital signature
Bug#533175: Updates on this?
Erik, are you still working on this? I too would be interested in having Hoogle as a package in Debian. thanks! iustin signature.asc Description: Digital signature
Bug#683200: unblock: ganeti/2.5.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package ganeti Hi release team, I would kindly ask you to unblock the ganeti package. As upstream, we have released version 2.5.2 especially to fix the outstanding issues that ganeti has in testing (and that were fixable without invasive changes). You can see the upstream commits here: http://git.ganeti.org/?p=ganeti.git;a=shortlog;h=refs/tags/v2.5.2;hp=refs/tags/v2.5.1 The debdiff between testing and unstable is a bit more hairy due to the HTML doc being regenerated, so I won't include it; let me know if you want to take a look at it. Beside the upstream changes, on the debian packaging side there are two extra changes: - a patch to fix the -no-kvm parameter (not upstreamed yet) - a fix to dh_installinit invocation (the fix for #677674) Let me know if unblocking is possible or not. Thanks! unblock ganeti/2.5.2-1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.23-ruru1 (SMP w/4 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Bug#599445: [Pkg-ganeti-devel] Bug#599445: ganeti2: SYNC_SPEED is not configurable
On Thu, Oct 07, 2010 at 04:19:48PM +, Clint Adams wrote: Package: ganeti2 Version: 2.1.6-1 Due to what I assume are horrible kernel bugs, letting drbd sync at a fast rate causes the entire machine to go down. It appears that there is no way to override ganeti's syncer rate setting other than to edit /usr/share/pyshared/ganeti/constants.py FYI, this is solved in upstream version 2.6.0, but that will only be uploaded after wheezy (it's a significant new release, and it's not yet ready, just release candidate, on upstream side). So this will probably be solved in a potential 2.6.0-x Debian release. regards, iustin signature.asc Description: Digital signature
Bug#677674: [Pkg-ganeti-devel] Bug#677674: ganeti2: does not install cleanly
found 677674 2.5.0-1 thanks On Sat, Jun 16, 2012 at 11:37:04PM +0200, Toni Mueller wrote: Hi, On Sat, Jun 16, 2012 at 11:21:57PM +0200, Iustin Pop wrote: Yes, but note that the error code is from before the update-rc message. it's probably from postinst. Could you please post the un-abbreviated install log? I'm curious if there are any other errors before dpkg returned an error code. The log is attached below. Please note that there are some control characters left in the log. Sorry for cutting out the important part in the first attempt. I can't really tell. It has been like this for a while, but I have only just gotten around to verify that this problem is likely to be in your package. For a while? I think I first tried to install ganeti2 in March 2011 (2.1.6 back then), then it got de-installed at 2.4.5, and now I can't install it. Finally found the problem. It's a trivial bug, introduced in version 2.5.0-1. I'll see if I can get a freeze exception. Sorry and thanks for the report! iustin signature.asc Description: Digital signature
Bug#682333: KVM failing with : as a disk separator
Package: ganeti Version: 2.5.1-1 Severity: important Tags: upstream This is a Debian bug corresponding to upstream issue 169: kvm can't open disk images with : as a disk separator, which albeit configurable is our default. Fixing this bug via the simple method of changing the disk separator means that running instances (e.g. Xen) will not be possible to live-migrate after upgrading the package until they are restarted. As such, we need to add caution notes/NEWS.Debian to detail this. For more information, see https://code.google.com/p/ganeti/issues/detail?id=169 and https://groups.google.com/forum/?fromgroups#!topic/ganeti/gBGhJFwMHQo. As it is right now, KVM is unusable with Ganeti. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.23-ruru1 (SMP w/4 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Bug#680859: NMUing
On Mon, Jul 16, 2012 at 01:46:43PM -0400, Scott Kitterman wrote: Uploading the attached to delay/2 due to no maintainer response after a week. If you want to fix it differently or have me delay it further, please let me know. Nope, this is the correct fix, I just had not time yet for my Debian activities. thanks, iustin signature.asc Description: Digital signature
Bug#678524: [Pkg-acpi-devel] Bug#678524: acpi-support-base: please drop dependency on consolekit
On Sun, Jun 24, 2012 at 01:41:53PM +0200, Michael Meskes wrote: On Fri, Jun 22, 2012 at 03:09:33PM +0200, Bernhard R. Link wrote: Would you please drop the dependency on consolekit from acpi-support-base? No, there is a reason why this was added. Upstream changed to ck-list-sessions because it seems to be the only tool working with lightdm: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/933626 This however is a bit sad. I don't use lightdm, and many of the systems where I install acpi-support-base are headless (e.g. virtual machines). Reading the upstream bug, it seems that instead of fixing lightdm to properly log to wtmp, they added a much heavier dependency. Now as I understand, this is an upstream decision, but it still (IMHO) sucks. I'll reply on the upstream bug⦠sad, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677674: [Pkg-ganeti-devel] Bug#677674: ganeti2: does not install cleanly
On Sat, Jun 16, 2012 at 01:04:50AM +0200, Toni Mueller wrote: Package: ganeti2 Version: 2.5.1-1 Severity: normal Dear Maintainer, while trying to install ganeti2, I get: # aptitude install ganeti2 ... [master ce2b39c] committing changes in /etc after apt run 5 files changed, 2036 insertions(+) create mode 100644 bash_completion.d/ganeti create mode 100644 cron.d/ganeti create mode 100644 default/ganeti create mode 100755 init.d/ganeti E: Sub-process /usr/bin/dpkg returned an error code (1) Hmm, what is this git output? Could it be that the git hooks failed somehow? A package failed to install. Trying to recover: Setting up ganeti2 (2.5.1-1) ... update-rc.d: error: defaults takes only one or two codenumbers usage: update-rc.d [-n] [-f] basename remove update-rc.d [-n] basename defaults [NN | SS KK] update-rc.d [-n] basename start|stop NN runlvl [runlvl] [...] . update-rc.d [-n] basename disable|enable [S|2|3|4|5] -n: not really -f: force The disable|enable API is not stable and might change in the future. dpkg: error processing ganeti2 (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for python-support ... Errors were encountered while processing: ganeti2 # I purged the package, then tried to re-install, getting the same effect. Hmm, this is strange, I always test packages for installation before uploading a new release and I haven't seen this. Furthermore, the piuparts service shows ganeti installing correctly (http://piuparts.debian.org/sid/pass/ganeti2_2.5.1-1.log): The following NEW packages will be installed: ganeti2 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 1390 kB of archives. After this operation, 5016 kB of additional disk space will be used. Get:1 http://piatti.debian.org/debian/ sid/main ganeti2 all 2.5.1-1 [1390 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 1390 kB in 0s (27.4 MB/s) Selecting previously unselected package ganeti2. (Reading database ... 9527 files and directories currently installed.) Unpacking ganeti2 (from .../ganeti2_2.5.1-1_all.deb) ... Setting up ganeti2 (2.5.1-1) ... invoke-rc.d: policy-rc.d denied execution of start. Processing triggers for python-support ... So no errors in the setting up phase. Maybe update-rc.d has changed since I uploaded? I'll check anew, thanks for the report. thanks, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677674: [Pkg-ganeti-devel] Bug#677674: ganeti2: does not install cleanly
On Sat, Jun 16, 2012 at 11:01:43PM +0200, Toni Mueller wrote: Hi, On Sat, Jun 16, 2012 at 10:43:17AM +0200, Iustin Pop wrote: On Sat, Jun 16, 2012 at 01:04:50AM +0200, Toni Mueller wrote: 5 files changed, 2036 insertions(+) create mode 100644 bash_completion.d/ganeti create mode 100644 cron.d/ganeti create mode 100644 default/ganeti create mode 100755 init.d/ganeti E: Sub-process /usr/bin/dpkg returned an error code (1) Hmm, what is this git output? Could it be that the git hooks failed somehow? this is from etckeeper. Yes, but note that the error code is from before the update-rc message. Could you please post the un-abbreviated install log? I'm curious if there are any other errors before dpkg returned an error code. It's true that there seems to be an update-rc.d call issue, but that seems to be after dpkg already failed, during aptitude rollback phase. Maybe update-rc.d has changed since I uploaded? I'll check anew, thanks for the report. I can't really tell. It has been like this for a while, but I have only just gotten around to verify that this problem is likely to be in your package. For a while? That is very strange then. I'll have to create a new chroot and install ganeti fresh then, since this doesn't match my install in existing chroot results. thanks! iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675837: protobuf: FTBFS[!linux]: error: 'isatty' was not declared in this scope
On Mon, Jun 11, 2012 at 03:08:54PM +0100, Steven Chamberlain wrote: Hi, Actually there seems to be another problem after this, when building the Java bindings. I wonder if Build-Depends: default-jdk is really acceptable for platforms without an openjdk: Setting up gcj-4.7-jdk (4.7.0-4) ... Setting up gcj-jdk (4:4.7.0-6) ... Setting up default-jdk (1:1.5-47) ... ... # java bindings # this code mimics mvn package. This should be changed when maven is supported by debian. /bin/sh /usr/bin/ant -f debian/java-build.xml jar Buildfile: /tmp/buildd/protobuf-2.4.1/debian/java-build.xml generate: [mkdir] Created dir: /tmp/buildd/protobuf-2.4.1/java/target/generated-sources [echo] src compile: [mkdir] Created dir: /tmp/buildd/protobuf-2.4.1/java/target/classes [javac] Compiling 38 source files to /tmp/buildd/protobuf-2.4.1/java/target/classes ... [javac] 70. ERROR in /tmp/buildd/protobuf-2.4.1/java/src/main/java/com/google/protobuf/TextFormat.java (at line 599) [javac] matcher.usePattern(TOKEN); Indeed, it might be not. This looks like what I've seen a long while ago, when sun-jdk/openjdk was too old even on platforms where it existed. Do I understand correctly, that building depends on openjdk (or rather said, on a JDK which supports java 1.5 or newer, or 1.6 or newer), so therefore it worked until now since the kfreebsd-* builders only built the arch-specific package? And you're trying to build all packages, not just binary ones, so that's why I fails? I wonder if the resulting JAR file built on (e.g.) amd64 works fine on a machine which doesn't have openjdk. Finally: maybe this should be split as a different bug; the gcc-4.7 fix is good (much appreciated!), so I can upload that soon. thanks, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675837: protobuf: FTBFS[!linux]: error: 'isatty' was not declared in this scope
On Sun, Jun 03, 2012 at 06:11:03PM +0200, Christoph Egger wrote: Package: src:protobuf Version: 2.4.1-2 Severity: serious Tags: sid wheezy User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the kfreebsd-* buildds: Yes, I know. The gcc 4.7 transition, *again*. thanks, iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674234: override: libprotobuf-dev:optional, libprotobuf-java:optional, libprotobuf-lite7:optional, etc.
Package: ftp.debian.org Severity: normal Hi, composing this manually as reportbug crashes on me; sorry if the format is wrong. I've changed the priority for all packages built from source package 'protobuf' from extra to optional, per #664744. I would appreciate if you can update the override file. The actual message is: libprotobuf-dev_2.4.1-2_amd64.deb: package says priority is optional, override says extra. libprotobuf-java_2.4.1-2_all.deb: package says priority is optional, override says extra. libprotobuf-lite7_2.4.1-2_amd64.deb: package says priority is optional, override says extra. libprotobuf7_2.4.1-2_amd64.deb: package says priority is optional, override says extra. libprotoc-dev_2.4.1-2_amd64.deb: package says priority is optional, override says extra. libprotoc7_2.4.1-2_amd64.deb: package says priority is optional, override says extra. protobuf-compiler_2.4.1-2_amd64.deb: package says priority is optional, override says extra. python-protobuf_2.4.1-2_amd64.deb: package says priority is optional, override says extra. All binary packages should be updated: section stays the same, priority becomes optional. thanks! iustin signature.asc Description: Digital signature
Bug#674033: ganeti2: Some disk operations broken in squeeze
On Tue, May 22, 2012 at 12:21:43PM -0400, Justin Azoff wrote: I had upgraded to ganeti2 and then tried converting some plain disk types to drbd, and everything broke: 2011-12-30 10:39:37,045: ganeti-masterd pid=2140/JobQueue22 INFO Op 1/1: Starting opcode CLUSTER_REPAIR_DISK_SIZES 2011-12-30 10:39:37,104: ganeti-masterd pid=2140/ClientReq13 INFO Received job poll request for 4053 2011-12-30 10:39:37,241: ganeti-masterd pid=2140/JobQueue22 INFO Disk 0 of instance FOO has mismatched size, correcting: recorded 1024, actual 0 2011-12-30 10:39:37,270: ganeti-masterd pid=2140/ClientReq13 INFO Received job poll request for 4053 2011-12-30 10:39:37,332: ganeti-masterd pid=2140/JobQueue22 WARNING Disk 1 of instance FOO did not return valid size information, ignoring Then when the disk conversion failed things like this started happening: 2011-12-30 10:40:11,046: ganeti-masterd pid=2140/JobQueue19 WARNING Could not prepare block device sda on node BAR (is_primary=False, pass=1): Error while assembling disk: Can't activate lv /dev/xenvg/0c44e017-a28f-4e56-a6bb-990ce83c2116.sda: One or more specified logical volume(s) not found. Hi, Not sure if this is the cause. The patch you quote only breaks repair-disks-sizes, in that it wouldn't work at all, not break disk activation. The fix is already in the upstream version, backporting it onto the stable package makes everything happy: http://git.ganeti.org/?p=ganeti.git;a=commitdiff;h=e50d88078e1dbfe3d78aa174b760aa6142f54b6c commit e50d88078e1dbfe3d78aa174b760aa6142f54b6c Author: Iustin Pop ius...@google.com Date: Tue Feb 15 14:39:44 2011 +0100 Fix LUClusterRepairDiskSizes and rpc result usage This LU was introduced before the RPC result conversion from .data to .payload, and it has managed to keep the old-style usage (how? it's the only LU that does so). Fix by changing to payload, and add some extra logging for easier diagnose. Signed-off-by: Iustin Pop ius...@google.com Reviewed-by: Stephen Shirley diam...@google.com Reviewed-by: Michael Hanselmann han...@google.com (cherry picked from commit 043beb38f4e10b75d0820c361c668c441c7a6980) I only ran into this when I tried converting from plain to drbd, so it's possible that most people will never have this problem. 2.1.x is also fairly old at this point, but it is the version in stable.. We're supporting newer version in backports; 2.4.5 is the current squeeze-backports version. Would that work for you? Alternatively, I could try to prepare a bugfix for stable, not sure if it could go in or not. Thanks for the report! iustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606898: python-pyxattr: Please package for python3
On Thu, Mar 15, 2012 at 02:33:06PM +0100, Didier 'OdyX' Raboud wrote: tags 606898 +patch thanks Hi Tim, hi Iustin, Le 12.12.2010 21:24, Tim a écrit : Package: python-pyxattr Severity: wishlist The latest version of pyxattr supports python3. However, no package exists in Debian for this, so it must be built from source when developing for python3. I am not aware of any other python 3.x compatible modules which suit my needs for accessing extended filesystem attributes. Building from source for python3 is actually quite straight-forward and created no problems for me on Sid, so it shouldn't be too much trouble to add a python3-pyxattr package. Here is a patch that creates both the python3-pyxattrs and its -dbg flavour. It uses the dh_python3 helper and just works in a fresh sid chroot. Iustin: please consider merging and uploading a fix to this bug. (Otherwise, no fondue for you...) :-) Hi all, During the investigation of another bug (as upstream), I've come to realise that the Python 3 namespace argument parsing is broken; so proper Python 3 support will have to wait a bit until I make another release (soonish). Didier: the patch looks good, will integrate it. thanks, iustin signature.asc Description: Digital signature
