Bug#962078: apt-listchanges: feature request: combine identical changelog entries from multiple packages
I apologize for the delayed response; for no reason I have yet managed to identify, I seem to have not received mail about any of the comments on this bug report. I believe I saw some combine-able changelog entries in a set of updates I installed just this past week, but I did not bother to confirm that they were sufficiently identical to have been combined, nor to remember what the packages involved were; I had no reason to expect those details to be any more important than they have been in the past several years. However, I did mention a few specific package names and associated version numbers in the original message with which I filed this bug report: > Specifically [...], kcrash, kdbusaddons, and kemoticons have > changelog entries for version 5.70.0-1 which differ only in the > package name and the exact timestamp. I believe it should be possible to obtain the .deb files for these from snapshot.debian.org, assuming that is currently functional. If my recollection is correct, those are the package names as they were shown in the apt-listchanges output; I do not know offhand whether that represents names of source packages, binary packages, neither of the above, or some combination. Is that information sufficient to be able to provide a reproducer for testing potential fixes? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#962078: apt-listchanges: feature request: combine identical changelog entries from multiple packages
Just as a supporting note on this: during today's routine dist-upgrade against testing I have seen yet another mass update of KDE-related packages, and this time I've taken the trouble to make a count. If that count is accurate, there appear to be as many as *43* different changelog entries (as presented by apt-listchanges) which are identical except for the displayed package name and exact timestamp. In all cases, the version number given is either 5.97.0-1 or an epoch-prefixed version of the same. This is a considerably larger degree of changelog-list clutter than with the three packages referenced in the message which opened this bug report as having identical changelog entries shown at once, and represents a correspondingly larger potential benefit from the ability to have them folded together into a single condensed entry. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
Nearly five months later, I'm just pinging in to say that I'm still A: interested in this, and B: waiting on any possible response as regards what qualifies as sufficient testing for the drop-the-problematic-file WIP branch. Once we're sufficiently certain that the result is OK as far as what would go into a package, I plan (as I have for some time now) to make a release with it, which should also include the new feature which has been sitting in Limbo for some time now. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#994081: (no subject)
I have the same result, although in my case, the command I had run was 'apt-get dist-upgrade' and there were no packages kept back. By "the same result", I mean that except for cosmetic things like the timestamp, the reported download speed, and the width of the wget download-progress bar, the output appears to be exactly identical. Looking at the scripts involved, I don't see anything that looks obviously different from what this seems to have been before; it's still just invoking 'apt-get check', reacting to the exit status, and returning success. That leads me to think that the difference must be the result of a change in the behavior of 'apt-get check', which would mean that the most likely cause is a change in apt itself. Looking at the apt changelog (from the uploads to experimental over the months of the release freeze), I see a few things which could maybe if the circumstances are right be handwaved as being related; however, I don't know the libdvd-pkg design well enough to be able to judge which of them might actually be related, and I'm not currently inclined to grab the apt source and start digging to see what 'apt-get check' is actually doing now that might be different from the last time this was known to be working. I do want to note that after getting this error, I ran 'dpkg-reconfigure libdvd-pkg' as suggested elsewhere, and saw it complete with no errors. signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-05-30 at 19:53, The Wanderer wrote: > On 2021-05-30 at 09:33, The Wanderer wrote: > >> There is now a 'wip' branch on the relevant GitHub repository, >> which includes a commit dropping this. I haven't pushed it to the >> primary branch yet, because I'm still not certain how to properly >> test the result; I'm reasonably certain that it is / will be fine, >> but "reasonably certain" shouldn't be enough to move forward on >> when there's an alternative. Now that the new stable release of Debian has been out for a couple of weeks: any status on this? That potential new moosic release (without examples/completion, and with the new play-one command) is still pending testing of the result; I have no reason to expect it to not work, and certainly haven't managed to find anything that does break with it gone, but I don't know what would constitute a valid test of whether there is anything that fails to work without it but did work with it. [Re the bug that manifests when one of the playback commands in the moosic config file would give "No such file or directory":] > Once I've either found and fixed the bug or (much less likely) > assured myself it's not going to manifest in plausibly-real-world > user scenarios, In the somewhat-extensive meantime, I have done the latter of these. I still don't know what causes the buggy behavior, but I've confirmed that it already seems to exist in the previously packaged version, and I don't believe it's going to manifest in real-world usage. As such, I don't consider this a blocker for moving forward. (For reference, the buggy behavior is that even when moosicd is already running, moosic will in some cases fail to detect it - more specifically, the moosic internal client-server command 'no_op' will fail - and will therefore try to start a new instance of the daemon.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#993132: python3-fife: prints "is"/"is not" used-with-a-literal warnings at install time
Package: python3-fife Version: 0.4.2-3 Severity: normal Dear Maintainer, When I installed python3-fife as a dependency from another package, I saw the following printed in the console: Setting up python3-fife (0.4.2-3) ... /usr/lib/python3/dist-packages/fife/extensions/fife_settings.py:301: SyntaxWarning: "is not" with a literal. Did you mean "!="? if module is not "FIFE": /usr/lib/python3/dist-packages/fife/extensions/fife_settings.py:435: SyntaxWarning: "is" with a literal. Did you mean "=="? if module is "FIFE": /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/animationicon.py:193: SyntaxWarning: "is not" with a literal. Did you mean "!="? if anim is not "": /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/curvegraph.py:164: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/linegraph.py:157: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/pointgraph.py:157: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1038: SyntaxWarning: "is" with a literal. Did you mean "=="? if len(margin) is 4: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1044: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 3: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1050: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 2: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1056: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 1: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1068: SyntaxWarning: "is" with a literal. Did you mean "=="? if len(padding) is 4: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1074: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 3: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1080: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 2: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1086: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:640: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:663: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:686: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmapsaver.py:301: SyntaxWarning: "is not" with a literal. Did you mean "!="? if info.getSubdivisions() is not 32: Setting up unknown-horizons (2019.1-3) ... /usr/lib/python3/dist-packages/horizons/extscheduler.py:72: SyntaxWarning: "is" with a literal. Did you mean "=="? if obj.loops > 0 or obj.loops is -1: I'm not sufficiently familiar with either the language or the codebase to be sure about whether these represent harmless warnings (in which case this bug should be "minor") or could produce actual unintended behavior, although I think the former is more likely; however, either way, having this output appear isn't the best user-facing appearance. Please adjust the package such that this type of output does not appear at the point of package installation. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages python3-fife depends on: ii libboost-filesystem1.74.0 1.74.0-9 ii libc6 2.31-13 ii libfifechan0.1.5 0.1.5-2 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libopenal1 1:1.19.1-2 ii libpng16-161.6.37-3 ii libpython3.9 3.9.2-1 ii libsdl2-2.0-0 2.0.14+dfsg2-3 ii libsdl2-image-2.0-02.0.5+dfsg1-2 ii libsdl2-ttf-2.0-0 2.0.15+dfsg1-1 ii libstdc++6 10.2.1-6 ii libtinyxml2.6.2v5 2.6.2-4 ii libvorbisfile3 1.3.7-1 ii python33.9.2-3 ii
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 13:02, The Wanderer wrote: > On 2021-07-16 at 12:55, Ian Jackson wrote: > >> I have now tested this. I found that a safety catch in >> mount-functions caused it to not work, and this additional patch is >> needed. >> >> mount-functions looks in /etc/filesystems and skips mounting things >> which the kernel doesn't seem to supoort. In general with so many >> filesystems being kernel modules this seems to be of questionable use. >> In this case it definitely broke things: I found that mounting the >> filesystem with mount(8) auto-loads the module. >> For your testing: >> >> AFAICT it isn't a particularly good idea to just copy the new >> mount-functions.sh into /lib but monkey-applying the patch with >> >> patch /lib/init/mount-functions.sh < >> 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch >> >> worked for me. With those patches (and the bodge in fstab commented >> it) it all works. > > I need to do some other things for a while, so I won't be rebooting > again immediately, but I'll probably test this sometime this afternoon. This has now been tested (twice, once from intentional shutdown and once from unexpected power loss). I did not make note of what boot-time message(s) there may or may not have been, but the mount is still in place and functioning without issues, and I don't see any new errors in e.g. dmesg. Barring reason to do otherwise, I plan to leave the patch applied until such time as something overwrites it (probably on a package upgrade). If I notice any issues, I will try to report back. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 13:36, Ian Jackson wrote:
> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
>
>> Wouldn't testing the existence of
>>
>> /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko
>>
>> be enough, and probably more reliable?
>
> I'm doubt very much it would be more reliable. What if the kernel
> reorganises its modules ?
That possibility hadn't even occurred to me, but now that you point it
out, I drop this suggestion.
>> (I'm assuming that the test which skips because "fstype not
>> available" comes before the one which skips because "already
>> mounted", and that's why I saw the warning even though it seems to
>> be up and working on my machine.)
>
> Yes, the tests are indeed in that order. I think you have it
> mounted now because of the apparmor fixup you found.
I was initially not sure that was going to be relevant after all,
because I was expecting AppArmor to be a thing that has to be constantly
running in order to be effective, and there's no such process visible
that I can see - but apparmor shows up in dmesg, et cetera, so I must
have been expecting wrong.
> The change to mountkernfs was ineffective on your system for the same
> reason it was ineffective on mine, but the apparmor workaround means
> you don't see the effects since apparmor has got it mounted by the
> time you log in.
Makes perfect sense.
>> I need to do some other things for a while, so I won't be
>> rebooting again immediately, but I'll probably test this sometime
>> this afternoon.
>>
>>
>> My current biggest concern about this is:
>>
>> --
>
> No objections then ? :-) (I think you may have missed a bit...)
Heh. That line was a leftover of when I was going to raise the question
of why the "fstype not available" test was even being reached, given the
"already mounted" test, before I realized that it must be simply a
matter of test order.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 12:55, Ian Jackson wrote: > I have now tested this. I found that a safety catch in > mount-functions caused it to not work, and this additional patch is > needed. > > mount-functions looks in /etc/filesystems and skips mounting things > which the kernel doesn't seem to supoort. In general with so many > filesystems being kernel modules this seems to be of questionable use. > In this case it definitely broke things: I found that mounting the > filesystem with mount(8) auto-loads the module. > > I'm using the existence of the mountpoint directory as a proxy for the > filesystem/module being available. IDK if that is exactly right, but > if it isn't the worst case is an error message about failing to mount > it. Wouldn't testing the existence of /lib/modules/`uname -r`/kernel/fs/efivarfs/efivarfs.ko be enough, and probably more reliable? (I'm assuming that the test which skips because "fstype not available" comes before the one which skips because "already mounted", and that's why I saw the warning even though it seems to be up and working on my machine.) > For your testing: > > AFAICT it isn't a particularly good idea to just copy the new > mount-functions.sh into /lib but monkey-applying the patch with > > patch /lib/init/mount-functions.sh < > 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch > > worked for me. With those patches (and the bodge in fstab commented > it) it all works. I need to do some other things for a while, so I won't be rebooting again immediately, but I'll probably test this sometime this afternoon. My current biggest concern about this is: -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 12:06, Ian Jackson wrote: > Control: tags -1 + patch > Here you go, in diff format and also a file you can just run. I > haven't rebooted with it (yet), but I did manually unmount the > efivars subdir and verify that the new mountkernfs script remounts > it. I've just rebooted, with this in place as /etc/init.d/mountkernfs.sh. (I kept the original around as a renamed file in the same directory.) The boot-time messages - which, unexpectedly and a bit bizarrely, don't seem to be logged anywhere that I'm managing to find - include with the following four lines (transcribed from a photograph taken before launching X), at what appears to be the beginning of the boot process: >> INIT: version 2.96 booting >> Using makefile-style concurrent boot in runlevel S. >> Filesystem type 'efivarfs' is not supported. Skipping mount. ... (warning). >> Starting hotplug events dispatcher: systemd-udevd. Where the string "(warning)." is in orange, rather than the usual whitish gray. /sys/firmware/efi/efivars/ exists and is populated just as on the previous boot, so this didn't break anything, but it also doesn't seem as if it would have helped if that directory hadn't been mounted for other reasons. I notice that the line >>> Registered efivars operations appears in the output of 'dmesg', as well as being present (with similar context) in /var/log/messages* and /var/log/syslog* from at least the past several boots; if the context would be helpful in figuring out when/where/how/by-what this is being mounted, I can share the surrounding lines, or even potentially the entire output if that's considered potentially safe. I'm also willing to consider other steps to track down what's making this work for me, if people care to suggest them. (Unpacking and analyzing the initrd might well be useful, but is more than I'm interested in undertaking just at the moment, although I can probably do it at some point if necessary.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 11:54, Thorsten Glaser wrote: > On Fri, 16 Jul 2021, The Wanderer wrote: > >> On Fri, 16 Jul 2021, Ian Jackson wrote: >> >>> On Fri, 16 Jul 2021, The Wanderer wrote: >>>> A possible additional complicating factor: on my system >>>> (tracking current testing, which I suspect is likely to turn >>>> into stable fairly > > Roughly 15 more days, AFAIHH. I didn't realize it had actually been scheduled; in my experience, any time someone asks when the release will happen, the only answer is "When it's ready.", and the gap between the ready date becoming known and the release happening tends to be so small there's no room for the question to be asked. >>>> soon), with sysvinit as the active init system, this directory >>>> already exists and is already mounted. > > Then test for existence of a file inside that first. I don’t have > access to an EFI system, can you share an “ls -l > /sys/firmware/efi/efivars”, and probably an “ls -l /sys/firmware/efi” > and “mount” as well? I think in principle relying on any specific file inside there would be potentially fragile, but in practice it might be possible to choose something that would be unlikely to go away in later kernels etc.. The attached file contains the requested output. It's not clear immediately whether the UUIDs are machine-specific or will be consistent across machines; efivarfs.rst.txt points me to /usr/share/doc/linux-doc-5.10/Documentation/ABI/stable/sysfs-firmware-efi-vars.gz - which mentions namespacing via vendor GUID, but also seems to say that the items whose names will contain those GUIDs are directories, so I'm not sure whether it's relevant here. >>> I suggest the following approach in mountkernfs: > > 1.See if /sys/firmware/efi/efivars/somefile exists; > if it does, it’s already mounted, and there’s > nothing to do. > >>> - See if /sys/firmware/efi/efivars exists. >>> >>> - If it does, and nothing is mounted on it yet, try to mount >>> efivarfs with the runes earlier in this bug. > > Is /sys/firmware/efi also a mountpoint, or is it a mere directory? On my system, it is not mentioned separately in the output of 'mount'. I think, but am not positive, that that's sufficient indication that it isn't a mountpoint. > Does it always contain an efivars subdirectory? I can't testify one way or the other, but I suspect from the little I've read about this that it does not. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw /sys/firmware/efi: total 0 -r--r--r-- 1 root root 4096 Jul 16 08:23 config_table drwxr-xr-x 2 root root0 Jul 15 18:29 efivars drwxr-xr-x 3 root root0 Jul 16 08:23 esrt -r--r--r-- 1 root root 4096 Jul 16 08:23 fw_platform_size -r--r--r-- 1 root root 4096 Jul 16 08:23 fw_vendor drwxr-xr-x 2 root root0 Jul 16 08:23 mok-variables -r--r--r-- 1 root root 4096 Jul 16 08:23 runtime drwxr-xr-x 19 root root0 Jul 16 08:23 runtime-map -r 1 root root 4096 Jul 16 08:23 systab /sys/firmware/efi/efivars: total 0 -rw-r--r-- 1 root root 14 Jul 15 18:29 AmdAcpiVar-79941ecd-ed36-49d0-8124-e4c31ac75cd4 -rw-r--r-- 1 root root 132 Jul 15 18:29 AMD_PBS_SETUP-a339d746-f678-49b3-9fc7-54ce0f9df226 -rw-r--r-- 1 root root 12 Jul 15 18:29 AMD_RAID-fe26a894-d199-47d4-8afa-070e3d54ba86 -rw-r--r-- 1 root root 1557 Jul 15 18:29 AmdSetup-3a997502-647a-4c82-998e-52ef9486a247 -rw-r--r-- 1 root root8 Jul 15 18:29 AmiHardwareSignatureSetupUpdateCountVar-81c76078-bfde-4368-9790-570914c01a65 -rw-r--r-- 1 root root 28 Jul 15 18:29 AMITCGPPIVAR-a8a2093b-fefa-43c1-8e62-ce526847265e -rw-r--r-- 1 root root 1024 Jul 15 18:29 AOD_SETUP-5ed15dc0-edef-4161-9151-6014c4cc630c -rw-r--r-- 1 root root8 Jul 15 18:29 ApSyncFlagNv-ad3f6761-f0a3-46c8-a4cb-19b70ffdb305 -rw-r--r-- 1 root root5 Jul 15 18:29 asusbkpsmmflag-3eb0ceb0-5890-4853-9a13-0942ec71 -rw-r--r-- 1 root root 20 Jul 15 18:29 AsusRomLayout-2e0585e9-2b5e-4f1e-bbeb-e632c5ef44b8 -rw-r--r-- 1 root root 56 Jul 15 18:29 AutoDetectData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r-- 1 root root 186 Jul 15 18:29 BiosEventLog-4034591c-48ea-4cdc-864f-e7cb61cfd0f2 -rw-r--r-- 1 root root 92 Jul 15 18:29 BiosSettingMappingTable-b57086d5-c2e5-4654-9e3a-0b55830fbb32 -rw-r--r-- 1 root root 122 Jul 15 18:29 Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root 126 Jul 15 18:29 Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root6 Jul 15 18:29 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r-- 1 root root5 Jul 15 18:29 BootFromUSB-ec87d643-eba4-4b
Bug#783990: efivarfs is a separate fs and needs moutning
(For some reason, I haven't gotten the copy of this reply that comes to
me via debian-init-diversity, even though it's clearly Cc'ed to the bug
which appears to send copies to that list. Is something in the chain -
probably BDO - detecting that I'm already in Cc and not sending the
second copy? That would be unfortunate, and a reason for me to return to
replying only to the bug number rather than to the full addressee
list...)
On 2021-07-16 at 11:00, Ian Jackson wrote:
>
> The Wanderer writes ("Re: Bug#783990: efivarfs is a separate fs and
> needs moutning"):
>>
>> I'm not sure what's making the difference (unless this is already
>> fixed for testing, and you're only discussing whether to backport
>> the fix to current stable, which I think doesn't sound like it is
>> the case),
>
> Perhaps the initramfs mounts it ? I can't conveniently check.
A quick grep through /usr and /etc/ for 'efivar' finds one thing that
looks potentially relevant: /etc/apparmor.d/abstractions/libvirt-lxc
includes a mount command for this directory.
(It also finds that
/usr/share/doc/linux-doc-5.10/html/_sources/filesystems/efivarfs.rst.txt
suggests 'mount -t efivarfs none mountpoint' rather than 'mount -t
efivarfs efivarfs mountpoint', but I suspect the end result will be the
same regardless.)
>> and I'm not sure where to look to try to find out - but whatever
>> fix is found for anyone experiencing this problem, it'll be
>> important to make sure it doesn't break people for whom this *is*
>> working.
>
> Certainly.
>
> I suggest the following approach in mountkernfs:
>
> - See if /sys/firmware/efi/efivars exists.
>
> - If it does, and nothing is mounted on it yet, try to mount
> efivarfs with the runes earlier in this bug.
>
> - If that mount fails, print an error message, but otherwise
> do not treat this as an error.
>
> If you think this is a good plan I will send a patch. Would each of
> you be willing to do a test reboot with it ?
That looks like a reasonable approach to me. I'm not sure exactly what
steps would be necessary to be sure that the reboot was properly testing
the patch, but as long as there's no meaningful risk of putting my
system into an unbootable state (an unlikely-seeming result), I have no
problem with testing this when time permits.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#783990: efivarfs is a separate fs and needs moutning
On 2021-07-16 at 10:23, Ian Jackson wrote:
> Control: tags -1 patch
>
> Thorsten Glaser writes ("Re: Bug#783990: efivarfs is a separate fs and needs
> moutning"):
>> This is not as easy as it sounds:
>>
>> tglase@tglase-nb:~ $ sudo mount -t efivarfs efivarfs
>> /sys/firmware/efi/efivars
>> mount: /sys/firmware/efi/efivars: mount point does not exist.
>> 32|tglase@tglase-nb:~ $ sudo mkdir -p /sys/firmware/efi/efivars
>> mkdir: cannot create directory ‘/sys/firmware/efi’: Operation not permitted
>>
>> This is on amd64 without EFI (classical BIOS, no CSM).
>
> Oh.
>
> I guess this should be done if /sys/firmware/efi/efivars exists, then.
>
> Can you confirm that that directory doesn't exist for you ?
A possible additional complicating factor: on my system (tracking
current testing, which I suspect is likely to turn into stable fairly
soon), with sysvinit as the active init system, this directory already
exists and is already mounted.
I'm not sure what's making the difference (unless this is already fixed
for testing, and you're only discussing whether to backport the fix to
current stable, which I think doesn't sound like it is the case), and
I'm not sure where to look to try to find out - but whatever fix is
found for anyone experiencing this problem, it'll be important to make
sure it doesn't break people for whom this *is* working.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-05-30 at 09:33, The Wanderer wrote: > There is now a 'wip' branch on the relevant GitHub repository, which > includes a commit dropping this. I haven't pushed it to the primary > branch yet, because I'm still not certain how to properly test the > result; I'm reasonably certain that it is / will be fine, but > "reasonably certain" shouldn't be enough to move forward on when > there's an alternative. > > Please follow up as you see fit, whether by testing (and letting me > know either about problems, or that it's OK and I can make a new > numbered release) or by letting me know how to test or by whatever > other means you feel appropriate. FYI in case it influences your decision-making, having pushed this WIP branch has inspired me to get back to hacking on moosic, and I've implemented a new feature whose absence I've been working around for some time (and which I know is actively requested by at least one other user of the program): the ability to say "play the next item in the queue, then stop". This can be simulated by e.g. 'moosic adv ; moosic no-adv', but that has a race condition with whether the playback has begun by the time the no-adv takes effect, and I'm fairly sure the in-program version avoids that. Unfortunately, it isn't quite perfect yet. Either it's 99% complete and introduces a bug, or it's 100% complete but exposes a pre-existing bug which I haven't found any other way to trigger; either way, I don't understand yet how the (moderately serious) bug comes about. Thus far, the bug only seems to manifest when ~/.moosic/config (or the equivalent in the directory specified with 'moosic -c') contains a playback command which is not actually available - i.e., trying to run that command would give "No such file or directory". I'm not sure whether that's rare enough in practice to warrant treating the bug as negligible, but I wouldn't be inclined to assume so myself. Once I've either found and fixed the bug or (much less likely) assured myself it's not going to manifest in plausibly-real-world user scenarios, either of which may take me A While, I plan to make another numbered release with that feature included. What effect that information may have on your own plans is up to you. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 06:11, The Wanderer wrote: > On 2021-03-12 at 05:57, Arto Jantunen wrote: > >> The Wanderer writes: > >>> Would this call for an upstream release dropping the file, or >>> are you OK with excluding it from what gets installed as part of >>> the package? >> >> I'd prefer an upstream release if you don't feel strongly about >> it, I think otherwise I need to filter the upstream tarball and >> I'd rather not. > > I'm a little hesitant to drop it, both because it'd be a (very > minor) pain to dig it up to add back later and because I'm not > entirely sure how to test the result for consistency and validity > (given that I currently lack usable VMs for install testing; nearly > all my testing of changes to date has been by running from the source > tree), but I've taken a stab at it locally. > > Any suggestions for how to test the post-drop source tree, or should > I just push 1.5.7.1 to GitHub and let you follow up at leisure? > > (This would probably be a good occasion for me to figure out how to > push secondary branches to GitHub, so that I can make this available > without an irrevocable update to master, but I don't feel like > investing that effort right at the moment. I might feel differently > once the day has gotten underway, but no guarantees.) After an unconscionably long time, for which I have no specific excuse (although I could provide plenty of less-specific ones), I've finally acquired a tuit that is of sufficient circularity. There is now a 'wip' branch on the relevant GitHub repository, which includes a commit dropping this. I haven't pushed it to the primary branch yet, because I'm still not certain how to properly test the result; I'm reasonably certain that it is / will be fine, but "reasonably certain" shouldn't be enough to move forward on when there's an alternative. Please follow up as you see fit, whether by testing (and letting me know either about problems, or that it's OK and I can make a new numbered release) or by letting me know how to test or by whatever other means you feel appropriate. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal
On 2021-04-25 at 20:45, Phil Morrell wrote: > Hi tarzeau, as promised here's the policy violation details for this > RFS. Despite the length, thank you for working on this, it seems to be a > fun collection. >> §7.4 >> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts >> Be aware that adding Conflicts is normally not the best solution when >> two packages provide the same files... >> >> Having similar functionality or performing the same tasks as another >> package is not sufficient reason to declare Breaks or Conflicts with >> that package. > > Similar functionality: > * fifteen (sgt-puzzles) > * mines (sgt-puzzles) > * sudoku (sudoku) > > It is reasonable for a user to want to have all of sgt-puzzles, > nbsdgames and kdegames (using a k prefix) installed simultaneously and > play different subsets of the games available. This also allows the user > to pick their favourite implementation where multiple exist. sgt-puzzles may potentially also be relevant here for another reason. At one point in its history, the binaries it installs were provided with no name prefix. This resulted in, for instance, /usr/games/net, which had a namespace collision with /usr/bin/net from samba-common-bin (even though the files themselves did not conflict, being under different paths). Later, the binaries were all renamed to have a 'sgt-' prefix; that turned /usr/games/net into /usr/games/sgt-net, making it unique. The prefix is short enough that tab-completion is not meaningfully interfered with in practice, at least not in my experience. I think it likely that the near-collision of the name, as well as the namespace claim of various other binaries in the package, is the reason for the addition of that prefix. The transition was a bit jarring on my end, as a user of the programs; it'd have been simpler by far if the prefix had just been there from the outset, as there is the chance to do in this case. > Given all this, I suggest you adopt a universal prefix for all the > games, perhaps "nb-"? On the other hand, it might be worth > preserving tab completion with a suffix instead, in which case no > harm with a full "-nbsdgames". I was going to suggest a 'nbsd-' prefix, for reasons of consistency with the collection name, but if 'nb-' is considered acceptable it would at least have the advantage of being faster and easier to type. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 05:57, Arto Jantunen wrote: > The Wanderer writes: >> Would this call for an upstream release dropping the file, or are >> you OK with excluding it from what gets installed as part of the >> package? > > I'd prefer an upstream release if you don't feel strongly about it, > I think otherwise I need to filter the upstream tarball and I'd > rather not. I'm a little hesitant to drop it, both because it'd be a (very minor) pain to dig it up to add back later and because I'm not entirely sure how to test the result for consistency and validity (given that I currently lack usable VMs for install testing; nearly all my testing of changes to date has been by running from the source tree), but I've taken a stab at it locally. Any suggestions for how to test the post-drop source tree, or should I just push 1.5.7.1 to GitHub and let you follow up at leisure? (This would probably be a good occasion for me to figure out how to push secondary branches to GitHub, so that I can make this available without an irrevocable update to master, but I don't feel like investing that effort right at the moment. I might feel differently once the day has gotten underway, but no guarantees.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 05:32, Arto Jantunen wrote: > The Wanderer writes: >> Neither of these things is new; they were true of the last version >> prior to the removal, and possibly of some versions prior to that >> as well. That makes this a bit aggravating. >> >> Still, I suppose that just means they slipped through the cracks of >> the less-stringent copyright review that's applied to packages >> already in the archive, rather than that they shouldn't need to be >> addressed... > > There is no systematic copyright review happening for packages that > are already in the archive (unless they add new binary packages and > end up in the NEW queue that way). I'm personally not a fan of how > this currently works in Debian, but "so there has ever been and ever > will be". Oh, I'm aware. The lack of systematic copyright review just means that what review does get applied is "whatever anyone who happens to be looking at the package happens to notice and cares to point out", which is clearly less stringent than what is applied at NEW time. ^_^ >> For examples/completion, it's not clear whether or not documenting >> the copyright statement would be enough. No specific license is >> stated for that file, so it's not clear what license Etienne PIERRE >> (whom I infer to be its original author, prior to later changes >> introduced by Daniel Pearson) would have intended for it. > > The completion script was actually provided through Debian initially > and then later included upstream: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184633 > > This initial submission includes a copyright statement, but no > license. Not asking for one was clearly my mistake. The advantages of incumbent, institutional-style knowledge! It wouldn't even have occurred to me to check for that sort of thing. > We might as well just remove it for now, we can easily bring it back > if we can come up with a plausible story about the licensing > situation. If you think that's OK for the package (and its users, who may or may not care about completion), then I'm fine with it for the moment. Would this call for an upstream release dropping the file, or are you OK with excluding it from what gets installed as part of the package? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
nse'd, and written by Daniel Pearson himself. We could always ask him (including questions about the two files noted above, in relation to the relicensing), but since I already inquired and he indicated that he no longer has interest in moosic, I don't want to impose on him unnecessarily. > In any case we have missed the freeze by a mile, so we have a couple > of years to get this done before the next round. I'd ideally prefer to at least have it in unstable (or at worst experimental) before the next stable release, but yeah, no rush to beat the freeze proper at this point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
(Apologies for breaking threading; I don't seem to have received the original mail, and my Web browser appears to be treating the mailto: links as something like file://mailto: links, and reports that it can't find any file by the given name.) On 2021-01-02 at 13:34, Arto Jantunen wrote: > The package has been uploaded and is in NEW awaiting processing by > the FTP team. Last night (as far as I can judge), this package disappeared from https://ftp-master.debian.org/new.html (which I take to be the NEW queue). As of a few minutes ago, it did not seem to be in the archive. A packages.debian.org search didn't find it in anything newer than stable (with the old version, of course), and the tracker.debian.org page for this package showed the last change being the removal this past April. I'm not sure whether this is normal (package approved, processing to get it actually into unstable doesn't happen right away, no visible sign of package's status in the meantime), or whether it may mean that the package has been rejected. If the former, then all is well. If the latter, I'd be interested to know the status, both so I know what to expect and in case there's anything I can do to help the package get in on a subsequent try. signature.asc Description: OpenPGP digital signature
Bug#981091: More-complete patch
On 2021-02-09 at 08:51, The Wanderer wrote:
> I'm seeing the same behavior, and I've put together a patch which
> looks like it should address the problem. I'm not providing it here
> just yet, because I haven't let it run overnight to confirm whether
> it works, but syntactically it seems like it should be OK.
Turns out I had a typo in that patch, and it didn't quite work right.
Here's an updated version, which also patches psaccu_atop in the
analogous way; whether that's necessary or not I don't know, but I've
had the combined patched version running overnight (and past another
cron-job schedule trigger) with no mailed warnings.
I haven't tested applying the patch from the diff; I edited the files
manually, generated the diff, and ran with the changes long enough to
test. Attempts to apply it to the already-patched live system with
'patch -d/ -p0 --dry-run' behaved as I'd expect if the patch were not
applied, so it's possible that this might need -R to work, but I can't
say for certain.
What I *can* say is that the changes represented in this patch seem to
eliminate the cron-job messages without other issues, at least that I've
observed to date. I'm not quite certain enough that the patch is good to
add the 'patch' tag to this bug report, but I'm not far short of that
either.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
--- /tmp/psaccs_atop 2021-01-20 13:33:03.0 -0500
+++ /etc/logrotate.d/psaccs_atop 2021-02-10 11:51:01.165928555 -0500
@@ -10,7 +10,7 @@
postrotate
# check if process accounting is installed
#
- if [ -e /etc/logrotate.d/psacct ] || grep -q 'savelog' /etc/cron.daily/acct
+ if [ -e /etc/logrotate.d/psacct ] || ([ -e /etc/cron.daily/acct ] && grep -q 'savelog' /etc/cron.daily/acct)
then
# check if process accounting is actually in use
#
@@ -18,9 +18,12 @@
then
ACCTFILE=`awk '$2 == "{" {print $1}' /etc/logrotate.d/psacct`
fi
-if grep -q 'savelog' /etc/cron.daily/acct
+if [ -e /etc/cron.daily/acct ]
then
-ACCTFILE=`sed -n "/savelog[^\/]\+\(\/[[:alnum:]\/]\+\).*/{s//\1/;p;q;}" /etc/cron.daily/acct`
+if grep -q 'savelog' /etc/cron.daily/acct
+then
+ACCTFILE=`sed -n "/savelog[^\/]\+\(\/[[:alnum:]\/]\+\).*/{s//\1/;p;q;}" /etc/cron.daily/acct`
+fi
fi
if [ -f "$ACCTFILE" ]
--- /tmp/psaccu_atop 2021-02-11 20:29:08.973973635 -0500
+++ /etc/logrotate.d/psaccu_atop 2021-02-11 20:29:34.093874797 -0500
@@ -8,7 +8,7 @@
ifempty
create 0600 root root
postrotate
- if [ -e /etc/logrotate.d/psacct ] || grep -q 'savelog.*/var/log/account/pacct' /etc/cron.daily/acct
+ if [ -e /etc/logrotate.d/psacct ] || ([ -e /etc/cron.daily/acct ] && grep -q 'savelog.*/var/log/account/pacct' /etc/cron.daily/acct)
then
# if the atop daemon does not run, restart it after
# accounting file is rotated
signature.asc
Description: OpenPGP digital signature
Bug#981091: Same here, plus partial patch
On 2021-02-09 at 08:51, The Wanderer wrote: > I'm seeing the same behavior, and I've put together a patch which > looks like it should address the problem. I'm not providing it here > just yet, because I haven't let it run overnight to confirm whether > it works, but syntactically it seems like it should be OK. Oops; I rewrote the above after having decided not to include the patch yet, but forgot to detach the attachment. Oh, well. Please consider it as you will; it's completely untested for now. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#981091: Same here, plus partial patch
I'm seeing the same behavior, and I've put together a patch which looks
like it should address the problem. I'm not providing it here just yet,
because I haven't let it run overnight to confirm whether it works, but
syntactically it seems like it should be OK.
I've also patched /etc/logrotate.d/psaccu_atop, which had a line which
seemed like it should be triggering the behavior in its turn, although I
don't know whether or not it was doing so in practice. I forgot to make
a backup copy of the file before applying the change, however, so I
don't have a ready way to generate a diff from that one. The change
should be simple and obvious by analogy to the psaccs_atop patch.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
--- /tmp/psaccs_atop 2021-01-20 13:33:03.0 -0500
+++ /etc/logrotate.d/psaccs_atop 2021-02-09 08:34:57.633250717 -0500
@@ -10,7 +10,7 @@
postrotate
# check if process accounting is installed
#
- if [ -e /etc/logrotate.d/psacct ] || grep -q 'savelog' /etc/cron.daily/acct
+ if [ -e /etc/logrotate.d/psacct ] || ([ -e /etc/cron.daily/acct ] && grep -q 'savelog' /etc/cron.daily/acct)
then
# check if process accounting is actually in use
#
@@ -18,9 +18,12 @@
then
ACCTFILE=`awk '$2 == "{" {print $1}' /etc/logrotate.d/psacct`
fi
-if grep -q 'savelog' /etc/cron.daily/acct
+if [ -e /etc/cron.daily/acct]
then
-ACCTFILE=`sed -n "/savelog[^\/]\+\(\/[[:alnum:]\/]\+\).*/{s//\1/;p;q;}" /etc/cron.daily/acct`
+if grep -q 'savelog' /etc/cron.daily/acct
+then
+ACCTFILE=`sed -n "/savelog[^\/]\+\(\/[[:alnum:]\/]\+\).*/{s//\1/;p;q;}" /etc/cron.daily/acct`
+fi
fi
if [ -f "$ACCTFILE" ]
signature.asc
Description: OpenPGP digital signature
Bug#979682: startpar: Is it running anything in parallel?
On 2021-01-09 at 18:56, Michael Krylov wrote: > Package: startpar > Version: 0.61-1 > Severity: important This version is present in current Debian stable, but there is a newer version available in current testing and unstable: 0.64-3. > Dear Maintainer, (Disclaimer: I am not a startpar maintainer as such, only an interested bystander. As such, I have no specific startpar expertise to date, only what I can observe and deduce.) > I get a feeling that startpar doesn't work as it was intended. > That is, it doesn't parallel the service starting at the boot. > > I've conducted a couple of experiments: first, with makefile-style boot > and startpar (the default one) and second, without startpar, by creating > the /etc/init.d/.legacy-bootordering file. > > Both of them yielded about the same time, 21±1 sec for me. > > More than that, after reading its man page, I've tried to run startpar this > way: > > /lib/startpar/startpar sleep sleep sleep -a 10 > > And sure enough, it starts three sleep processes one by one and finishes after > 30 seconds instead of 10. On a computer tracking current Debian testing, with startpar 0.64-3, I see: $ time /bin/startpar sleep sleep sleep -a 10 real0m10.006s user0m0.009s sys 0m0.000s $ time /bin/startpar sleep sleep -a 10 real0m10.014s user0m0.012s sys 0m0.000s (Judging from the changelogs, the startpar binary was moved to /bin in package version 0.63~beta-1.) As such, I do not appear to encounter this behavior on my system. > I might be wrong, but doesn't this mean that startpar is basically > useless now? The changelog for startpar 0.64 includes the following entry: >> * Fixed regression which could cause jobs to run in serial (interactive >> mode) instead of parallel when devpts check failed. >> Should greatly increase performance on affected systems. I'd guess that you may be hitting this regression. If so, the problem should be fixed in the currently latest startpar, although that version is apparently not in current testing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
First, the bad news. In trying to test the playlist-file compatibility concern, I've discovered that at least on my system as it now exists, the default moosic configuration in the published codebase doesn't play WAV files (or anything else that relies on sox) correctly. IIRC it did work back in September, but I'm guessing something may have changed in the meantime; I've certainly done enough package upgrades for that to be plausible. The moosic configuration from the Python-2-based instance I've been running for all these years, however, does play the files correctly. Trouble is, I don't know whether it's likely to work on a standard Debian install, or whether mine is special in some way. The difference is that the default ~/.moosic/config defines WAV files as being played by invoking 'sox $item -t ossdsp /dev/dsp' (and fails with "no handler for given file type 'ossdsp'"), and the live-environment one defines them to be played by invoking 'play $item'. This can be tested either via moosic, by adjusting the config file, or simply by invoking sox with that syntax on a WAV file which sox knows how to play. If you get a chance to test with either method on a known-baseline Debian system, and it turns out that the observed behavior is indeed not specific to my environment, please let me know; I'll be happy to either spin up a minor (micro?) release which adjusts the default config, or if preferred, just provide a patch without making a new release yet. Second, two pieces of good news. One: although the playlist-queue file doesn't seem to be identical in format to the one from the Python 2 daemon, it does seem to be quite similar, and the code which generates it hasn't changed (except for the exact syntax of catching errors). I was able to take a moosic configuration directory generated with the Python 2 daemon and load it with the Python 3 daemon, and it seems to work without issues. Two: it looks like either I was wrong in remembering that the Py2 daemon and Py3 client don't talk to one another cleanly, or I managed to fix the problem before and forgot about it. I accidentally invoked the Py3 client in a way which seems to have made it interact with the Py2 daemon, and aside from one text-encoding error message which might be cosmetic, it seems to have worked fine - including adding a file to the existing daemon's playlist in a way which the existing daemon was able to parse and handle without issues. So my previously mentioned upgrade-scenario concerns may indeed not be a problem in practice. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: not Python-3-compatible, so due for removal
Thinking about this again, I feel I should note for your awareness when it comes to packaging that the primary things I'm concerned about on upgrades are already-running daemons and existing playlist files. I don't remember to what extent I tested this when I did the original porting work back in September, so I'm not positive either of these things is actually an issue, but both should be tested in the packaged version if possible (in case there's anything that can be done, or needs to be documented, at upgrade time there). If I recall my observations correctly, the Python-3-based client will not communicate correctly with the Python-2-based daemon. Whether this will just result in error messages, or potentially cause problems (e.g. corrupting the playlist and/or history file), I would have to re-test to be certain. As the daemon typically runs on a per-user basis, we can't restart it at package upgrade time, so this will probably need to be handled by a user-visible notice (e.g. NEWS entry). I could look into adding a client-launch-time check and notification about this on the upstream side, or even potentially an "automatically kill and re-launch the daemon if we've crossed the Python-versions boundary" behavior - but I'm a little reluctant to do so, partly because of my level of expertise with the language involved and partly because this is a one-time transition which I'd prefer not to carry an every-launch check for indefinitely. Still, if you have a strong preference in this regard, I can see what may be possible here - although that would increase the chance that we'd miss the start of the release freeze. I also remember being concerned about whether the updated daemon would correctly parse and handle an existing playlist file from the older daemon, or whether the file would need to be discarded across the upgrade, and I don't remember whether that concern turned out to be baseless or whether I specifically tested that scenario. I'll look for an opportunity to carry out such a test, but if you have access to disposable testing environments (e.g. VM snapshots), you might be in a better position to do so than I currently am. If it doesn't work seamlessly, that's not really catastrophic, since moosic playlist contents are ephemeral to begin with - but again, probably worth notifying the user about at upgrade time, so that the playlist file can be backed up prior to first launch of the new demon under a given user. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2020-12-23 at 02:08, Arto Jantunen wrote: > The Wanderer writes: >> I've decided it's worth the effort to become the new upstream for >> this, and confirmed with the original author that he has no >> objections, as he is no longer spending any time maintaining it. >> >> Version 1.5.7, based on Python 3 rather than Python 2, is now >> available from: >> >> https://github.com/inverseparadox/moosic >> >> Please consider packaging this version, if possible in time to meet >> the release freeze. >> Please let me know if there's anything I can do to help move this >> forward. > > You've done the big part of the work already. I'll try to take care > of updating the package as soon as I can, but due to commitments > related to the holiday season that will probably take a week or so. > That should still give us barely enough time before the freeze. I am *very* glad to hear that. After sending the above, I discovered that the package had in fact already been removed from both testing and unstable; I was starting to be concerned that it might need a full RFP / ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a problem and more time-consuming than I'd prefer to engage with at this stage. While obviously making the release freeze would be preferable, don't worry too much if you can't make that time-frame on your end; I'd still be happier with the package available in sid (or even experimental) than with it dropped entirely, even if it doesn't get shipped with the next release. > Thanks a lot for the work you did here. Thank *you* for picking this package back up, even with the upstream side already handled! My "if there's anything I can do to help" on this still stands, so long as I continue to have the time and other capacity to spare. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: not Python-3-compatible, so due for removal
retitle -1 moosic: new upstream version works with Python 3 thanks I've decided it's worth the effort to become the new upstream for this, and confirmed with the original author that he has no objections, as he is no longer spending any time maintaining it. Version 1.5.7, based on Python 3 rather than Python 2, is now available from: https://github.com/inverseparadox/moosic Please consider packaging this version, if possible in time to meet the release freeze. I have a private branch which includes a debian/ directory, and I have successfully built a Debian package from that branch which depends on Python 3 and appears to work. However, my ability to test such a thing in my available environments is limited, and I don't at all trust that I've gotten the packaging updates correct; all else being equal, I would prefer to rely on the existing Debian maintainer for that work. Please let me know if there's anything I can do to help move this forward.
Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings
On 2020-11-26 at 09:43, The Wanderer wrote: > Package: mariadb-client > Version: 1:10.5.8-3 > Severity: normal > > Dear Maintainer, > > I have just upgraded mariadb-client (and -server) from version 10.3.x to > version 10.5.8-3. As far as I can tell, no versions between those made > it into testing. If I'm not mistaken, the last version I was running > pre-upgrade was 10.3.24-2. > > Prior to the upgrade, in an interactive session within the 'mysql' > terminal-based client, Ctrl+W would kill everything to the left of the > cursor up to the first word boundary (which in practice appeared to mean > "whitespace"), but nothing to the left of that point. > > This is apparently not the default, but I have it configured in > ~/.editrc. The contents of that file are as follows: > > ---8<--- > bind "^U" vi-kill-line-prev > bind "^W" ed-delete-prev-word > ---8<--- > > Following the upgrade and a restart of the client, in such an > interactive session, Ctrl+W now kills everything to the left of the > cursor, all the way to the beginning of the line. This appears to be the > default behavior, used when no alternate configuration has been applied. > > It thus appears as if the settings I have in place in ~/.editrc are > simply being ignored. The environment variable EDITRC is not set. > Launching with it explicitly set does not appear to change anything. On further investigation, this might not be the full explanation after all. According to 'man editline', the ed-delete-prev-word function is bound by default to Ctrl+Meta+H. When I execute that key combination, it kills not up the preceding whitespace (as Ctrl+W used to do), but to the preceding word boundary (using what seems to be the same criteria as would be used by '\b' in a regular expression). https://certif.com/cplot_print/libedit.html and https://www.certif.com/spec_print/editline.html document the "kill until previous whitespace" functionality as being provided by em_kill_region. 'man editline' refers to em-kill-region, but states that it kills everything between the cursor and "the mark"; since the mark must be explicitly placed and omitting it means invoking this function is an error, that doesn't seem to be equivalent to "kill until previous whitespace". The latter of those pages documents the readline equivalent of ed-delete-prev-word as being backward-kill-word, and the one for "kill until previous whitspace" as being unix-word-rubout. I haven't found a way to readily test the behavior of these on my system yet, so I don't know for sure which if any of them provide the behavior I expected. I'm coming to suspect that there may be no way to regain access to the previous behavior without either severely patching libedit (either locally or upstream) or reverting to have mariadb-client use readline again instead. Either of those things would be drastic, but for this regression to be permanent would be quite unfortunate. Either way, the fact that ~/.editrc does not seem to be being respected is still an issue, which may or may not reside in mariadb-client. This additional discovery may simply mean that it was being ignored previously as well, I just hadn't noticed. I filed this as a bug report on account of regression, but it's starting to look like it might belong more in more general discussion channels for the time being, until the actual root nature of the regression can be figured out... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings
Package: mariadb-client Version: 1:10.5.8-3 Severity: normal Dear Maintainer, I have just upgraded mariadb-client (and -server) from version 10.3.x to version 10.5.8-3. As far as I can tell, no versions between those made it into testing. If I'm not mistaken, the last version I was running pre-upgrade was 10.3.24-2. Prior to the upgrade, in an interactive session within the 'mysql' terminal-based client, Ctrl+W would kill everything to the left of the cursor up to the first word boundary (which in practice appeared to mean "whitespace"), but nothing to the left of that point. This is apparently not the default, but I have it configured in ~/.editrc. The contents of that file are as follows: ---8<--- bind "^U" vi-kill-line-prev bind "^W" ed-delete-prev-word ---8<--- Following the upgrade and a restart of the client, in such an interactive session, Ctrl+W now kills everything to the left of the cursor, all the way to the beginning of the line. This appears to be the default behavior, used when no alternate configuration has been applied. It thus appears as if the settings I have in place in ~/.editrc are simply being ignored. The environment variable EDITRC is not set. Launching with it explicitly set does not appear to change anything. I've found this behavior mentioned in a few places online. Nearly all of them seem to advise resolving it by adding that Ctrl+W bind in ~/.editrc. The only one I've found thus far which indicates that doing so does not change the behavior is https://bugs.mysql.com/bug.php?id=95287 in which the solution found is to build with the internal libedit rather than the system copy, which is obviously not suitable for Debian. The only mentions of 'edit' in the relevant changelogs that I've found are in those for mariadb-client-core-10.5. Version 1:10.4.12-1~exp2 has an entry for "Link with libedit instead of readline5", and version 1:10.5.5-2 has one for "Add native dependencies on gnutls, libedit and ncurses" (in relation to cross-compiling). I'd guess that the former is the more relevant of the two, but I don't know for sure. The installed version of libedit2 is 3.1-20191231-1. Based on the date, I doubt that it was recently upgraded from an earlier version, but I cannot testify to that for certain. The only mention of ~/.editrc being ignored that I've managed to find yet is a question on superuser.com from 2010, regarding ghci, which got no answer. I'm not sure whether the bug here is in mariadb-client or in libedit, or even somewhere else, but this is clearly a behavior regression. If the existing configuration through this file is supposed to continue to be respected after the upgrade, please make appropriate adjustments so that that happens. If it is not, please explain and document what the correct method is for applying such configuration. If there is anything I can do to help track this down and get it working, please let me know. I've tried strace, but failed to find anything relevant thus far in the result; in particular, I find no mention of the string 'editrc', although libedit.so.2 is apparently read. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mariadb-client depends on: ii mariadb-client-10.5 1:10.5.8-3 mariadb-client recommends no packages. mariadb-client suggests no packages. -- no debconf information
Bug#970635: moosic: not Python-3-compatible, so due for removal
I've done some more digging, and it looks like the delay isn't related to the new version, or to moosic at all. It happens only with WAV files played by sox; my best guess is that it's a matter of how sox handles things internally, such that when it gets SIGSTOP or suchlike it (I imagine) lets a buffer run empty before fully stopping. While investigating that, I also ran into two intermittent problems with the unpause command (and various related commands): one that occurs only with ogg123, and one that so far occurs only with MPlayer (which isn't used in the default moosic config). The latter isn't strictly moosic's problem, and I don't see anything moosic can do about it; the former isn't either, but moosic can avoid it by changing the way it handles sending SIGCONT when the target process is ogg123, so I've added a patch that does that. I haven't provided it here, since it's not related to the Python 3 transition, but it can follow later separately if appropriate. At least the MPlayer-related problem has been confirmed, with testing, to also occur with the existing 1.5.6 Python 2 version of moosic. From my understanding of the other two problems, I fully expect them to occur there as well. As best I can determine, none of them are new issues. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On 2020-09-10 at 01:45, Tobias Frost wrote: > On Wed, Sep 09, 2020 at 10:53:37PM +0200, Alec Leamas wrote: >> Hi, >> >> A new version is uploaded to mentors. Time to reset the history. Changes >> since last round: >> >> - New warning dialog for downloading binary plugin content (patch). >> - Spelling error fixed >> - Removed references to upstream bugs. I think it's a pity, the >> references linked patches in d/patches to upstream bugs. > > Well, actually, all those lines probably should be removed: > debian/changelog is intended to record changes to the packaging part > only, it is not to record changes made upstream; more generally: Only > stuff that changes files in the debian directory should be mentioned > in d/changelog. (See > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > for some better/more accurate wording in the Policy) I'm not sure I read that section as meaning that. Could you point more specifically to the exact wording there which you understand as reflecting this rule? Regardless, I'm fairly sure there are exceptions to this in practice. For example, if a new upstream release includes a change which closes an open Debian bug report or fixes a particular CVE, a notation in the changelog recording that fact seems to be de rigueur, and in fact as I understand matters the tooling recognizes and parses notes such as "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug report or to mark a newly-packaged version as unaffected by the given CVE. For that matter, look at the Linux kernel packages (linux-image-VERSION-ARCH, among others). They don't seem to ship a changelog.Debian.gz, but the changelog.gz which they do ship seems to be in Debian changelog form and list Debian package versions, and is reported by apt-listchanges at upgrade time; in that file, each new Debian version tends to contain a "New upstream stable update" entry, which is then followed by a kernel changelog URL and a lengthy, detailed listing of changes (apparently nearly commit-level) taken from that upstream changelog. I'm not sure this is best practice, or that it would be a good thing for other packages to be doing en masse - but it's a large-scale example of including upstream changes in debian/changelog, and it certainly doesn't seem to be an unacceptable violation if something as core as the kernel packages have been doing it for so long and are still going that way. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#968442: dpkg: "compressed data is corrupt" while unpacking locales-all
On 2020-08-25 at 05:34, Guillem Jover wrote: > Hi! > > On Sat, 2020-08-15 at 07:29:42 -0400, The Wanderer wrote: >> During a routine 'apt-get dist-upgrade' against testing, I got (in >> part): >> After this, a run of 'apt-get -f install' did not appear to act on >> the locales-all package, and did not fail. A subsequent repeat of >> the dist-upgrade command saw locales-all as the only package >> available to be upgraded, and proceeding let it upgrade without a >> repeat of the error. > > Did the subsequent upgrade download the package again? If so the > local one could have been damaged, but a redownload would have fixed > that. I do not recall noticing it doing so, but I cannot swear that it didn't. Unfortunately, I no longer have access to the relevant backscroll to check, and the only log file which looks as if it should perhaps record such (/var/log/apt/term.log) seems in fact to only record the terminal output from after the download process would have completed. > If you do not have access to the supposedly "faulty" package as it > was just after the dpkg error, then I'm not sure there is much we can > do at this point though. :/ Quite possibly not. I'll keep that thought in mind in case a similar problem recurs at some later point, but there may indeed not be anything we can do about it now. > I'm not sure if this could be related to some recent fixes in apt > where it previously was not fully fetching all data from remote > sites. > > What I can do though, is add a bit more information to the error > message, such as the .deb name and size, so that if the file had been > truncated then we'd be able to immediately know. Ideally a checksum > would also be printed but hmmm. That could indeed be useful in the event of a recurrence. Regardless, I do appreciate the attention you're giving to this! -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#968442: dpkg: "compressed data is corrupt" while unpacking locales-all
Package: dpkg Version: 1.20.5 Severity: normal Dear Maintainer, During a routine 'apt-get dist-upgrade' against testing, I got (in part): Preparing to unpack .../73-locales-all_2.31-3_amd64.deb ... Unpacking locales-all (2.31-3) over (2.31-2) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-EMKBka/73-locales-all_2.31-3_amd64.deb (--unpack): cannot copy extracted data for './usr/lib/locale/ja_JP.eucjp/LC_CTYPE' to '/usr/lib/locale/ja_JP.eucjp/LC_CTYPE.dpkg-new': unexpected end of file or stream ... Errors were encountered while processing: /tmp/apt-dpkg-install-EMKBka/73-locales-all_2.31-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) After this, a run of 'apt-get -f install' did not appear to act on the locales-all package, and did not fail. A subsequent repeat of the dist-upgrade command saw locales-all as the only package available to be upgraded, and proceeding let it upgrade without a repeat of the error. I have not thus far found anything elsewhere in the system (e.g. dmesg, for underlying disk errors) which might explain why this unexpected EOF occurred. I am not at all sure which package might be responsible for this; locales-all (and thus glibc) is a possibility, but at a glance I think this looks more like a dpkg issue, and I can't rule out that it's something else entirely. Please feel free to reassign - or, if e.g. this is likely a one-off local error which is not likely to recur for others, close - as you see fit. At least at the moment, I can no longer reproduce this failure, but just in case it isn't a one-off I didn't want to let it go unreported. As usual, if there is any information I can provide to help track this down, don't hesitate to ask. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-3 ii liblzma5 5.2.4-1+b1 ii libselinux1 3.1-2 ii tar 1.30+dfsg-7 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.1.10 pn debsig-verify -- no debconf information
Bug#968397: dpkg: package bug script exits with 256 on reportbug
On 2020-08-14 at 14:15, Guillem Jover wrote: > Control: found -1 1.20.1 > > Hi! > > On Fri, 2020-08-14 at 10:00:23 -0400, The Wanderer wrote: >> Package: dpkg >> Version: 1.20.5 >> Severity: normal > >> When I attempt to file a bug report against dpkg with reportbug, I get >> the following output: >> >> >> The package bug script /usr/share/bug/dpkg exited with an error status >> (return code = 256). Do you still want to file a report? [y|N|q|?]? > > Oh, so I guess this is due to you not having a tainted usr-merged system Correct. > and the readlink failing, due to some recent refactoring. I'll fix that. I wasn't aware that there had been recent changes in that area; that would explain it. Thank you for your prompt attention to this. >> It is not clear whether this reflects a problem that will manifest >> itself in the resulting bug report, but at the minimum, it is clearly >> suboptimal UX. If it does reflect a real problem, that problem should be >> fixed; if it does not, it should be streamlined so that this notice does >> not appear in routine bug-report attempts. > > This would be reportbug noticing that the bug script failed and > reporting that. Yeah - the "this" to which I was referring is more the fact that the bug script failed, and the possibility that that might mean the bug report wouldn't have all the data the maintainers would be expecting to receive. On deeper examination, this latter seems unlikely, at least for this particular bug script. >> As things stand, I have another bug report which I would like to file >> (which might belong either to dpkg or to locales-all, or even somewhere >> else I can't identify at a glance, but I think fits dpkg as the most >> likely candidate) which is on hold because of this. > > I assume that until the problem has been fixed in the bug-script, just > replying 'y' would do. Given the above, I concur, and will follow up appropriately. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#968397: dpkg: package bug script exits with 256 on reportbug
Package: dpkg Version: 1.20.5 Severity: normal Dear Maintainer, When I attempt to file a bug report against dpkg with reportbug, I get the following output: The package bug script /usr/share/bug/dpkg exited with an error status (return code = 256). Do you still want to file a report? [y|N|q|?]? It is not clear whether this reflects a problem that will manifest itself in the resulting bug report, but at the minimum, it is clearly suboptimal UX. If it does reflect a real problem, that problem should be fixed; if it does not, it should be streamlined so that this notice does not appear in routine bug-report attempts. As things stand, I have another bug report which I would like to file (which might belong either to dpkg or to locales-all, or even somewhere else I can't identify at a glance, but I think fits dpkg as the most likely candidate) which is on hold because of this. I'm not sure where to look on my system for anything that might be contributing to the problem; I've already checked the script itself, and tried running various commands and scripts based on what I find there, without reproducing the 256 exit code as of yet. If there's anything I can do to help track this down, don't hesitate to ask. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-3 ii liblzma5 5.2.4-1+b1 ii libselinux1 3.1-2 ii tar 1.30+dfsg-7 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.1.10 pn debsig-verify -- no debconf information
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 12:51, Joan Moreau wrote: > An additional question : I still do not understand why, if this is a > "source" package, the source (and the Makefile) does not get included > ? > > Am I missing something ? The .deb is not a source package. A .deb is a binary package. Earlier in this thread, you were linked to https://wiki.debian.org/Packaging/SourcePackage, which should define the term "source package" in detail and with clarity. Have you read through that page? In addition to that page, I do recommend that you take the time to read through at least https://mentors.debian.net/intro-maintainers and https://www.debian.org/doc/manuals/maint-guide/index.html, at length and in detail, before trying to proceed with package creation much further. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 12:26, Joan Moreau wrote: > Ok, I tried to put a Makefile that import all needed packages > dynamically (via "git clone" mostly) Sorry - accessing the network during compilation is (at least generally) prohibited. IIRC, it both is a violation of Debian policy, and may actually not work from the build environment on the servers. You need to arrange for the relevant code to already be present prior to the start of the compilation process. > You may check > https://github.com/grosjo/tomboy-reborn/blob/master/packages/tomboy-reborn_1.0.0-1_amd64.deb That's a .deb file, which is a binary package. We need to look at the updated source package, which is used for generating the binary package. Looking at https://github.com/grosjo/tomboy-reborn, and more specifically at https://github.com/grosjo/tomboy-reborn/blob/master/packages/Makefile, I see that you're cloning two git repositories. If the software in those repositories is already packaged for Debian, you need to find out which packages it's in, add them as build-dependencies (as defined in some of the documents you've previously been linked to), and adjust your project (possibly through flags in the Makefile or appropriate setup in debian/rules) to draw on the files installed by those packages. If the software in those repositories is not already packaged for Debian, then unless an exception is allowed for, you need to get it packaged - into separate packages, not into the one you're already working on - and then do the above. If compiling your project needs the code from these repositories, how does your IDE-based build normally pick up that code? I'd expect that the same process should work for a command-line build, but I'll admit that I'm not familiar with Lazarus. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 10:54, The Wanderer wrote: > In order for this to be included in Debian, the final package build > - after all testing and tweaking to make sure things work properly - > will need to take place on the Debian build-daemon servers (AKA the > buildds), with no user interaction whatsoever. To clarify this somewhat: After all the preparatory work is done to get your package ready for inclusion, what will happen is that a copy of your source package will be uploaded to the Debian servers. Those servers will then automatically initiate the package-build process. This process will need to compile your program from source, then build the binary package (that is, the .deb file) from the result. There is not, and cannot be, any human involvement in this sequence. At most, if any part of the build fails, a human can modify the source package and upload it to be tried again. As such, anything other than a fully-automated compilation and package-building process is not going to wind up being included in Debian. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-05 at 10:31, Joan Moreau wrote: > Hi > > The lazbuild is commented because this does not work properly from > console, one shall use lazarus IDE in order to compile the sources > properly, and according to its architecture. Can the IDE be triggered to do this from the command line, so that the process can work without interaction from the user? If not, then this cannot be used to compile a program for a Debian package. The package-build process must be able to start with the uncompiled sources (with no IDE or similar already open) and end up with the compiled program, with no user interaction at all, beyond single command-line invocation which starts the whole process. This basically always requires a command-line compilation method. In order for this to be included in Debian, the final package build - after all testing and tweaking to make sure things work properly - will need to take place on the Debian build-daemon servers (AKA the buildds), with no user interaction whatsoever. I would not be surprised if those servers don't have a graphical environment available, such that a graphical IDE may not even be able to launch. I really do think that what you'll probably need to do is figure out what's going wrong with the lazbuild result and fix it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy
On 2020-07-04 at 11:28, Boyuan Yang wrote: > In your case, I do not see any build system in your source code > repository. There is a built binary file but there's no script or > instructions describing how the built binary was generated. I have > absolutely no idea how you were building the Pascal source code into > binaries. My best guess is that you are using the building function > embedded in Lazarus IDE -- which is completely unacceptable since a > working build system should be fully automated and require no > graphical IDE tool to function well. For what it's worth, there appears to exist a tool called 'lazbuild', which is apparently supposed to be able to compile a program from the command line if passed the appropriate Lazarus project file. I find two different versions of it in Debian, both in the lcl-utils-2.0 package. Also, https://forum.lazarus.freepascal.org/index.php?topic=37272.0 involves people talking about how to build a Lazarus project from the command line; they appear to have gotten it working without the use of lazbuild in at least one case, but whether that's worth the effort I don't know. If that's viable, there may not be any need to add a separate build system, although there would still be a need to add appropriate how-to-build documentation and (of course) the necessary debian/rules glue to get it to be run at package-build time. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#962078: apt-listchanges: feature request: combine identical changelog entries from multiple packages
Package: apt-listchanges Version: 3.22 Severity: wishlist Dear Maintainer, >From my perspective, this is technically not a new bug report; it is another part of the wishlist item reported as bug #841837, which was not addressed by the change which led that bug report to be closed. The change made under that bug report resulted in identical binNMU entries being folded together, and listed with one entry per identical changelog, at the end of the list. This is a major improvement, and addresses the large majority of cases where such identical entries made change lists hard to read. However, as mentioned in that wishlist bug report, binNMUs are not the only context in which substantially-identical changelogs occur: > (At the moment, I am also seeing a mass set of identical entries in > an apparently maintainer-initiated update to set of KDE-related > packages; a couple of dozen or so packages seem to have been updated > simultaneously to the same version, with identical or near-identical > changes in each. This sort of issue thus is not exclusive to such > automatic rebuilds, it's just most common there.) I am once again seeing this, albeit at a smaller scale, with a mass update to KDE-related packages. Specifically (although I cannot guarantee that this is the full set of affected packages, without spending more time on analyzing each changelog entry than I want to invest), kcrash, kdbusaddons, and kemoticons have changelog entries for version 5.70.0-1 which differ only in the package name and the exact timestamp. (Some other packages involved in the same mass update seem to include a changelog section for that version which is identical to the one from the packages named, but also have an additional changelog section for the same version to describe other changes which are specific to each package. Otherwise, there would probably be closer to a dozen packages which I could easily list. Splitting out such identical sections from otherwise-differing changelog entries would clearly do more harm than good.) Part of the request made under that bug report was for all such identical changelog entries to be folded together, much (if not necessarily exactly) as is now done with binNMUs; whether the identical changelog entries result from binNMUs or from something else is not relevant to that purpose. Please either extend the current binNMU folding to catch other types of identical changelog entries and treat them similarly, or add an additional feature (possibly requiring enablement via an option) to cause such additional identical entries to be folded together in a similar way. (I can easily see that this may be a less commonly desired behavior, and that indeed some people may prefer to have it not happen, given that it would break up the orderly listing of package versions in cases where other versions' changelog entries to the same packages are not similarly identical. As such, making this an optional behavior which has to be enabled would probably be more appropriate than making it the default.) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt2.1.5 ii debconf [debconf-2.0] 1.5.74 ii python33.8.2-3 ii python3-apt2.1.3 ii python3-debconf1.5.74 ii sensible-utils 0.0.12+nmu1 ii ucf3.0042 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 81.0.4044.92-1 ii dillo [www-browser]3.0.5-7 ii elinks [www-browser] 0.13.1-4 ii exim4-daemon-light [mail-transport-agent] 4.93-16 ii iceweasel [www-browser]38.8.0esr-1~deb8u1 ii kterm [x-terminal-emulator]6.2.0-46.2 ii links [www-browser]2.20.2-1+b1 ii lynx [www-browser] 2.9.0dev.5-1 ii python3-gi 3.36.0-3 ii w3m [www-browser] 0.5.3-38 ii xterm [x-terminal-emulator]356-1 -- debconf information: * apt-listchanges/save-seen: true * apt-listchanges/which: both * apt-listchanges/email-format: text * apt-listchanges/email-address: root * apt-listchanges/reverse: false * apt-listchanges/no-network: false * apt-listchanges/frontend: pager * apt-listchanges/headers: false * apt-listchanges/confirm: true
Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137
On 2020-05-05 at 16:05, Tollef Fog Heen wrote: > ]] The Wanderer > >> I'm not at all sure whether the underlying cause is still the same, >> but I'm getting a very similar-looking failure - albeit with >> different BUG details - after a reboot a few nights ago into a new >> kernel. > > My understanding is that when you get one of those, it indicates a > kernel problem, isn't that so? If so, it should probably just be > reassigned to linux. That's entirely possible, and I wouldn't object if that happens. That said, in my case I'm now reasonably certain that the proximate underlying cause is misbehaving (either buggy, or outright starting to fail) storage-related hardware, as touched on at the end of my initial comment. After the RAID-array check completed that evening, I ran /etc/cron.daily/mlocate by hand (as root), and the I/O freeze from overdoing writes that I mentioned was triggered; the system kept running for a few hours, but the gkrellm clock froze at one second to midnight, and the system hadn't recovered by 6:30 the next morning. A hard power-cycle and a full manual fsck (including fixing several errors on one partition) got things working again, with no sign of current problems. I haven't retried explicitly initiating the process again, but it's been long enough that it would have run on its own, and nothing seems to have gone awry. The kernel probably still shouldn't BUG when this happens, but I don't know how far it's reasonable to expect the kernel to go to avoid such problems, and it's useful to get the notification of what's happened / hung under the hood - so I wouldn't be too fussed if the kernel people just declined this as being outside of their scope. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137
On 2020-05-03 at 10:34, The Wanderer wrote: > I'm not at all sure whether the underlying cause is still the same, but > I'm getting a very similar-looking failure - albeit with different BUG > details - after a reboot a few nights ago into a new kernel. Blast. I forgot to specify: $ uname -a Linux obfuscated 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) x86_64 GNU/Linux $ apt-cache policy mlocate mlocate: Installed: 0.26-3+b1 Candidate: 0.26-3+b1 Version table: *** 0.26-3+b1 900 900 http://ftp.us.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 0.26-3 800 800 http://ftp.us.debian.org/debian stable/main amd64 Packages Other version details available on request. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137
0078 [204955.926760] R13: 7ffc09560630 R14: R15: [204955.926761] Modules linked in: tun ufs qnx4 hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 bnep bluetooth drbg ansi_cprng ecdh_generic ecc rfkill binfmt_misc fuse nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc w83627ehf hwmon_vid loop firewire_sbp2 parport_pc ppdev lp parport intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul ghash_clmulni_intel radeon snd_usb_audio snd_hda_codec_realtek snd_hda_codec_generic snd_usbmidi_lib ledtrig_audio snd_hda_codec_hdmi ttm snd_virtuoso snd_hda_intel aesni_intel snd_intel_dspcfg snd_oxygen_lib snd_hda_codec snd_mpu401_uart crypto_simd cryptd snd_rawmidi glue_helper drm_kms_helper snd_hda_core mc snd_seq_device snd_hwdep snd_pcm_oss intel_cstate snd_mixer_oss serio_raw pcspkr snd_pcm intel_uncore drm joydev evdev mxm_wmi snd_timer iTCO_wdt iTCO_vendor_support watchdog snd soundcore i2c_algo_bit i7core_edac sg i5500_temp button acpi_cpufreq ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_decompress zstd_compress dm_mod raid10 [204955.926790] raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 md_mod sd_mod hid_generic sr_mod cdrom usbhid hid crc32_pclmul r8169 ahci xhci_pci realtek uhci_hcd libahci xhci_hcd ehci_pci crc32c_intel firewire_ohci libphy libata ehci_hcd psmouse firewire_core crc_itu_t usbcore lpc_ich mfd_core scsi_mod i2c_i801 usb_common wmi [204955.926804] CR2: 97693740 [204955.926806] ---[ end trace ff3d7f0c82e84c49 ]--- I can't guarantee that there isn't a hardware problem in the SATA controller on this system, but if so it doesn't seem to have previously manifested in any other way than intermittently making POST take several times longer than it normally should. (This does not happen every time, and it didn't happen at the most recent boot; IIRC, it happens most frequently when not performing a cold boot, i.e. one after letting the system sit unpowered for a while.) (Well, I do have past experience indicating that if I do sustained write I/O on this array for too long, it stops responding to writes until I reboot, though I think reads remain fine. That said, I only encountered that when doing mass replication of large parts of the Debian package archive, and adding enough sleeps into the middle of the process made it stop happening. IIRC, I found indication at the time that this was a known kernel bug that was fixed in a newer version, and I've already upgraded well past that version.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Bug#954875: Seems needed for YouTube now
As of today, I'm getting the following error when attempting to download
any YouTube video I've tried:
$ youtube-dl 'https://www.youtube.com/watch?v=qxXZF60EPdM'
[youtube] qxXZF60EPdM: Downloading webpage
[youtube] qxXZF60EPdM: Downloading video info webpage
ERROR: Signature extraction failed: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1384, in _decrypt_signature
func = self._extract_signature_function(
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1262, in _extract_signature_function
raise ExtractorError('Cannot identify player %r' % player_url)
youtube_dl.utils.ExtractorError: Cannot identify player
'https://www.youtube.com/s/player/4fbb4d5b/player_ias.vflset/en_US/base.js';
please report this issue on https://yt-dl.org/bug . Make sure you are
using the latest version; see https://yt-dl.org/update on how to
update. Be sure to call youtube-dl with the --verbose flag and include
its complete output.
(caused by ExtractorError("Cannot identify player
'https://www.youtube.com/s/player/4fbb4d5b/player_ias.vflset/en_US/base.js';
please report this issue on https://yt-dl.org/bug . Make sure you are
using the latest version; see https://yt-dl.org/update on how to
update. Be sure to call youtube-dl with the --verbose flag and include
its complete output.")); please report this issue on
https://yt-dl.org/bug . Make sure you are using the latest version; see
https://yt-dl.org/update on how to update. Be sure to call youtube-dl
with the --verbose flag and include its complete output.
In the case of this particular video, I was able to successfully
download it with this exact same command sometime within the past week.
The most obvious conclusion would seem to be that YouTube has changed
their formats recently, and an updated extractor is required.
I have tried with the version available via wget from
https://yt-dl.org/downloads/latest/youtube-dl, and that version
downloads the video is without apparent issues. I don't see anything in
the recent commits on GitHub which seems like it might affect this, but
clearly there must have been something. (Unless something else has
caused the version installed on my system to break.)
If this is happening for other people too, then getting this updated is
probably more urgent, and this should probably go from "wishlist" to
"important".
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Bug#946840: libsmbclient-dev: libsmbclient.h: field *_ts has incomplete type
Package: libsmbclient-dev Version: 2:4.11.1+dfsg-3 Severity: important Tags: patch upstream Dear Maintainer, When I attempt to compile FFmpeg from current git HEAD with the '--enable-libsmbclient' configure flag, detection of libsmbclient fails with the following errors: ---8<--- In file included from /tmp/ffconf.29iCgpHh/test.c:1: /usr/include/samba-4.0/libsmbclient.h:168:18: error: field 'btime_ts' has incomplete type 168 | struct timespec btime_ts; | ^~~~ /usr/include/samba-4.0/libsmbclient.h:172:18: error: field 'mtime_ts' has incomplete type 172 | struct timespec mtime_ts; | ^~~~ /usr/include/samba-4.0/libsmbclient.h:176:18: error: field 'atime_ts' has incomplete type 176 | struct timespec atime_ts; | ^~~~ /usr/include/samba-4.0/libsmbclient.h:180:18: error: field 'ctime_ts' has incomplete type 180 | struct timespec ctime_ts; | ^~~~ /usr/include/samba-4.0/libsmbclient.h:1134:38: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration 1134 | struct timeval *tbuf); | ^~~ /usr/include/samba-4.0/libsmbclient.h:1953:41: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration 1953 | int smbc_utimes(const char *url, struct timeval *tbuf); | ---8<--- This appears to have been discussed upstream in late 2018 (both on a samba-related mailing list and on a GitHub pull request, https://github.com/samba-team/samba/pull/212), but although the patch provided there for fixing the problem was acknowledged, it does not seem to have been committed. The issue seems to be simply a failure to include time.h in libsmbclient.h. https://github.com/samba-team/samba/pull/212/commits/11e8c14b78e2423041f3846882f74cd6490a3e44 is the patch; if it would help for me to do the work of extracting that into an apply-able diff, I can certainly do so. If I apply this patch to my local copy of libsmbclient.h, detection passes, the build completes, and the resulting binary appears to be usable. (Although I am currently in a position to test its SMB-related functionality.) Please apply this patch, and/or check with upstream about getting them to do so. Alternatively, if there is some reason why including time.h here would be inappropriate (e.g. a documented requirement that users of this API do so themselves), please indicate where to find a clear indication of that fact so that I can take that to the FFmpeg developers. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libsmbclient-dev depends on: ii dpkg 1.19.7 ii libsmbclient 2:4.11.1+dfsg-3 libsmbclient-dev recommends no packages. libsmbclient-dev suggests no packages. -- no debconf information
Bug#946700: apt-listchanges: mail notifying of changes has (MIME-?) garbled Subject line
Package: apt-listchanges Version: 3.21 Severity: minor (I have a vague memory that I have reported this once before, but I am not having any luck finding any record of such a report, so I'm filing this again.) Dear Maintainer, First, for background: When I install package updates via apt-get (which is usually at least once a week, on average), apt-listchanges sends a mail to root containing the changelogs which were displayed prior to the final confirmation prompt for that upgrade session. For reasons which make sense but which I have not bothered to track down, when mail is sent to root, it shows up in the pending local mail queue for my non-root local account, which is named wanderer. Whenever a new message has arrived in that queue, every time a command I initiate from a console or terminal exits, that terminal reports a message along the lines of "You have new mail.". This happens once per terminal, meaning that if I don't clear the pending mail, I get that notification repeatedly. In order to prevent that, I habitually read the mail (thus transferring it from that queue into ~/.mbox) immediately after confirming the update session. The only mail client which I have configured to read from this local mail queue is the one invoked by the command 'mail', which in my (AFAIK, default) configuration is bsd-mailx, which is installed at version 8.1.2-0.20180807cvs-1+b1. All of the above is normal and expected, and I do not consider it a problem. The actual problem I'm reporting is that when I do this, the Subject line of the mail which is sent by apt-listchanges appears in a garbled form. For example (and I'm not entirely positive this won't be line-wrapped): ---8<--- $ mail Mail version 8.1.2 01/15/2001. Type ? for help. "/var/mail/wanderer": 1 message 1 new >N 1 r...@apologia.fra Fri Dec 13 18:40 318/10860 =?utf-8?q?apt-listchanges=3A_changelogs_for_apologia?= & ---8<--- If I'm understanding matters correctly, this garbling is actually MIME character encoding. This was not always the case. Back in the day, these mails would have un-garbled Subject lines, more along the lines of 'apt-listchanges: changelogs for apologia'. This is the behavior I would have preferred to see continue, and would like to see return. The final mail I have in my archive with this older, non-garbled form is dated 2016-08-21, and includes the NEWS entry for installing apt-listchanges version 3.3. The changes summarized in that entry include migrating the package to python3; I suspect, but am not certain, that this may be the relevant change. The first mail I have with this garbled form is dated 2016-08-26. I did not report this initially because I assumed that it would be noticed and corrected in short order. After that, I more or less got used to ignoring the issue, but as it's still suboptimal I'm now finally reporting it. If mail clients are not expected to be able to consume this format and present correctly-formatted Subject lines for user viewing, then apt-listchanges should not be emitting this format, but should emit the bare-text Subject line just as was apparently done prior to the 3.x version series. If mail clients are expected to be able to consume this format and present correctly-formatted Subject lines for user viewing, then the fact that the apparently-default local-queue mail client in a Debian environment presents this 'garbled' form would seem to be a bug either in that client or in the choice of default local-queue mail client, and this bug should be reassigned appropriately. Although I do not have immediate access to confirm this, I believe that I have seen this behavior happen on at least two machines (with at least slightly different configurations), so I don't think it's likely to be a purely local problem. If there's anything I can do to help track this down and get this behavior corrected, please let me know. In particular, if knowing everything that was upgraded in that upgrade session would be helpful, I can provide a copy of the exact changelog mail from that upgrade session. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt1.8.4 ii debconf [debconf-2.0] 1.5.73 ii python33.7.5-1 ii python3-apt1.8.4+b1 ii python3-debconf1.5.73 ii sensible-utils 0.0.12+nmu1 ii ucf3.0038+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 78.0.
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
On 2019-09-16 at 11:38, Andreas Tille wrote: > Control: tags -1 pending > > Hi, > > I wanted to upgrade to the latest upstream version in Git[1] where > upstream has changed the build system. Its a bit irritating to use > meson on top of cmake (at least I have never seen this before) and I > think I have added all needed Build-Depends (locally - not commited > yet): > > > diff --git a/debian/control b/debian/control > index b4d7424..c5a11fd 100644 > --- a/debian/control > +++ b/debian/control > @@ -5,6 +5,10 @@ Section: libs > Priority: optional > Build-Depends: debhelper-compat (= 12), > dh-exec, > + meson, > + pkg-config, > + cmake, > + googletest, > zlib1g-dev, > libhdf5-dev, > libboost-dev, > > > Despite I have added googletest it seems not be found: > > > Library rt found: YES > Configuring LibBlasrConfig.h using configuration > Program tools/check-formatting found: YES > (/build/pbseqlib-5.3.3+dfsg/tools/check-formatting) > Pkg-config binary for MachineChoice.HOST is cached. > Determining dependency 'gtest_main' with pkg-config executable > '/usr/bin/pkg-config' > PKG_CONFIG_PATH: > Called `/usr/bin/pkg-config --modversion gtest_main` -> 1 > > CMake binary for MachineChoice.HOST is not cached > CMake binary missing from cross or native file, or env var undefined. > Trying a default CMake fallback at cmake > Trying CMake binary cmake for machine MachineChoice.HOST at ['/usr/bin/cmake'] > Found CMake: /usr/bin/cmake (3.13.4) > Extracting basic cmake information > Try CMake generator: auto > Called `/usr/bin/cmake --trace-expand .` in > /build/pbseqlib-5.3.3+dfsg/obj-x86_64-linux-gnu/meson-private/cmake_gtest_main > -> 0 > -- Module search paths:['/', '/opt', '/usr', '/usr/local'] > -- CMake root: /usr/share/cmake-3.13 > -- CMake architectures:['x86_64-linux-gnu'] > -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share', > 'lib/x86_64-linux-gnu'] > Run-time dependency gtest_main found: NO (tried pkgconfig and cmake) > Looking for a fallback subproject for the dependency gtest_main > > unittest/meson.build:14:0: ERROR: Automatic wrap-based subproject downloading > is disabled > > > > I also tried adding libgtest-dev in addition but this does not change > the situation. > > Any hint, what to do? I'm not remotely an expert on any of the tools, systems, or packages involved, but one thing I notice is that googletest doesn't seem to install an actual .pc file, just a .pc.in: $ dlocate gtest.*.pc googletest:amd64: /usr/src/googletest/googletest/cmake/gtest.pc.in googletest:amd64: /usr/src/googletest/googletest/cmake/gtest_main.pc.in (And similar lack of suitable results from apt-file search, et cetera.) The googletest package description says that it "does not contain a library to link against, but rather the source code to build the google test and mock libraries" (which fits with the fact that it isn't a lib* package). Typically the .pc file would be in the lib*-dev package, but in this case, since there isn't a matching lib* package to install, I can easily see why that might not make sense to do. (If it would, this would probably be a wishlist item for the googletest package maintainers.) /usr/share/doc/googletest/README.Debian states that >> The Google C++ Testing Framework uses conditional compilation for >> some things. Because of the C++ "One Definition Rule", gtest and >> gmock must be compiled with exactly the same flags as your C++ >> code under test. Because this is hard to manage, upstream no >> longer recommends using precompiled libraries [1]. >> [1] >> http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d and that >> If your build system uses CMake, the ExternalProject command can >> be used to build gtest, then FindGTest can be used to find the >> built library. Clearly you need to build gtest before it can be picked up; this might give some indication of how to go about doing so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#935177: liblcms2-dev:i386: error overwriting src.zip on package upgrade
I've extracted the two .deb files and compared the results. The only different file between the two (with the same name and path) is indeed src.zip. Extracting the two src.zip files and comparing the result with 'diff -rq' shows no differences, but examining the directory listings shows different timestamps; that file contains three RTF files (apparently API documentation, et cetera, not actual source), and they're timestamped four minutes apart, on the date of the automated binNMU rebuild carried out on the buildd. Similar timestamp differences exist in other files in the two .debs. I'm guessing that perhaps the necessary differences in the ZIP file to record the different timestamps are what is causing this failure. Comparing the two ZIP files with vbindiff shows a total of six bytes different, scattered across the file; they are all a change between 0xA3 and 0x25. If each file's timestamp is recorded in two places in the file, that could fit with these being timestamps; I'm not sure how a difference of four minutes could result in a timestamp difference of 0x7E (126), but I can imagine I just haven't thought it through all the way. Do the files in these two ZIPs really need to be compressed? If so, is there a way to generate the files differently so that they don't get different timestamps? If not, is there a way to do the compression differently such that the timestamps don't get recorded in the compressed file? /usr/share/doc/liblcms2-dev/changelog.Debian.amd64.gz contains only one entry, that from this most recent binNMU; I suspect that the analogous i386 version would be the same. I'm guessing that this type of mismatch would happen any time this package in its current form gets built on the buildds (as I believe is now required, with the change to source-only uploads?), and that this is simply the first time such a thing has happened. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#911148: kildclient: mouseover timestamp balloon disappears instantly
Package: kildclient Version: 3.2.0-2 Severity: minor Dear Maintainer, One of the features of KildClient is that, when I hover the mouse pointer over a line of text in the scrollback buffer for about a second or so, a small "text balloon" will appear showing information about the line - most prominently, a timestamp of when it arrived. Since my most recent restart of KildClient (following a power-loss reboot, following quite a few package upgrades over the course of weeks without a client restart), this balloon now disappears after well under a second, then reappears again after little if any more time than that, and the pattern repeats - resulting in a "flickering" behavior, in which the balloon is visible for such a short period that it is difficult if not impossible to read the contents of the balloon. What's more, if I have the focus in another window at the time when this "the balloon disappears" behavior happens, the focus changes to KildClient. (However, KildClient is not brought to the foreground.) That latter behavior seems as if it could be conditional on particular window-manager focus settings. I run e16, currently version 10.0.15.000 (self-compiled), with the setting "focus follows pointer sloppily". I suspect that this is probably not actually a problem in KildClient, but in one of the GTK libraries; I think that KildClient is the only GTK3 program I currently use which has this type of mouseover-causes-balloon feature. However, as I am not sufficiently familiar with GTK to even begin narrowing it down, and none of the existing bug reports against the immediate GTK-related dependency library (libgtk-3-0) seem related at a quick scan-through, I think it may be more useful to report the bug where I'm observing it. If the bug needs to be reassigned elsewhere, I fully approve of that happening. If a separate bug report (to pick up additional system information) against a different package is needed, I can do that too, as long as I know which package and in what terms to couch the report. If there is anything I can do to help narrow this down and/or resolve it, please do not hesitate to let me know. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages kildclient depends on: ii desktop-file-utils 0.23-4 ii libc6 2.27-6 ii libglib2.0-02.58.1-2 ii libgnutls30 3.5.19-1 ii libgtk-3-0 3.24.1-2 ii libgtkspell3-3-03.0.9-2 ii libjson-perl2.97001-1 ii libpango-1.0-0 1.42.4-3 ii libperl5.26 5.26.2-7+b1 ii zlib1g 1:1.2.11.dfsg-1 kildclient recommends no packages. Versions of packages kildclient suggests: ii kildclient-doc 3.2.0-2 pn libgtk3-perl -- debconf-show failed
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
On 2018-02-26 at 14:55, Ben Hutchings wrote: > On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote: >> If the automatic DKMS rebuild is expected to be able to produce >> modules which can work with the running kernel, then clearly the >> current behavior is buggy in some way, and should be addressed. > > I don't think that's a reasonable expectation. But I think DKMS > should not automatically rebuild when installing a version of > linux-headers- ABINAME that is newer than the currently *installed* > version of linux- image-ABINAME. It's possible that it actually doesn't. I believe the rebuild that triggered the problem, for me, was triggered not by an upgrade of linux-headers-ABINAME but by an upgrade of virtualbox-dkms; the linux-headers-* package was upgraded much earlier, I believe on January 21st. (And IIRC the matching linux-image-* package was upgraded at the same time.) Off the top of my head, I don't see any potential way for DKMS to know whether it's being asked to build against the sources of the running kernel, vs. simply the sources of the currently installed kernel - and I'm fairly sure that making the correct decision about whether or not to rebuild when upgrading non-kernel packages would require knowing that. >> On the other hand, if rebuilding the modules is expected to result >> in modules which will not load against the running kernel, >> shouldn't the DKMS machinery detect this condition and refrain from >> automatically removing the existing (working) modules, at least >> without an override request of some sort? Or at bare minimum, warn >> that proceeding with the upgrade will result in functionality loss >> until a reboot can be carried out? > > If by "removing" you mean unloading a module from the kernel, I > agree that it should not do this. The idea of not unloading the module at upgrade time had in fact not occurred to me. It's an interesting one, and if viable would seem to offer a way out of the problem, but I'm not sure how viable it would be in practice. The upgrade process appears to consist basically of an uninstall followed by an install. As such, all three of those scenarios would need to be considered. As far as I can tell without deeper investigation than I'm currently set up for, what DKMS currently does at upgrade is to delete the old modules, build the new ones, unload the old ones, and then load the new ones. (I'm basing this on the output messages during the upgrade; I've dug for the place where the underlying commands get run and the messages get generated, but I haven't found anything I'm confident is the right place.) If there's a way to load the new module without unloading the other first - if, e.g., the kernel will detect the collision and automatically unload the old one after validating the new - it should be possible to have DKMS do that, and skip the unload entirely. However, I don't remember seeing any indication that such a way exists. If there's a way to detect whether the newly-built modules will be compatible with the currently-running kernel before trying to load them, it might be possible to have DKMS skip the unload and subsequent load if the latter would fail. Again, however, I don't know of any such way. If neither of those things is possible, then the choices would seem to be to either never unload (meaning that the old module would remain in use until sysadmin intervention), or always unload (basically the current situation). What DKMS currently does at uninstall time I don't know. Clearly, however, it would need to unload the module, as otherwise the uninstall could not be considered complete. However, it's not clear to me that there's any way for it to be able to tell a "permanent uninstall" removal from an "upgrade" removal. At install time, plainly DKMS needs to load the just-built module, but again it's not clear to me that there's any way for it to tell a "clean install" build from an "upgrade" build. (That said, I've also seen my entire system hardlock when upgrading VirtualBox packages while a VirtualBox VM was running, and it seems very plausible that the lockup was because a module which was in use by VirtualBox got automatically unloaded by DKMS. If it's possible to design so as to avoid that automatic unload, without unacceptable tradeoffs, that would make managing my upgrades easier.) > If you mean replacing the module on disk, I disagree; it should > build modules for the installed kernel version. Certainly it should, and if there's no way to do that without removing the existing modules from the disk, then that's what it should do - possibly with a warning message or even an "are you sure?" prompt, but still. I h
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
Or in other words: the unexpected behavior here is on the part of DKMS, in removing working modules when the ones which will be put in as their replacements do not work, not on the part of the kernel headers (et cetera) themselves. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann
I encountered this error today on upgrade of virtualbox-dkms, I think
from version 5.2.6-dfsg-2 to 5.2.6-dfsg-5. To the best of my knowledge,
I have not carried out any downgrade, either of the kernel or of the
DKMS package.
In my experience, upgrading a DKMS package triggers an automatic rebuild
of the relevant module(s) against installed headers; more specifically,
on removal of the pre-upgrade version the old modules are removed, and
on install of the post-upgrade version the new modules are automatically
built. (The messages printed during this process seem to imply that the
DKMS machinery has the ability to have multiple installed module
versions per kernel, and simply set one or another as active, but I have
never seen this functionality be used.)
I am still running kernel version 4.14.13-1, although the installed
version of linux-{image,headers}-4.14.0-3-amd64 is 4.14.17-1; I have not
rebooted since upgrading the kernel package, and IMO it should not be
expected that upgrading the kernel will be followed swiftly by a reboot.
To the best of my recollection, I have never previously seen it be
necessary to reboot in order to avoid loss of functionality from a DKMS
rebuild subsequent to a kernel upgrade.
If the automatic DKMS rebuild is expected to be able to produce modules
which can work with the running kernel, then clearly the current
behavior is buggy in some way, and should be addressed.
On the other hand, if rebuilding the modules is expected to result in
modules which will not load against the running kernel, shouldn't the
DKMS machinery detect this condition and refrain from automatically
removing the existing (working) modules, at least without an override
request of some sort? Or at bare minimum, warn that proceeding with the
upgrade will result in functionality loss until a reboot can be carried
out?
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
On 2018-02-16 at 12:31, The Wanderer wrote: > On 2018-02-16 at 11:42, Theodore Ts'o wrote: >> If I had created separate transition packages for each architecture >> separately (e.g., libcommerr2:i386, libcomerr2:amd_64, etc. I >> belive I would have gotten Lintian errors and complaints that I was >> wasting ftp space on all of our mirrors). > > I'm not sure what the right way to handle this is, but having a > single-architecture or non-architecture-specific transitional package > attempt to substitute for all the cross-architecture dependencies > clearly isn't working. > > I'd be glad to help with figuring out what to do on this, but if > having a "separate" transitional package for each architecture isn't > an option, I'm really not sure what might be... Having thought about it again (in the shower), I suspect that the solution is simply to make the transitional package M-A:same, just as the library package itself is (at least going by my, admittedly extremely limited, understanding of the multiarch spec). It looks to me as if any package which needs its dependencies to be the same architecture as itself - as a library-transition package does - effectively needs to be M-A:same, even if no files within that package vary between architectures. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
On 2018-02-16 at 11:42, Theodore Ts'o wrote: > On Fri, Feb 16, 2018 at 07:05:41AM -0500, The Wanderer wrote: > >> Package: libcomerr2 Version: 1.43.8-2 Severity: normal >> >> Dear Maintainer, >> >> libcom-err2, which is currently at version 1.43.9-1, currently >> Breaks: any libcomerr2 package of a lower version. This is normal >> and reasonable. >> >> There is a libcomerr2 package of matching version, which is labeled >> as a transitional package. This is normal, and working fine. >> >> However, there does not appear to be any libcomerr2:i386 >> transitional-package version. The most recent version of >> libcomerr2:i386 available in current testing is 1:43.8-2. (The >> packages.debian.org pages for libcomerr2 that I know to check show >> nothing to indicate that this version is expected to be absent, and >> I have been unable to find any indication of its having been >> rejected for testing migration for whatever reason, but it is >> nevertheless not available.) > > There is a libcomerr2:all package which is in in testing: > > https://packages.debian.org/buster/libcomerr2 Yes, I saw that page. >> As a result, when I attempt to dist-upgrade, apt-get proposes to >> remove libcomerr2:i386, and everything that (directly or >> indirectly) depends on it; that includes at least one package which >> I actively want to retain. (pcsx2, for what it's worth.) > > What I believe *should* have happened is that apt-get should have > replaced libcomerr2:i386 with the new version of libcomerr2 of type > any. If I understand you correctly, I think that's what *is* happening - but the new libcomerr2 package apparently doesn't satisfy the i386 dependency. In fact, I think it's correct in not doing so, because it can't possibly know which non-native architectures of its dependency to pull in. The arch:all libcomerr2 depends on libcom-err2. Since that dependency does not explicitly specify any architecture, it resolves to the package version from the installed native architecture; in this case, that's libcom-err2:amd64. However, what is needed by the :i386 package declaring the dependency is libcom-err2:i386, which the arch:all libcomerr2 does not depend on. In the long run, the right solution is clearly for the depending packages (in this case, parts of krb5) to update their dependencies to libcom-err2. That doesn't affect the question of getting things to work cleanly during the transitional period, though. > If I had created separate transition packages for each architecture > separately (e.g., libcommerr2:i386, libcomerr2:amd_64, etc. I belive > I would have gotten Lintian errors and complaints that I was wasting > ftp space on all of our mirrors). I'm not sure what the right way to handle this is, but having a single-architecture or non-architecture-specific transitional package attempt to substitute for all the cross-architecture dependencies clearly isn't working. I'd be glad to help with figuring out what to do on this, but if having a "separate" transitional package for each architecture isn't an option, I'm really not sure what might be... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
Package: libcomerr2 Version: 1.43.8-2 Severity: normal Dear Maintainer, libcom-err2, which is currently at version 1.43.9-1, currently Breaks: any libcomerr2 package of a lower version. This is normal and reasonable. There is a libcomerr2 package of matching version, which is labeled as a transitional package. This is normal, and working fine. However, there does not appear to be any libcomerr2:i386 transitional-package version. The most recent version of libcomerr2:i386 available in current testing is 1:43.8-2. (The packages.debian.org pages for libcomerr2 that I know to check show nothing to indicate that this version is expected to be absent, and I have been unable to find any indication of its having been rejected for testing migration for whatever reason, but it is nevertheless not available.) As a result, when I attempt to dist-upgrade, apt-get proposes to remove libcomerr2:i386, and everything that (directly or indirectly) depends on it; that includes at least one package which I actively want to retain. (pcsx2, for what it's worth.) Please make sure that the i386 transitional package, suitable to satisfy this dependency chain, is available alongside the amd64 one. It may also be worth checking into whether transitional-package versions for any other architectures are also MIA. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/12 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libcomerr2:i386 depends on: ii libc6 2.26-6 libcomerr2:i386 recommends no packages. libcomerr2:i386 suggests no packages. -- debconf-show failed
Bug#887833: kildclient: fix for 885007 adds indirect dependency on libpam-systemd
Package: kildclient Version: 3.2.0-1 Severity: wishlist Dear Maintainer, Bug 885007 was fixed by adding a dependency on gvfs. gvfs depends on gvfs-daemons, which depends on udisks2, which depends on libpam-systemd. I intentionally run a non-systemd system; the only packages from src:systemd on my machine are libsystemd0 and udev (and probably libudev1, et cetera). The presence of libpam-systemd on an otherwise non-systemd system introduces behavior changes which I find undesirable. As such, any dependency on this package is undesirable to me. As we've discussed in direct mail, the desired functionality can apparently be achieved by a dependency on desktop-file-utils, rather than on gvfs. I have tested with this configuration (and have it installed as I write this, although I am filing the bug against the version which depends on gvfs), and the "open URL in default browser" functionality which the dependency is supposed to provide works as expected. In the interest of keeping chain dependencies minimal, please replace the gvfs dependency with a dependency on desktop-file-utils. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-2-amd64 (SMP w/12 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages kildclient depends on: ii desktop-file-utils 0.23-2 ii libc6 2.26-2 ii libglib2.0-02.54.3-1 ii libgnutls30 3.5.16-1 ii libgtk-3-0 3.22.26-2 ii libgtkspell3-3-03.0.9-2 ii libjson-perl2.94-1 ii libpango-1.0-0 1.40.14-1 ii libperl5.26 5.26.1-4 ii zlib1g 1:1.2.8.dfsg-5 kildclient recommends no packages. Versions of packages kildclient suggests: ii kildclient-doc 3.2.0-1 pn libgtk3-perl -- debconf-show failed
Bug#866950: fontconfig: upgrade radically changes font-rendering - hotfix and possible lead
On 2017-07-03 at 20:13, Tomasz Nitecki wrote: > Ok, so just two quick additions: > > 1. Correct local.conf location for the system wide configuration is > /etc/fonts/local.conf > > 2. You can use Terry`s configuration [A] as it is cleaner (with > proper xml structure) and works just as well. Terry's configuration actually does something slightly different, though. Your snippet turns on full font hinting; his not only does that, it also disables autohinting. (That can be omitted by cutting out part of his config, which is superior in abstract terms, but using it verbatim will have that result.) Some people may want to do both, others may only want to do one, and still others may want to do something different from both. Depending on exactly what font settings you had in place prior to the upgrade, that may require different configuration snippets. The information so far present in this bug mainly just points to where the configuration changes to revert the behavior need to be made and what format they need to be in, with hints about what settings are supported by the software. A comprehensive listing of possibly relevant configuration options for this is almost certainly out of scope. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#853086: livestreamer: Can't play twitch streams: Client Error: Bad Request for url
Per the comments at https://github.com/chrippa/livestreamer/issues/1478#issuecomment-247242827 and https://github.com/chrippa/livestreamer/issues/1478#issuecomment-247392244 , the expected solution for this is via livestreamer's '--http-header' option, which can be provided in one of two ways. On the livestreamer command line, add the option: --http-header=Client-ID=ewvlchtxgqq88ru9gmfp1gmyt6h2b93 Or in ~/.livestreamerrc, add a line reading http-header=Client-ID=ewvlchtxgqq88ru9gmfp1gmyt6h2b93 (Other Client-IDs could potentially work; that one is the ID apparently assigned to livestreamer itself. People have reported success using the ID assigned to the Twitch Web-based player, but that seems less appropriate.) Whether having this in the config file would cause any problems for streaming from other sites I don't know, but it seems to make things work fine for Twitch, with the livestreamer version currently available in testing. There's also a patch in that thread which looks as if it should both make the Client-ID potentially configurable (without exposing a configuration interface for it, though) and use the ID automatically. I haven't tested with it, although I wouldn't be surprised if it or a derivative had been adopted by the 'streamlink' fork. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...
It's now been well over two months since this bug was filed. Not only has the problem not been fixed, another Flash release has been made upstream in the interim; I've been retrying this once a day so that I'll notice as soon as a fix gets put in place, and it's now reporting failure to download the checksum file for 25.0.0.127 (vs. the original report's 24.0.0.194). Getting this working in the short term should be nearly trivial for anyone who has write access to the ~/bartm/ Webspace. Does anyone other than Bart Martens himself have that access? If so, someone with that access should put the necessary file into place, so that the package is once again installable at least in the short term. If not, someone should adopt the package (or at least NMU it, though I suspect this would be out of scope for an NMU) and either drop the requirement for this external checksum entirely (making it optional would be fine), or alter the checksum lookup to point to a location which is write-accessible to a sufficiently large pool of people that one of them can be expected to respond to future Flash updates within a week or so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...
What is the justification for marking this bug as 'important', down from the previous 'grave'? As things stand, this package is actually uninstallable - or rather, it will fail in the postinst step which is what actually downloads and installs the current version of the plugin (since the package itself is just a downloader). I confirmed this by testing in a chroot. A release-blocker severity seems entirely appropriate to me under those circumstances; making a Debian release which includes a package which cannot be installed does not seem remotely ideal, even if the problem can be fixed without changing the contents of the package repositories. If there are plans in place to make sure that that problem is fixed before the release, and that it is dealt with promptly whenever it recurs after the release, that's one thing - but if that's the case, those plans should be stated publicly (preferably on the bug report), and to date that has not happened AFAICT. Te actual problem here is that the functionality of this internal update tool depends not only on something external both to the local machine and to the package system, but on something that is specific to one particular person. If I'm reading things correctly, people.debian.org/~bartm/ is the personal Debian web space of Bart Martens, who is listed as the maintainer for this package; this would seem to imply that _no one else_, except perhaps the sysadmins of that server, can update this. This seems like an undesirably fragile design. If external checksum files for this download are to be required, IMO they should be hosted on a Webspace particular to the package rather than to the maintainer, and any DD should have the ability to update them. Maintaining a hard requirement for external checksum files is one matter when the maintainer who updates them is on the ball and gets them updated promptly after a new version is available (i.e., within a week at most) - but when the checksum files have still not been updated not only more than a week after the release of the new version, but a good month and a half after the bug reporting their absence was opened, that represents a less acceptable situation. I subscribe to a half-dozen or so Debian discussion mailing lists, and I have not seen any sign of life from Bart Martens since September of 2016 - close to six months ago. It's far from impossible that he's active elsewhere and I've just missed noticing those areas, but at some point this starts to look like an inactive maintainer. Unfortunately, the normal channels for dealing with a nonresponsive maintainer mostly seem to assume that the proper solution to the problem (assuming the maintainer remains nonresponsive) is for someone else to adopt the package - but in this case, that wouldn't directly help, since the problem is actually in the maintainer's private Debian Webspace and external to the package itself. At best, a new maintainer could tweak the script to A: point to a different Webspace - which would only redirect the problem, in the long term - or B: (optionally) skip the validation entirely, which is potentially problematic in its own way. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#856813: pidgin: AIM accounts will require 2.12 as of 2017-03-28
Package: pidgin Version: 2.11.0-3 Severity: normal Dear Maintainer, As has been reported on various tech-news sites, AOL is dropping support for older versions of the authentication methods which third-party clients such as Pidgin use to connect to the AOL Instant Messenger service. This dropping of support is scheduled to take effect on March 28th, well before the expected release of Debian stretch. The official word from upstream is that version 2.12 of Pidgin will include support for the newer authentication methods involved, and that this version is due for release in about a week. To release Debian stretch with a version of Pidgin which no longer supports connecting to one of the major instant-messaging networks, despite a version which does still support that being available, would obviously be undesirable. However, as we are already within the release freeze, including the fix is not as straightforward as simply packaging the new upstream version directly after its release. Please take whatever measures are appropriate to ensure that a version of pidgin which supports the new required authentication mode for AIM either ships with Debian stretch, or is available to users of stretch as promptly as possible after the release occurs. If such a version can be available (even if from another repository) to users of testing in the meantime, that would be even better. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init) Versions of packages pidgin depends on: ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-20.108-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3+b2 ii libgadu31:1.12.1-4 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-1 ii libgstreamer1.0-0 1.10.3-1 ii libgtk2.0-0 2.24.31-2 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-0 1.40.3-3 ii libpurple0 2.11.0-3 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.4-3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.24.1] 5.24.1-1 ii pidgin-data 2.11.0-3 Versions of packages pidgin recommends: ii gstreamer1.0-alsa 1.10.3-1 ii gstreamer1.0-libav 1.10.3-1 ii gstreamer1.0-plugins-base 1.10.3-1 ii gstreamer1.0-plugins-good 1.10.3-1 Versions of packages pidgin suggests: ii libsqlite3-0 3.16.2-2 -- debconf-show failed
Bug#856247: dict-gcide: Missing definition present upstream: "appeal"
On 2017-02-27 at 03:00, Ritesh Raj Sarraf wrote: > On Sun, 2017-02-26 at 17:20 -0500, The Wanderer wrote:> >> Reinstalling the package (via 'apt-get install --reinstall dict-gcide') >> did not affect this behavior. > >> By contrast, looking up 'appeal' in either the www.dict.org Web-based >> query interface for gcide or the gcide.gnu.org Web-based query interface >> finds three separate definition sections: >> http://www.dict.org/bin/Dict?Form=Dict2&Database=gcide&Query=Appeal >> http://gcide.gnu.org.ua/?q=appeal&define=Define&strategy=. > >> I would expect that looking up "appeal" using the dict command-line >> interface would provide the same results as doing so via the various >> online interfaces. > > Yes. I am aware of the version in Debian. The version in Debian needs to be > updated to the latest. But this won't happen in time for Debian Stretch due to > lack of time on my part. So this is just a matter of "not at current upstream version"? I apologize for the noise, then. The dict.org Web lookup interface claims to be using version 0.48, which is a reasonable match for the Debian-installed version of 0.48.3; I thought I'd seen an 0.48 version number on the gcide.gnu.org.ua interface as well, but now that I look I don't see one, and the savannah.gnu.org project page says that version 0.51 is available (apparently since 2012!). Not having packaged the current upstream release is significantly less of a problem than missing definitions which are in the upstream instance of the packaged version. I'd ask if there's anything I can do to help get the Debian version updated to the latest upstream release, but the fact that we're past the freeze date means there's probably not much point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#856247: dict-gcide: Missing definition present upstream: "appeal"
Package: dict-gcide
Version: 0.48.3
Severity: normal
Dear Maintainer,
When I run the following command, I get (in part) the following output:
$ dict -d gcide repeal
[...]
>From The Collaborative International Dictionary of English v.0.48 [gcide]:
Repeal \Re*peal"\ (r?-p?l"), v. t. [imp. & p. p. {Repealed}
(-p?ld"); p. pr. & vb. n. {Repealing}.] [OF. repeler to call
back, F. rappeler; pref. re- re- + OF. apeler, F. appeler, to
call, L. appellare. See {Appeal}, and. cf. {Repel}.]
[...]
This points to a definition of "appeal", marked as being available for
lookup. However, when I attempt to look up "appeal", I get no results:
$ dict -d gcide appeal
No definitions found for "appeal"
Similarly, manually grepping through /usr/share/dictd/gcide.* does not
locate any definitions for "Appeal".
Reinstalling the package (via 'apt-get install --reinstall dict-gcide')
did not affect this behavior.
By contrast, looking up 'appeal' in either the www.dict.org Web-based
query interface for gcide or the gcide.gnu.org Web-based query interface
finds three separate definition sections:
http://www.dict.org/bin/Dict?Form=Dict2&Database=gcide&Query=Appeal
http://gcide.gnu.org.ua/?q=appeal&define=Define&strategy=.
I would expect that looking up "appeal" using the dict command-line
interface would provide the same results as doing so via the various
online interfaces.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init)
Versions of packages dict-gcide depends on:
ii dictd [dict-server] 1.12.1+dfsg-4
dict-gcide recommends no packages.
Versions of packages dict-gcide suggests:
ii dict-wn 1:3.0-33
-- no debconf information
Bug#854314: youtube-dl: 'Signature extraction failed' on some YouTube videos
Package: youtube-dl
Version: 2016.12.01-1
Severity: normal
Dear Maintainer,
Today, in attempting to download videos from YouTube with youtube-dl, I
have seen some download normally and others produce errors.
(Unfortunately, this happened late enough that the release-freeze
announcement came in while I was testing it.)
Specifically, I have seen the following:
$ youtube-dl https://www.youtube.com/watch?v=4pbMUEHvoAo --verbose
[debug] System config: []
[debug] User config: ['-f', 'best']
[debug] Command-line args:
['https://www.youtube.com/watch?v=4pbMUEHvoAo', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.12.01
[debug] Python version 3.5.3 - Linux-4.8.0-2-amd64-x86_64-with-debian-9.0
[debug] exe versions: rtmpdump 2.4
[debug] Proxy map: {}
[youtube] 4pbMUEHvoAo: Downloading webpage
[youtube] 4pbMUEHvoAo: Downloading video info webpage
[youtube] 4pbMUEHvoAo: Extracting video information
[youtube] {43} signature length 42.43, html5 player en_US-vflkk7pUE
[youtube] 4pbMUEHvoAo: Downloading player
/yts/jsbin/player-en_US-vflkk7pUE/base.js
ERROR: Signature extraction failed: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
(caused by ValueError("unknown url type:
'/yts/jsbin/player-en_US-vflkk7pUE/base.js'",)); please report this
issue on https://yt-dl.org/bug . Make sure you are using the latest
version; see https://yt-dl.org/update on how to update. Be sure to
call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
li
Bug#841837: apt-listchanges: feature request: combine identical changelog entries from multiple packages
Package: apt-listchanges Version: 3.5 Severity: wishlist Dear Maintainer, On a semi-frequent basis - usually when there is an automatic mass binary rebuild on the buildds, in response to a transition against a common dependency package - running a dist-upgrade will result in being shown a flood of changelog entries which are essentially identical, differing only in package name, package version, and entry timestamp. The pattern which such entries usually follow is: * Binary-only non-maintainer upload for [architecture]; no source changes. * Rebuild against [depended-on package]. (At the moment, I am also seeing a mass set of identical entries in an apparently maintainer-initiated update to set of KDE-related packages; a couple of dozen or so packages seem to have been updated simultaneously to the same version, with identical or near-identical changes in each. This sort of issue thus is not exclusive to such automatic rebuilds, it's just most common there.) This mass repetition of identical entries makes it difficult to spot changelog entries for other packages in the middle of the flood - especially since these near-identical entries are often not grouped all together, but scattered around throughout the apt-listchanges report, such that other packages' entries sometimes appear in the middle of a set of the identical entries. I would like to request that there be implemented a mode for apt-listchanges in which, if two changelog entries which are to be reported in a single apt-listchanges run are identical except for package name, package version, and timestamp, the changelog body is only shown once, and the packages and versions (and possibly timestamps) which use that body are listed together next to that single instance. It's fine (and probably best, at least to start with) if this mode is not the default, as long as it can be enabled in an appropriate configuration file, and the way to enable it is documented in the man page. This is, of course, not an urgent request. I regret that I lack sufficient familiarity with the apt-listchanges code (and even the language it's written in) to be comfortable with trying to implement this myself; that may change, but even if it doesn't, I still want to record the existence of the request. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init) Versions of packages apt-listchanges depends on: ii apt1.3.1 ii debconf [debconf-2.0] 1.5.59 ii debianutils4.8 ii python3-apt1.1.0~beta5 pn python3:any ii ucf3.0036 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 53.0.2785.143-1 ii dillo [www-browser]3.0.5-2+b1 ii elinks [www-browser] 0.12~pre6-11+b3 ii exim4-daemon-light [mail-transport-agent] 4.87-3+b1 ii iceweasel [www-browser]38.8.0esr-1~deb8u1 ii kterm [x-terminal-emulator]6.2.0-46.1+b1 ii links [www-browser]2.13-1 ii lynx [www-browser] 2.8.9dev9-1 ii python3-gi 3.22.0-1 ii w3m [www-browser] 0.5.3-29 ii xterm [x-terminal-emulator]327-1 -- debconf-show failed
Bug#833621: RFS: libgap-sage/4.8.3+ds-1 [ITP] -- GAP kernel as a C shared library
On 2016-08-09 at 04:36, Mattia Rizzolo wrote: > control: tag -1 moreinfo > control: owner -1 ! > > On Sun, Aug 07, 2016 at 02:49:38AM +0100, Jerome Benoit wrote: >> [1] https://anonscm.debian.org/cgit/debian-science/packages/libgap-sage.git > > d/*.lintian-overrides + d/*.README.Debian: > you use the word 'furnished', which really means "providing > forniture" (or "provided with forniture"), afaik. I'm positive Debian > doesn't ship forniture :D > I think you meant 'provided' there. Actually, this is valid. The first definition of "furnish" from the dict-gcide package is: 1. To supply with anything necessary, useful, or appropriate; to provide; to equip; to fit out, or fit up; to adorn; as, to furnish a family with provisions; to furnish one with arms for defense; to furnish a Cable; to furnish the mind with ideas; to furnish one with knowledge or principles; to furnish an expedition or enterprise, a room or a house. See also e.g. http://www.thefreedictionary.com/furnish for online-dictionary definitions. Although the sense related to providing furniture for a room is the more common usage nowadays, it is in fact secondary to the sense related to providing anything with "anything necessary, useful, or appropriate". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#825104: zotero-standalone: claims to not require any Firefox browser, but depends on firefox packages
Package: zotero-standalone Version: 4.0.29.5+dfsg-1 Severity: minor Dear Maintainer, The long package description of zotero-standalone states in part that: "This package contains the standalone version of Zotero which does not require any Firefox browser." However, the package includes a Depends: line which lists both firefox and firefox-esr. As such, the package cannot in fact be installed without a Firefox browser. If this version of Zotero does in fact require the presence of a Firefox browser on the system, then the package description is incorrect and needs to be revised. (And the description of the program as "standalone" may be argued to be misleading.) If it does not require that, then the Depends on firefox | firefox-esr should be demoted to at most a Recommends, if not removed entirely. I notice that the Depends: line from package version 4.0.22-1 lists several different versions of xulrunner as alternatives, with iceweasel as the last option in the list. It seems possible that it was once possible to install Zotero standalone (with no Firefox browser present), by installing one of the xulrunner packages instead, and that when the xulrunner alternatives were dropped the package description was not altered to match. I do not know why xulrunner was dropped as a dependency alternative; the only reason to do so which springs to my mind is the possibility that separate XULRunner may be going away, and thus not be there to be depended on. If that is the case, then it seems entirely possible that it will in fact cease to be possible to install a standalone version of Zotero at all, in which case the zotero-standalone package should probably go away as well. Note that to date, I have not actually used Zotero myself; I simply noticed this while looking at the package out of interest. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init)
Bug#810290: ITP: mediawiki -- website engine for collaborative work
Is there any update or status on this? Before realizing that Debian's MediaWiki packages were out of date and were not included in testing, I committed to setting up an in-house Wiki at my workplace, to be present and functional by the end of June. If it were going to be dropped from Debian entirely, I could fall back on installing and configuring MediaWiki separately, rather than via the Debian packaging system. However, if (as this bug indicates) it's going to be reintroduced through Debian, I would prefer not to install an unpackaged version and then need to deal with either upgrading it manually or migrating across to the packaged version. As it has been more than two months since the filing of the ITP, and nearly as long since the last bug activity, I am left a little bit in Limbo on this; I can neither move forward independently of any Debian package, nor plan around the expected arrival schedule of the updated Debian package. (Also, the version of MediaWiki in Debian stable does not seem to behave as documented; the only in-Debian documentation I've found directs the sysadmin to configure the package via a Web interface, but on a machine which has had mediawiki 1:1.19.20+dfsg-2.3 installed - with its dependencies, including Apache - and no other special configuration performed, Apache does not expose the described Web interface. Which isn't relevant to this bug, except that it means I can't just start out with the already-packaged version and expect to be able to upgrade that if-and-when the new version gets packaged.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#817244: exim4-base: cron noise re environment
On 2016-03-10 at 11:05, Andreas Metzler wrote: > On 2016-03-10 The Wanderer wrote: > >> Andreas Metzler on Wed, 9 Mar 2016 18:07:30 +0100 >> I get this same behavior. > >>> The Debian configuration sets add_environment: > >> $ /usr/sbin/exim4 -bP | grep environment >> LOG: MAIN >> WARNING: purging the environment. >> Suggested action: use keep_environment and add_environment. >> >> add_environment = >> keep_environment = > > >> $ /usr/sbin/exim4 -bV | tail -n1 >> Configuration file is /var/lib/exim4/config.autogenerated >> >>> grep -rl _environment /etc/exim4/ >> >> $ grep -rl _environment /etc/exim4/ >> grep: /etc/exim4/passwd.client: Permission denied > > Hello, > > Does not look like you are using unmodified up-to-date exim4-config: I didn't see how that could have happened, but you appear to be quite right, though there's something odd going on. Yesterday, I did an 'apt-get update'/'apt-get dist-upgrade', specifically in order to check whether the updated exim4 in testing fixed this problem. In the morning, when I saw that the cron mail had still showed up with the same contents, I went looking and found this bug report. After receiving your mail, I ran 'apt-get dist-upgrade' again, without running 'apt-get update' first - and it listed exim4-config as being available to upgrade. (It appears to have previously been at version 4.86-7.) I don't know how this can have happened, since as far as I'm aware I had no pins or holds on exim4-related packages. With exim4-config updated to version 4.86.2-2, however, I now get the environment results you indicated. I expect this to have fixed the problem. If I do get the notification again tomorrow, I will report back. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#817244: exim4-base: cron noise re environment
I get this same behavior. > The Debian configuration sets add_environment: > > ametzler@argenau:~$ /usr/sbin/exim4 -bP | grep environment > add_environment = <; PATH=/bin:/usr/bin > keep_environment = $ /usr/sbin/exim4 -bP | grep environment LOG: MAIN WARNING: purging the environment. Suggested action: use keep_environment and add_environment. add_environment = keep_environment = > Are you using Debian's configuration scheme? As far as I know, yes; I certainly don't remember making any changes to it. If my current exim4 configuration is not the Debian default, I'm reasonably sure that's news to me. > ametzler@argenau:~$ /usr/sbin/exim4 -bV | tail -n1 $ /usr/sbin/exim4 -bV | tail -n1 Configuration file is /var/lib/exim4/config.autogenerated > grep -rl _environment /etc/exim4/ $ grep -rl _environment /etc/exim4/ grep: /etc/exim4/passwd.client: Permission denied -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site
On 2016-02-18 at 04:27, Niklas Edmundsson wrote: >>>> * The Wanderer [2015-09-04 12:17]: >>>>> When I connect to http://get.debian.org/ in a Web browser, I >>>>> am redirected to https://www.debian.org/CD/, which is a HTTPS >>>>> site. > > FYI, get.debian.org redirects to http://www.debian.org/CD/ > > I think the https stuff comes from the > https-was-previously-used-for-this-site-so-lets-enforce-it > site/browser feature, I forget what it's called... > > So at least the confusion is not intentional on our part ;-) The same redirection happens with wget: $ wget http://get.debian.org/ --2016-02-29 07:19:52-- http://get.debian.org/ Resolving get.debian.org (get.debian.org)... 130.239.18.173, 130.239.18.165, 2001:6b0:e:2018::165, ... Connecting to get.debian.org (get.debian.org)|130.239.18.173|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.debian.org/CD/ [following] --2016-02-29 07:19:52-- https://www.debian.org/CD/ So unless wget has a similar feature (which would rather surprise me, particularly since I don't see one documented in the man page), I think this is an unlikely explanation. (For that matter, it also happens with lynx, for which I'd be even more surprised if such a feature were present.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
On 2015-12-14 at 23:31, The Wanderer wrote: > On 2015-12-14 at 12:47, David Kalnischkies wrote: >> On Mon, Dec 14, 2015 at 11:42:34AM -0500, The Wanderer wrote: >> >>> Couldn't create tempfiles for splitting up >>> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease >> Interesting might be the permissions of your $TMPDIR: stat /tmp >> $TMPDIR > > $ stat /tmp $TMPDIR > File: ‘/tmp’ > Size: 53248 Blocks: 112IO Block: 4096 directory > Device: fd02h/64770dInode: 2 Links: 73 > Access: (0775/drwxrwxr-x) Uid: ( 1000/wanderer) Gid: ( 1004/ tmpdir) > Access: 2013-08-30 09:47:13.901246241 -0400 > Modify: 2015-12-14 23:14:47.519608765 -0500 > Change: 2015-12-14 23:14:47.519608765 -0500 > Birth: - > > IOW, it's not world-writable, and the group involved is probably not > a standard one. > > By comparison, on a different machine which doesn't have the > problem, /tmp is drwxrwxrwx root:root. > > Now that I've looked at this, I vaguely recall that I set /tmp up > this way intentionally, not long after I built this system - but I > can't remember why. I think it was simply that I couldn't write to > /tmp as my normal user otherwise, but that doesn't seem to hold with > the other system; there may also have been a bit of thinking that the > way /tmp looked in 'ls / --color=auto' with drwxrwxrwx root:root was > ugly, but if so I haven't noticed it on the other system in the past > few years. > > This is probably the culprit. I'll investigate changing this in the > morning, when I have more time and less of a headache. I've changed this to match the described configuration of the machine which works, and the error has disappeared. (I first tried just adding '_apt' to the group involved, which has write access to that directory, but that didn't work; I'm not really sure why.) Unless it's worth trying to detect this type of case in the code and either adapt to work around it or provide a more useful error message, about the only thing I think might be called for would be update documentation to at least provide a hint of where to look. (Someone should probably also point this out to the person who reported the Ubuntu bug I linked to; I may, if no one else does.) If that's not worth it either, this bug can probably be closed as (a somewhat unusual form of) operator error. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
On 2015-12-14 at 12:47, David Kalnischkies wrote: > Control: notfound -1 1.0.10.2 > Control: found -1 1.1.3 > > (fixing up metadata to reflect report) Looks like my attempt got there a bit earlier, but thanks anyway, since I wasn't sure I'd gotten it right. (Is the use of -1 to represent "current bug" or suchlike documented anywhere? I remembered seeing it used, but I couldn't find it in https://wiki.debian.org/HowtoUseBTS, https://www.debian.org/Bugs/server-control, or 'man bts', so I didn't risk trying it.) > On Mon, Dec 14, 2015 at 11:42:34AM -0500, The Wanderer wrote: > >> Couldn't create tempfiles for splitting up >> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease > > The code doing the splitting is present since 0.9.8 (~2013), so that > is probably really about the tempfiles rather than this code itself > as it didn't change much. > > I guess its permission related as this code is now executed as _apt > rather than as root. You can disable privilege dropping temporarily > with -o APT::Sandbox::User=root Agreed, that sounds likely - and thanks for the tip. > Interesting might be the permissions of your $TMPDIR: stat /tmp > $TMPDIR $ stat /tmp $TMPDIR File: ‘/tmp’ Size: 53248 Blocks: 112IO Block: 4096 directory Device: fd02h/64770dInode: 2 Links: 73 Access: (0775/drwxrwxr-x) Uid: ( 1000/wanderer) Gid: ( 1004/ tmpdir) Access: 2013-08-30 09:47:13.901246241 -0400 Modify: 2015-12-14 23:14:47.519608765 -0500 Change: 2015-12-14 23:14:47.519608765 -0500 Birth: - IOW, it's not world-writable, and the group involved is probably not a standard one. By comparison, on a different machine which doesn't have the problem, /tmp is drwxrwxrwx root:root. Now that I've looked at this, I vaguely recall that I set /tmp up this way intentionally, not long after I built this system - but I can't remember why. I think it was simply that I couldn't write to /tmp as my normal user otherwise, but that doesn't seem to hold with the other system; there may also have been a bit of thinking that the way /tmp looked in 'ls / --color=auto' with drwxrwxrwx root:root was ugly, but if so I haven't noticed it on the other system in the past few years. This is probably the culprit. I'll investigate changing this in the morning, when I have more time and less of a headache. It might be worth trying to detect /tmp or $TMPDIR writability at some point in the process, but I entirely understand if it's considered not worth the code and/or the hassle. > Potentially also how you mount it (if you do it): mount | grep tmpfs This returns a bunch of things, starting with udev and including several things under /run and one under /sys, but no /tmp or similar. > [I see that you haven't followed the systemd switch yet, which > suggests you could have other "new" default options not as default > like a non- persistent /tmp as well] As it happens, /tmp is currently persistent on this computer, but is non-persistent on the one which doesn't have the problem. That's got nothing to do with the systemd switch AFAIK, however, and I'm pretty sure it's orthogonal to the current problem. > You could also try moving /var/lib/apt/lists away. There is no > 'partial' in this file path, so maybe some bad file is stuck in there > doing bad things. While at it: Anything interesting in the partial/ > subdirectory and does the mention file looks at least reasonable? The > files are all Hit's – what modification time have the files in the > lists/ dir? I don't have this information ready to hand, since I always run the update again after downgrading back to the working version, and that's going to update the timestamps and suchlike. If it's important, which I now think it probably isn't, I can do the dance to get it tomorrow or so. > I presume 1.1.3 was the first apt you tried of the 1.1 series, > right? It's the first to make it to testing, so yes. >> Could not execute 'apt-key' to verify signature (is gnupg >> installed?) > > (That is a catch-all message printed after we had a failure higher > up the chain [which was probably very technical like this one] – with > the "most likely" cause added in a few layman terms as we do it in a > few other error messages as well.) I rather expected this would be the case. I mentioned gnupg just to confirm that, yes, I had investigated the cause suggested in the error message and it didn't seem to apply. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#807948: Acknowledgement (apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files)
found 807948 1.1.3 notfound 807948 1.0.10.2 thanks My mistake - I forgot to tweak the bug-report template's automatic version info before sending it in. This is found in 1.1.3 and later, not in 1.0.10.2. This is the first time I've used the BTS commands, so I hope I've got this right... I tried to correct it with the 'bts' command-line program first, and saw no errors, but nothing seems to have happened to the bug itself. If this mail doesn't fix it, I'll leave things alone until someone can look at this, or until I can get advice through other channels.
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
Package: apt Version: 1.0.10.2 Severity: important Dear Maintainer, When I upgrade to apt 1.1.3 or later (tested with both that and 1.1.4), and then run 'apt-get update' or 'apt update', I get results like the following: Ign:1 http://ftp.us.debian.org/debian stable InRelease Hit:2 http://ftp.us.debian.org/debian testing InRelease Err:2 http://ftp.us.debian.org/debian testing InRelease Couldn't create tempfiles for splitting up /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Hit:3 http://ftp.us.debian.org/debian stable Release Err:4 http://ftp.us.debian.org/debian stable Release.gpg At least one invalid signature was encountered. Ign:5 http://download.videolan.org/pub/debian/stable InRelease Hit:6 http://download.videolan.org/pub/debian/stable Release Err:7 http://download.videolan.org/pub/debian/stable Release.gpg At least one invalid signature was encountered. Hit:8 http://security.debian.org stable/updates InRelease Err:8 http://security.debian.org stable/updates InRelease't create tempfiles for splitting up /var/lib/apt/lists/security.debian.org_dists_stable_updates_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Hit:9 http://security.debian.org testing/updates InRelease Err:9 http://security.debian.org testing/updates InRelease splitting up /var/lib/apt/lists/security.debian.org_dists_testing_updates_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Reading package lists... Done W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.us.debian.org/debian testing InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.us.debian.org/debian stable Release: At least one invalid signature was encountered. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.videolan.org/pub/debian/stable Release: At least one invalid signature was encountered. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://security.debian.org stable/updates InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://security.debian.org testing/updates InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://ftp.us.debian.org/debian/dists/testing/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://security.debian.org/dists/stable/updates/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://security.debian.org/dists/testing/updates/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://ftp.us.debian.org/debian/dists/stable/Release.gpg At least one invalid signature was encountered. W: Failed to fetch http://download.videolan.org/pub/debian/stable/Release.gpg At least one invalid signature was encountered. W: Some index files failed to download. They have been ignored, or old ones used instead. As the below should indicate, I do have gnupg installed. Downgrading back to apt 1.0.10.2 (which is a manual process involving multiple passes with dpkg, due to dependency problems) restores functionality. A problem which looks like the same issue has been reported by an Ubuntu user: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1524196 The configuration information below was captured from a system where the downgrade back to 1.0.10.2 had been completed. The pins against apt and aptitude-common are to prevent dist-upgrades from bringing back the broken configuration again. As far as I'm aware, nothing about my system should prevent this from working. However, I've been unable to figure out how to get meaningful information about what is failing. If there is anything I can do to help track this down, please do not hesitate to let me know. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.1\.0-2-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.2\.0-1-
Bug#799296: [debian-mysql] Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history
On 2015-09-17 at 12:48, Clint Byrum wrote: > Sorry that you had this happen. I wonder if the important commands > were mysql grants for users? It's not impossible that some of the oldest commands in the history might have been such grants, but most of the history was more mundane select and update queries - albeit ones with enough complexity to be a pain to construct. > More likely would be that perhaps you had the mysql client wrapped > with a shell script that changed MYSQL_HISTFILE to something other > than ~/.mysql_history ? Not as far as I know. I haven't intentionally written any such wrapper; as far as I know, what I was running was the version of /usr/bin/mysql which is provided by mysql-client 5.5.44-0+deb8u1. I also still have a backup copy of a (much) older ~/.mysql_history, from before this database even existed, at a path and filename which seems to indicate that I copied it from the name ~/.mysql_history. For whatever that's worth. > Thanks for reporting anyway, we'll try and figure this one out. You're quite welcome. In the unlikely event that there's anything I can do to help track this down, please don't hesitate to let me know. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history
Package: mysql-client-5.6 Version: 5.6.25-4 Severity: minor Dear Maintainer, I habitually have an instance of mysql-client running, connected to a particular database, with the somewhat-complex commands which I regularly use with that database present in the mysql command history. When I have upgraded mysql-client in the past, all I have needed to do is to exit the old client instance after the upgrade and re-launch with the new client, and everything has been seamless. In particular, the command history from the previous client has still been present. When I upgraded to 5.6, exited the 5.5 client, and re-launched with the 5.6 client, I discovered that my command history was empty. Newly-entered commands made it into the new history just fine, but all of the old ones were gone, apparently beyond recovery. I expected that instead, my command history would be retained, as has happened on every previous upgrade in what is substantially the same scenario. In this particular case, I was able to recover the main important commands from where they were displayed in the terminal from the recent 5.5 session, but it is pure good fortune that all of the main important commands had been used recently enough to still be visible in the terminal's backscroll. If any had not been, I would be stuck with reconstructing them from scratch. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/12 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: sysvinit (via /sbin/init) Versions of packages mysql-client-5.6 depends on: ii debianutils4.5.1 ii libaio10.3.110-1 ii libc6 2.19-19 ii libdbd-mysql-perl 4.028-2+b1 ii libdbi-perl1.633-1 ii libgcc11:5.2.1-17 ii libstdc++6 5.2.1-17 ii libterm-readkey-perl 2.33-1 ii libwrap0 7.6.q-25 ii mysql-client-core-5.6 5.6.25-4 ii mysql-common 5.6.25-4 ii perl 5.20.2-6 ii zlib1g 1:1.2.8.dfsg-2+b1 mysql-client-5.6 recommends no packages. mysql-client-5.6 suggests no packages. -- debconf-show failed signature.asc Description: OpenPGP digital signature
Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site
Package: www.debian.org Severity: minor Dear Maintainer, I'm not completely positive that this is the correct place for this bug report, but I don't know of anywhere else which would be better. Please feel free to reassign if appropriate. Whenever possible, I prefer to connect to Websites via HTTPS. This includes all Debian Websites. When I connect to http://get.debian.org/ in a Web browser, I am redirected to https://www.debian.org/CD/, which is a HTTPS site. However, the initial connection attempt is made over HTTP, and is potentially subject to external observation. When I connect to https://get.debian.org/, I get a near-instant "connection refused" or "failed to connect" error. Firefox reports "Unable to connect", w3m reports "Failed to load", and wget reports "Connection refused". Initial testing seems to indicate that the same basic behavior occurs with cdimage.debian.org, which is the old name for the service now provided by get.debian.org. Please make it possible to connect to get.debian.org via HTTPS and have the redirection function properly. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/12 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: sysvinit (via /sbin/init)
Bug#769602: youtube-dl: download from YouTube fails, “RegexNotFoundError: Unable to extract Initial JS player signature function name”
This looks like an issue which was fixed upstream in version 2014.11.13: https://github.com/rg3/youtube-dl/issues/4175 -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#763619: libmeanwhile-dev: package long description refers to old library package name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Source: libmeanwhile-dev Version: 1.0.2-5 Severity: minor Dear Maintainer, The long description of libmeanwhile-dev states that the package "contains development files of the libmeanwhile0 library.". However, the package itself now Depends: on libmeanwhile1, and libmeanwhile0 appears to no longer exist. It is more common for -dev packages to simply state that the package contains the development files, without specifying any particular package name or version, which is already implicitly indicated by the package dependencies. This mismatch is probably an example of one of the reasons why. Please address this discrepancy, either by removing the package-name reference, or by updating it to refer to the currently live package name. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUK/XKAAoJEASpNY00KDJr7H0P/jGXvUcWp+0jkf9PfyeJSRFt oYttppes3F+aWqUgHYFSc5KqVH4iN+QpA+P2BaMGMhvw8EZNQiD+DUS10g4agaEA eyp3Oult3zszybk+8hsi3HtWuu8trvNc4z9qn9QoEm8ODvC2pqOM/e3ATYeJHLA9 YbW8bpS2ZFlSw0Zosw8PJp2njaFaff7kl5AD/6+Z6I9gaUTo/fRTQJx57/PZrDBk OzOS0UxyVrdyYwgKjx24q5sx4CLlSdLF6MSFCrzzhUGXw+S7Q9w60RLxA+9wDspc m0dRRrEBTO2c1U2PvGaO9vSM95hgXAOow/nBLRR3FAx0QrqXaEsTsJ6bZJwNkUMU 3c9cqW0M9xOK1dhvDHjPOfmfWhRnymjyfNElwmRYZPVQVZ86qBwqR0vgZTScRzmZ ie/wcle1j01zakMChdhwWRvushvqyo0Bw7tRXZmcrL4rcfOm5S+TyNQ859ciPERw tXoQdVmFaUiYT8Lknkro6gvCFShBFov0J42hIfXnMQ8PAuDD1eJKRSH6QVq+aTLu NJot0Mjeo9U9Pev4vdLVPcG8lEHY92eM4h+FseGu4Fnh9DLBf0f2feIdVPxIJIan HTzFEYyJUgJKNdExuDxxxgYe2u5sZ+oRaH1sOhkqw/wGr2olaFsuUKLfqfsCEzwH 4Au+xVIrDlTFtcr74pwX =4dG3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756883: micropolis-data: depends on dummy package ttf-dejavu-core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: micropolis-data Version: 0.0.20071228-7 Severity: minor Dear Maintainer, The ttf-dejavu-core package has been replaced by the fonts-dejavu-core package; as far as I am aware, this is a simple package renaming. ttf-dejavu-core itself still exists, but is a dummy package, and in the long run needs to be safe to remove without causing the removal of any other packages. However, micropolis-data still lists a dependency on ttf-dejavu-core, which prevents the dummy package from being removed without also removing micropolis. Please update the dependency to fonts-dejavu-core, or if there is some reason why that is not a suitable alternative, take other appropriate measures. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/12 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 micropolis-data depends on: ii ttf-dejavu-core 2.34-1 micropolis-data recommends no packages. Versions of packages micropolis-data suggests: ii micropolis 0.0.20071228-7 - -- debconf-show failed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT3ZZpAAoJEASpNY00KDJrVEMQAKsrRcQABKPs+puvCJT9OZ5Z ur5HtZg3VAlFA/1SSW8S3HGZ/n+eoTXWopCG3AUmmHEPiu60HgzKaAMnDI63RSqk iDIxkRNRa0EvAe3HKDMPS7/9mj5Tl8h7ib4BrkkMCqCoS7/BYLaCeHu7Zsc2if8g 8ecbRb6LI//HUSwz+cyPxFdPWORN724pR04t08ro6JRt7k4Qx6292pPIMHCDx339 9fAEI4dPVquT+ZJeNzb+/Kb8+yZ4kyGMc6GbHFNMgqAGK4airC+S8kHPv8tJbKQ1 Qj27Hje2sg3M7RfdsYEz0enZg5Et1ImVa89RvJvUTc83fnfaG2E0M/s3d4ytgwRK oxrslokBM2eWCclfqWlpF/4GKo98rNf7pGxq8JDiX0/dwH4JvIBaBXvMcJ7o8tBl eANneH91wbFRqIdg/kwEiMN+ATZgAI+rVChesI6hs/Vzt36EoXx2JpLrE1WlbVdR BjKNTMDUlyAkwdxYRmUCgbYSHWlhT+QeYQ50FQtih+YG0XFUQ5b4qLRmST93jnmJ GPVARYHLnQanMyzp2ILP+55k1VaxU6MVYnEy2Px78UzteiZJKbtNCMaw325zVYAK OD+DiMRgkrAuOxjK/i3UjPbx3rwp71UAWZ7S9zM52GAAENiXD8pj/wcL1W0g+84H wzW/yOPGr7bJwdwj0ARu =cORu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751048: marked as done (RFS: fizsh/1.0.6-1 (already in Debian))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/16/2014 12:42 PM, Axel Beckert wrote: > Control: reopen -1 > > Dear Bart, > > Debian Bug Tracking System wrote: >> Package fizsh has been removed from mentors. > > since when is this a reason to close RFS bug reports? > > Reopening! I believe the idea is that if the package is not (any longer) in mentors, there is nothing left to sponsor, so the RFS bug is obsolete. If something new comes along to be sponsored later on, according to my understanding of the logic, a new RFS bug should be filed. I could easily be entirely off-base about that, of course, and I agree that the phrasing in these (semi-automated?) closure messages is kind of confusing; it took me a few weeks seeing them come through the mentors list before I figured out what was probably going on. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTn6hGAAoJEASpNY00KDJrqJ8QAIT2MPWHQ+1wKCsTrROi8jEf Jk5IqDhq3nrhcFNXNkdiOFS3xcQSC8eeXRfV8Yi/WxnC/8GZ+Njst7av3DR+wtTB lxVOBaq/s6Q82KwkIpdcnJlPhPmDG6nkQiiuIPkuIprRuvzpoe3ytSr7ucA+20ua BBD8vJX8WRlVbyPvOZmsYwsaKwLMZp8rvmiDOBD5a6AVUbTmNE2eBxny3KcXNCjF BVSp4kzKPqVzeTHvJv8dgd/e+ADzXRwK8Pn2BBVknFS5snrxzYN8K6KWG6oKt/w+ Qug/G46eOwMgcSDpCf3M6EKsjs/MwqcKGzuOlu06yljq/swMcVuRRwKN6vS6uOXA U7h/QrPhvaJ5RxV4moRpA+CQWU70btGVPoplreYK9wsaCHV4ApuUioR6lXZx32w1 yJot9k8IewLJRRBUAUrb2OI19TrN/2BiluyiObBBHGhQ6B+SOrwGYBE4JTsmXaYC JjMxqeR07gSw0fxNLH5qDADRYqNvQPme0wJEf3VgH1umBGLLdwFviDC9vEpQlohD AZJ5Ef2tEAAQ6c+Hl+CljY+QOaE+7QZBzbcTHaEXNSFDJPbFVDM6EKbn/DGS/4d9 WPl+kWC+93NalkIwgI6zaSwoWTf96VlEg6kB8slEyXFf2VIHEy4rNyatTuOxWFmt +uYpkuh4eD3cmB4glYne =fNjx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505381: genisoimage: writes blank sectors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This behavior (or one very similar to it) appears to still be present, five and a half years later. The patch still appears to apply (albeit with considerable a offset) against current upstream SVN. I have not managed to find any indication of what the reason for adding these blank sectors is supposed to be. The code in question appears to date all the way back to the original import of mkisofs into Subversion, so there's no help there. Any chance of either getting this patch applied, or at least figuring out a reason why it would be a bad idea? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTmzLDAAoJEASpNY00KDJrbKkP/16p+KD924ulw9uNTLl9fiy8 RW3WTiMqK8Hv8izcOk+nfTZlLBWDMdFsUHTqWsw4xhgCN+F6KauVDAy1eB82FrEx 8KTCTpb7H0fCrXzY9WArQBPSWAAF/lWn5/dRmw4ZuJUaaAmsZcYRxl1E4cxB+CEF Aoctd0gk3jccQ9Qd+IwzIc5eM2eP1HwHWYfoLoVs7aOlnAWLQ2vt4tnR1nW3YXcG uGUIkcP662l7taIJRW2NsT31AdWXneDrZ3dnHLaORjnrKBzkuFhg0mdRmaKQqzE7 91Tg5L+H/mH9lusfRqkR038dIZy2YoZdpRtcsDkn0iLqvxa3DKVxR3dUZj+Id2+C lhhvTQ2K/1MPVf/FF6mP5ubo7h4V/Vk1K4AQPh9k+RQBRc829njy9HMPcCAdFW2v bAYcESqWmrzNY7HjCVb3rVMVm5SKL3BG5IfwflWBm/+0zr6z970Y7ufHtlnrdzrr KL10nAKg8yh9r4sWYDl2iB007M7bKVLplQsExdh+x6Dj7O5Oiwkub523/zaa4nYu eu0HibpVgGdmi6xE547UucNCf7bOl6TPAfsbiQihwXC3HDNx9fCUb5CkzMgFlPcz l9GRhordnborQzTwTbIimMWFv/OaGwKDFW8Mn4mczGyCmCQoVx68lx8smjVfghuv lkyl/b0kz5TcaoUBzOw3 =+qSF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751396: genisoimage: -xa option not documented in man page
On further research, it appears the man page was updated to include this option (and many others, some of them aliases to already-documented commands and some previously undocumented) in upstream SVN... in January 2011. (With typo fixes in March of the same year.) However, the last official upstream release was made in October 2010. The only commits upstream since that official release are documentation updates, documentation spelling/typo fixes, a correction to a Changelog entry, and a segfault fix for icedax. That doesn't seem enough to be worth making a release over, which probably explains why upstream hasn't made one. Any chance of either updating the package to the latest upstream SVN revision, or at least cherry-picking the man-page changes into the Debian package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751396: genisoimage: -xa option not documented in man page
Package: genisoimage Version: 9:1.1.11-2 Severity: normal Dear Maintainer, According to information found via Web search, the old mkisofs supported a '-xa' option, to create XA-format ISO filesystems. (Exactly what the differences between that and a non-XA filesystem are is not clear at a glance, but testing confirms that they do exist.) Since genisoimage is descended from mkisofs, it seemed likely that it should also support the same option, but the man page does not mention any such option. However, in my testing, genisoimage does accept the '-xa' option, and does generate a different image with that option - including various obviously XA-related tags in the generated (meta?)data. Please document the '-xa' option in the genisoimage man page. It may also be worth reviewing the code to identify any other undocumented command-line options, and adding man-page documentation for any such which are found. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/12 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 genisoimage depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.18-7 ii libmagic1 1:5.18-1 ii zlib1g 1:1.2.8.dfsg-1 genisoimage recommends no packages. Versions of packages genisoimage suggests: pn cdrkit-doc ii wodim 9:1.1.11-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519469: apt-get proposes to autoremove packages not yet installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It looks like this happens when: * One version of a package is installed. * A newer version of that package is available from the repositories. * The newer version depends on a package which the currently-installed version does not. * The new-dependency package is not currently installed. * The original package is for some reason marked as "kept back" by the dist-upgrade logic, and so will not actually be upgraded. In this circumstance, apt-get incorrectly selects the new dependency for installation as a new package by dist-upgrade, even though the package version that depends on it is not actually going to be installed. It then correctly lists the newly installed package for autoremoval, because nothing that's actually installed depends on it. Here's the details of my case, from which I came to this conclusion: I run an amd64 system, with i386 enabled on multiarch. jackd1, libjack0, libjack0:i386, and libjack-dev are installed on my system. Both libjack-dev and jackd1 depend on libjack0. The newest available version of jackd1 adds a dependency on libzita-alsa-pcmi0 and libzita-resampler1, and the newest version of libjack-dev adds a dependency on uuid-dev. None of those three packages are currently installed. Due to bug 740708, the current testing version of libjack0 is not coinstallable with the current testing version of libjack0:i386. As a result, libjack0 is "kept back" on dist-upgrade, causing libjack-dev and jackd1 to also be kept back. However, the new dependencies of those packages are still selected for installation by dist-upgrade. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTXUdMAAoJEASpNY00KDJrcw8P/RDZpTVzSmB2WbQ5oFMsGKh4 SmgaT1Z93Sd1EkPXgUAZxSRn2qKRQdAUBogKnDbFlsyOThB8Fcis15h1fHbBQZ6a FGFL+YHNs7I+pRFHgpu22EUo4AbesektX5XecFMUniYeDaIlgp+vbrU2Rz+V8NGa AkrZi030VZBkCVTmaK0PDzbb4NAtUmzo1/0/aiFjqOR/kpOVblxcw5N7XfWUmdHg TtEUqmDViYkVYYO9NyWf7eU7PW6gxFNqHMHw1qVwyNwCl1xg7cIXr/nFNCdp/Nf8 yT+IjMXRzTKEDDr+gF/xJpNodHVjaXrPgi00m2Nd+h3RLnaNbolCYvGd/Bma2E6l IwRB19XpQ8HA5Pt/6JJ12arZCnNRuop44dG71ggevZxIXVID9XK7xv/070a28kqB 4YK3SQq90Hzv0gzujlj+rzbK0ujchZe+DHnxbFGZJNMleYe5b3bqgExGmglVAERd PEUTFfrrhEJbsxo8cJ2O9ARoMVDKfM/PVyhrqNSoPyPIEcNsS2n83K+yG7wlhyT7 nWgRJaeVmBC6ASjqwlEJlifunAxG3dQP1j56Xmwvm6FECp3kvQzLNddxMXTLhggD XRuGg/oMxIUqRDe9oVmxYB2/VP/o5aQMvzeLvSRKbuwldvDw+pRW+MQAgi5oNfau laP9tfl1+tORrJyjUIZ/ =cAO7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519469: apt-get proposes to autoremove packages not yet installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm seeing what looks like a somwhat less severe version of this same behavior. As it stands, I have no packages listed as candidates for autoremoval: root@apologia:~# apt-get autoremove Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded. Attempting to dist-upgrade results in candidates listed for autoremoval, all but one of which are also listed as candidates for new-package installation: root@apologia:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: librtmp0:i386 libzita-alsa-pcmi0 libzita-resampler1 uuid-dev Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: gir1.2-atspi-2.0 libatspi2.0-dev librtmp1 librtmp1:i386 libsdl-gfx1.2-5 libzita-alsa-pcmi0 libzita-resampler1 nettle-dev startpar uuid-dev Something is screwy somewhere, though I'm not completely clear on whether it's necessarily in apt or whether it might be in the dependency constellation of some other package(s). I'll hold off on completing this upgrade for a few days, in case this gets any attention and there's anything useful to be discovered from my system configuration. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTXFc2AAoJEASpNY00KDJrjXkQAIMYZLxyUdVTu7nEYi7MI5uB eHWh/mHaoCQLj1/JevECqVI9EpNvXA+SspyjTCGbmS7XCOddPKnAMNT3f5iYwa3/ 4YAdiQdBfRZgWX3SICi4CDz2ZwPdjjX0SYiX5kq4Dzk90sbZJg0k651xkQJH5cPm XHPXwZ/udFcqAQ1wwmOkTaNe4saX09K9s3/W2V8Q6SjPRb6T4lSwatlYAI/0Q5Pq y5li1x3kNazGI2Cqahn3/w7FnFehg/pBx1a7VZ0m6DKfP0Oa3MAPYxzt+aczLUaO gurPXPHMvnrxS3/Udq7wuzqBkk13Znx0udGMt2zItFF7KPJPSewLG+pkulj6DecO KndjDxFXX63q6Bh6XCUMgNjYN+F/WDdAXTLtITZnnd4ZmTgj6ekO3sOqaTfdVAx+ 0uPhRhPJgMMxvoDybJJRIPHu5m9m/M/mz4bAmBiVoOauu3ONBMlwLTgGvf9tLIpS 1M31DQJYBB7qt244JN4gYScyc4ay8xM83RWMJibZ3rC0/myGrlz1L9q5NJnEJuZE 5jnWsHhYrhithKDfh85BXQhFN6+b2lWC/rT9W78AC9CBO4/AuAgnlxJCWRerFZCH 7tZW1RodOLjjB1jWhBF+4jM3lRzFBL/46pyBIXN1K0W9eD2wqnXYyNj/0TH06L30 fWIsPwTlKY670Snp+gOZ =D13N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741843: [help] volview: FTBFS: vtkKWWizard.cxx:162:51: error: 'Tcl_Interp' has no member named 'result'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/15/2014 04:07 PM, Andreas Tille wrote: > Hi, > > is there any kind C++ capable soul who could provide a patch for this > problem? A bit of Googling seems to indicate that this is due to building against Tcl 8.6: https://bugzilla.redhat.com/show_bug.cgi?id=902561 As a short-term thing, you can probably get it working by either adding - -DUSE_INTERP_RESULT to the CPPFLAGS at build time, or patching some appropriate internal header to include the same define - or possibly by explicitly build-depending on tcl8.5-dev, though I don't know enough about Tcl or its packaging to speak to that approach. In the long term, as the link indicates, the correct fix would involve modifying the source to avoid using internal fields from Tcl_Interp. However, that seems like the sort of thing that would be best done by upstream. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTTZZdAAoJEASpNY00KDJrFMwP/1RPRb8PkbiNmRuegI8aT63b yrt3s+iKF8fAC9XsPpYI+J5I7VlnEz97B4Rf1/vBYx2R/HBjJE7FxSAJiPUoKz0J Eqgo0evIaVKdOFFLydAPbbEz9jswyZRDtXCYwBD1gXNjTMayOvZ/X2TLmvlPTOCD BJChOuA57lIUPsXfvaacQPQeu2rqX0WOrHp9NEZMaPRU3j5w1nHKKzgkYaDgYTii gWMaWaO1WStGTw++N6pKKLeFBHTIgJ2oKr/pX7HtmQwS3TXDZFL0PGT/ixxghut5 o+0+cwRdlVTOdZIhU2c5ALFvb7Jbmq7SPkoA66HxhR5pV9Ds3Cj0dQrclpUpw2jv /HvPYw9y1Q1YLMHCjOz1xLSYf6HPSZmMLb/xmSwkdjdhorcoK/dqsmZQrlvBxpdM 0ZCBXvyxUcmPbwjz9wYqd3wO7hjdnujhlFf5Hyt0CJ+/27Iuo4Bwe5u5SOatDpuy LmKnEtp9tllqgEvwMZt+HjX44auL02TxDoX9mkfh/wXOg5t3i0G4oIDvL2lzMduT iA+OQjPtAEJcgwkiQZdm1KZicvKX/7ftOSaBlNybWXw0wLciU+cD8yXanHGc3nQ+ J8zFpPOFo18LYcCas8TnvsaNTci5pUI2vLtjGJ8DFK+4A6YU9Xn1UPBmEyrhnNyV bXwaasScwv3qGuIwdKkU =xeha -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737208: RFS: linuxlogo/5.11-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2014 02:46 AM, Dariusz Dwornikowski wrote: > I do not want to close old bugs. Just asking, what will happen with > bugs for older versions that e.g. are not used anywhere no more? Will > these bugs hang forever or is there a cleaning policy ? Whether to close a bug has, AFAIK, nothing to do with whether the version it was reported against is still in use. It's entirely about whether the bug exists in current packaged versions. If the bug is still valid - meaning, mostly, if the behavior described in the bug A: is in fact considered a bug and B: still exists in the current version - the bug should remain open, even if that means remaining open forever. If the behavior described in the bug no longer exists in the current version, but for some reason the bug wasn't closed when the fix was first released, then I'd imagine that the bug should be closed manually (with a comment explaining that the bug is know to be fixed as of such-and-such a version). In the specific case of the bug you tried to close (twice) in the changelog which led to this subthread discussion, the correct thing to do is not clear at a glance. This is because you gave two different explanations of why you were closing it, and the two explanations disagree with one another. One explanation was "upstream won't fix". This seems to imply that the behavior described does still exist in the current packaged version, and that upstream has refused to change it. I believe that would be handled one of two ways: * Decide that the behavior described isn't really a bug after all, and close the bug report. * Decide that the behavior is a bug, and leave the bug report open to reflect the fact that the behavior still exists in the current packaged version. The other explanation was "not relevant anymore". This seems to imply that the behavior described no longer exists in the current packaged version, but that for some reason the bug wasn't closed when the change actually occurred. I think that in that case, the correct thing to do would be to close the bug report manually (not via a changelog entry), with a comment explaining that the bug is known to have been fixed sometime before version Such-and-such. I'm not an expert on these matters, however. I hope that helps. (And that I haven't gotten anything wrong anywhere.) - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS9Y2HAAoJEASpNY00KDJr1yoP/AxDl1Xxx97kIL2QyDsoRUQ3 lhHWR2cZFmFtiUbdRpKRwzwcUj2IU2IUtphP+30y6EzI82YYXkrKJvYHEBt6kMWg tW68HYhA9lXEtPEq/QMP4tkfEhTAoDg5WaDUK2aG0TmAOq0+UK5sC+xrM24YdTxu 8BcqDki12nFH51RKzdG2lhhvkGmKPQmL6T4/jB8xCasCPWGlgu4ZGjdtDTRLbrXn FgVfIBigDmvSn9yEZrlvJiSReE3Prv8CzUi3vSg6UvNMRfQoGkj1sA8/+X++AoMW twS2Gyj0YqN3QSk/m+/LUo7Ft4DTOZCtpa4ffOHYNl9C/6VsbWO67VN/RbsWhWmM vaFPGHf98THd6gGiFAYvLGjpzUZ8bmvxhBApgx0/9l1wx1VjHRdnd6TsemAuvUVy /Wph8wpu0xvxCtE+TLRRoLDoRERpKZbvafrLPm07VcBuXr3uDWHv6ZOEY3CwI0WG bp/+/4mCE27wP6ji01BuIzqItQ4pJVaRQ4eqRW3mGcSwCU3r3Tb0om7zTrYocfxG b2xK8SWPbJzbW4GlKvSkt7nF/fxVBp4y40b71qPicx0UDK/R4fEVzmS/Otn9LXtS PLSMLa+3VXXCCDTwSEG8yuDJA+c8aA2ARh/+uR+opCdK2GVjnj3fzmShuj21FNAu +tGpbUfClzj3uG0gqDL/ =brz9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/25/2014 05:24 AM, Johannes Schauer wrote: > Hi, > > Quoting The Wanderer (2014-01-22 15:14:34) > >> Do things still work fine in Debian when using ld.gold (by >> installing the binutils-gold package) rather than ld.bfd? I know >> there's an important difference in ld.gold related to --as-needed >> (or possibly to - --no-as-needed, I don't recall offhand). > > I dont think the binutils-gold package exists anymore. binutils-gold > seems to be provided by the binutils package which now seems to ship > /usr/bin/ld.gold I hadn't noticed, but you're right, it's only in stable now. (Even the stable package claims that it only installs the diversion of ld to ld.gold, so it's possible that ld.gold was always provided by binutils directly; I haven't dug into the history here.) That might mean my attempted recall was wrong, or that plans have changed since the last I heard about it. It's still probably good practice to make sure things build both ways, though. > Do you happen to know an easy, undisruptive way to test with ld.gold? That depends. The most general way I can think of would be to set up an alternatives group for ld, define ld.bfd and ld.gold as the two alternatives, and then switch back and forth in between tests; however, that's a system-wide change, which might not qualify as non-disruptive. Depending on your package's build system, there might be a configure option or an environment variable to specify what ld to use. That would be non-disruptive, since it's local rather than system-wide, but it's also not universally applicable. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS46qkAAoJEASpNY00KDJr6RMP/i2y/d+ob0fGrU1MrowLPJ48 8w25wSwOxwUWBsm8cck9qSMfB/qgF2lythw4utfPi+LUO0cj7+evTpDJjtcewwJs u4q3mE+HpzWTmkYaD9gZXiKKJiaXx/Uf8QNuob+2kIkesI4QxPNzOnqREvrf/vP/ U+0UwHTwMti80ZFzFWxasMfxNqFyii64vMoYPFx1CkUCYBXwDI8br++xsDOT8yW6 rK3kab1h9VIS+glpTbM+DZBvlVt/1XDQkb10UqK5myIvzvtc99nMunvu7lRuN6wL 7BtwYbGC5vx6y25sNpsumJKBHNyK99vyXAB7xGPuxZ5RWJwd81R5NyE3SDtQ/+OA lA7WWmuOqYxcK2Rkd9r+EEsiaKLqUnUCOvXL/wZQS8SwbuLTyD2rKgCHGendBeU4 RyATKI3gndC1LR226Su7gkx/FhRE5ZGsyx2Re9OEWt4MuVRijOwDhNM1YJX59XlA UiCbMGkfX/zG3p/l4HYuj/TIYlXxxWxXCj/IJfDvh0QAI3Gdr2jbciQYiSWTJHQ7 6MzlAnkbn3M7PJC2BKfIilVufeQmln6SOvTe7JvHD1bQbWZ512RDhAAaA7NQxB4L 2OogGzLQg7nLheVFzaWJAEULqDzuHMCXsC8iItNtUX55JrvAG7pp1sKAFWjoYeCl oA8qeUxdwVseS1C2krN+ =817s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/22/2014 05:12 AM, Johannes Schauer wrote: > Hi, > > Quoting أحمد المحمودي (2014-01-22 10:36:11) > >> Actually what happens implicitly (at least on Ubuntu precise) is: >> $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ >> >> which causes the compilation to fail, because the -l<...> should be >> after the object files (or source files in this case). > > Ah funny, so it's a ubuntu problem. I did not observe this problem > with Debian unstable. > > After trying it out myself in a ubuntu precise and saucy chroot and > asking on #debian-mentors, the reason why this error happens only on > Ubuntu seems to be: > > https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed > https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition > > Should I contact upstream to yet again change his makefile or are > things okay as they are because everything works fine in Debian? Do things still work fine in Debian when using ld.gold (by installing the binutils-gold package) rather than ld.bfd? I know there's an important difference in ld.gold related to --as-needed (or possibly to - --no-as-needed, I don't recall offhand). I seem to recall that there are long-term plans to switch Debian over to ld.gold or to produce the same effect in ld.bfd, and that it's recommended (or at least preferred) to make sure your package builds with the gold linker; I suspect that this is the "similar change... being discussed for Debian" mentioned in the ToolchainTransition article you linked. There's no expected completion date for this AFAIK, but trying to be compliant with it isn't a bad idea; I've already got the upstream of something I haven't even packaged yet to accept a compliance patch, just based on test packaging attempts. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS39JJAAoJEASpNY00KDJrqYQP/0GBnMOtwgXJwbDIj/qskRr0 En2lnuVM76ua/xb4iYCrbmeQ3APnwJ8pqrJ2oSozuA+A1244TAiXgzf/iLFCZ+JI 2sID3uMLf8+rrXnVs0FFKNEuNHAVYLSi9TxF1Ptlpai1YFwasGU5MrEr13kthrD+ RgQ0+3HWxJ29aNo4yR90SxK8zADjjm0bggJlwI8ltGaWxKMPZsfZSs12f19lMSe+ UpIT0vISg724mlsU3i31+rUIrfnAm+AlrVzX0j5H6p5gkp6o1+IKsmi9LBQviCJh sBZ85Eq7LvZpfWpErf1FBXVRlnosuBC/P/S8XfJhTQP5owDLqOO5ot33IKb128f0 /MmoiT0xe/KjlKnqcLg0Mru90HmNkm1VY0ZKuojJfc1n/OcMg+IX8UrjGCTSnjSW bV7CpT2eYFj6ikbSNcLGBWEy+zllppWaBXIB5K+c3NJ++oc1VHN88/lKlmL36d07 BKPiMA1qoyGbdbpr9dLbCXL8QVgOS9ZblMXRimZjsYhDDM4DzZq6pMheTorfCUR3 9wzGL40K1tE4MNm/j2gfKaYTKauw1u+EI70CPX6+jFECmWqAsL0grDHvMlavZfvN JmoxhwsH6WHldkrhjih1VcglJ84AZCB/wllxsRRI0+ULt7yo4X7966y+0AFi57la 5xw2Zvg+Asg22VMaA1cy =AeaL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730737: dizzy: exits immediately with "strict refs" error in Perl2GLSL.pm, line 160
Package: dizzy
Version: 0.3-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
When I launch dizzy, it briefly displays a black window, then exits. The
following is printed to the console:
Smartmatch is experimental at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 17.
Smartmatch is experimental at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 183.
GPU features: [x] GLSL [x] FBOs
Can't use string ("# op description list of private"...) as an ARRAY ref
while "strict refs" in use at /usr/share/perl5/Dizzy/Perl2GLSL.pm line
160.
I have a local modification to /usr/games/dizzy, to make the '-f'
(fullscreen) option work; this was reported as bug 697423, and appears
to be fixed under that bug, but the fixed version has not yet been
released AFAICT. I have tested without this modification, by way of
'apt-get install --reinstall dizzy', and the present problem still
occurs.
I am reporting this as grave because it renders the package completely
unusable for me, and I have no reason to expect the behavior to be
different for anyone else. If it still works on a fully upgraded system
tracking testing for anyone else, please feel free to downgrade this to
normal.
Note that this is the same version of dizzy as was working at the time
of bug 697423. In the interim I have dist-upgraded multiple times to
track testing, and I am at present up-to-date with testing as of early
this afternoon. I do not know specifically when it stopped working.
Although I do not use dizzy often, I still like having it available. If
there is anything I can do to help track this down, please do not
hesitate to let me know.
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-3-amd64 (SMP w/12 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 dizzy depends on:
ii libconvert-color-perl 0.09-1
ii libopengl-perl 0.6702+dfsg-2
ii libsdl-perl2.540-3
ii perl 5.18.1-4
dizzy recommends no packages.
dizzy suggests no packages.
-- debconf-show failed
-- debsums errors found:
debsums: changed file /usr/games/dizzy (from dizzy package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730730: youtube-dl: long description lists 'youtube:search' twice
Package: youtube-dl Version: 2013.11.11-2 Severity: minor Dear Maintainer, The long description of youtube-dl (as seen with e.g. 'apt-cache show') includes a list of sites which the program supports. In version 2013.11.11-2, the entry 'youtube:search' now appears in this list twice. A previous version (I believe 2013.10.23-1) included it only once. It seems unlikely that this duplication is intentional. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/12 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 youtube-dl depends on: ii python2.7.5-5 ii python-pkg-resources 0.6.49-2 Versions of packages youtube-dl recommends: ii ffmpeg 6:0.8.9-1 ii libav-tools 6:9.10-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 ii rtmpdump 2.4+20121230.gitdf6c518-1 youtube-dl suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723107: less: search history no longer contains new blank entry from current search
Package: less Version: 458-2 Severity: normal Tags: upstream Dear Maintainer, When beginning a text search in less by pressing the '/' key, you are presented with a blank line to type your search string into. It is possible to scroll backwards and forwards through the search history, in order to repeat a previous search (with or without modifications). The behavior of this scrolling at the "bottom" of the list has changed, in a way that I find both unintuitive and undesirable. Steps to reproduce: * View a file in less. * Press '/' to display a blank search line. * Press the Up arrow to display the most recent search string. * Press the down arrow. Expected result: The original blank search line is displayed again. Actual result: The screen flashes in the manner of a "system beep" event, and the displayed search string does not change. It is useful to be able to easily return to a blank search string, for example in order to quickly and conveniently cancel the search without changing the displayed search results. It is also not intuitive that "up then down" does not return to the original location. This behavior change appears to be a side effect of an intentional change: the ability to scroll through only search strings beginning with a particular prefix, by typing that prefix before pressing the Up or Down arrow. I am not positive, but I believe this was introduced in less version 449. Please restore the blank "current search" entry in the less search history. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/12 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 less depends on: ii debianutils 4.4 ii libc62.17-92 ii libtinfo55.9+20130608-1 less recommends no packages. less suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714820: ITP: ntopng -- High-Speed Web-based Traffic Analysis and Flow Collection Tool
On 07/06/2013 09:14 PM, Ludovico Cavedon wrote: On Wed, Jul 3, 2013 at 5:00 AM, The Wanderer wrote: Might I suggest a different package name, e.g. 'ntop-ng'? At a glance, 'ntopng' reads to me as "N-to-PNG", along the lines of existing file-format converter programs. While it's not absolutely necessary to avoid that, if there's no real downside to doing so, it might be a good idea. Good point about the double interpretation, I did not think about it. However, given that there is no real conflict, I would like to keep the name as close as possible to upstream. Just to be clear, making sure we're on the same page: I'm certainly not proposing changing the name of the actual program; I'm only proposing changing the name of the package. For comparison, a program which upstream calls 'calc' is available in the package name 'apcalc', even though there is no package named 'calc'. (I don't recall whether or not there used to be.) If that would also be too much of a change from upstream to suit your preferences, then fair enough. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714820: ITP: ntopng -- High-Speed Web-based Traffic Analysis and Flow Collection Tool
On 07/03/2013 02:45 AM, Ludovico Cavedon wrote: Package: wnpp Severity: wishlist Owner: Ludovico Cavedon * Package name: ntopng Version : 1.0 Upstream Author : Luca Deri * URL : http://www.ntop.org/products/ntop/ * License : GPL-3 Programming Lang: C++ Description : High-Speed Web-based Traffic Analysis and Flow Collection Tool ntopng is the next generation version of the original ntop, a network traffic probe that shows the network usage, similar to what the popular top Unix command does. ntop is based on libpcap and it has been written in a portable way in order to virtually run on every Unix platform, MacOSX and on Win32 as well. Might I suggest a different package name, e.g. 'ntop-ng'? At a glance, 'ntopng' reads to me as "N-to-PNG", along the lines of existing file-format converter programs. While it's not absolutely necessary to avoid that, if there's no real downside to doing so, it might be a good idea. I'm also not sure how good "-ng"-style names are in the first place, unless you are positive that there will never be a future "next" generation after this one; a name like "ntop2" would be more forward-development-compatible in that light. But that's just my principles speaking, not a source of present confusion. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711961: libglib2.0-0: causes iceweasel 3.5.18-1 to SIGABRT on launch
Package: libglib2.0-0 Version: 2.36.1-2build1 Severity: normal Dear Maintainer, I want to first note that I am intentionally using a configuration which may be unsupported. However, just in case the problem I am encountering might be relevant independent of that potentially unsupported configuration (and/or might get fixed anyway), I would like to report it regardless. I am running iceweasel version 3.5.18-1, which was the version available through the then Debian stable when I intentionally reverted to the 3.x series. I am working on resolving the issues which impede me from satisfactorily updating to a more modern version, but I am not there yet, and depending on other priorities may not get there any time soon. With libglib2.0-0 version 2.36.1-2build1 and its dependencies, this version of Iceweasel dies on launch with the following error: GLib-GObject:ERROR:/tmp/buildd/glib2.0-2.36.1/./gobject/gobject.c:4127:g_weak_ref_set: assertion failed: (weak_locations != NULL) I previously managed a GDB session which provided a backtrace indicating that the call chain for this this came through pango, but since then I've been unable to get the program to run in gdb to reproduce that backtrace. Given the lack of debugging information included, it's not clear that the backtrace would have helped anyway. After downgrading to libglib2.0-0 version 2.33.12+really2.32.4-5 and its dependencies from stable (including a number of libpango* downgrades and/or removals), this version of Iceweasel works fine. While this constitutes a regression, it is not clear whether that regression would only affect outdated software such as this or might potentially manifest for something more up-to-date. I'm reporting it on the possibility that it might be the latter, and so might get fixed; though I can hope, I do not really expect it to be fixed if it's the former. If this is sufficiently worth pursuing for further information to be desirable, please let me know what to provide. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710140: gpgme1.0 (>=1.3.2) dropping libgpgme-pth.so
apt-listbugs alerted me to this bug when I attempted to upgrade from 1.2.0-1.4. I can't tell from the information provided: if I upgrade to an affected version, should I expect things on my system to break? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
