Bug#1065768: libauthen-krb5-perl: FTBFS on arm{el,hf}: Krb5.xs:1040:17: error: implicit declaration of function ‘krb5_free_address’; did you mean ‘krb5_free_addresses’? [-Werror=implicit-function-dec
gregor herrmann writes: > I'm by far not any expert on C code and gcc flags; but yes, given the > above findings and unless someone more knowledgeable steps up in the > next couple of week, I think we have to remove libauthen-krb5-perl (and > libauthen-krb5-admin-perl). Authen::Krb5 has a bunch of stuff that dates from the pre-GSS-API era of Kerberos, and there were other things that at one point got me to start writing my own version of the same idea (although alas I never finished). In theory, one could delete the pieces of the module that try to do things that no one should really be doing from Perl and the rest of it remains somewhat useful, but given that upstream has archived the project, I would go ahead and remove it. Maybe someday I'll dust off and finish a proper Kerberos Perl module that uses the modern C API. In my copius free time. :) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1042853: docknot: FTBFS with Perl 5.38: t/spin/errors.t failure
gregor herrmann writes: > On Wed, 06 Sep 2023 08:21:24 -0700, Russ Allbery wrote: >> gregor herrmann writes: >>> According to https://github.com/rra/docknot/issues/6 fixed upstream >>> (in git, not released yet). >> Yeah, I'm sorry about the delay here. I'm trying to get a new release >> out shortly and if I fail at that I'll patch this in the Debian >> package. Please feel free to move forward with Perl and don't block on >> this package; this is totally my own (known) problem. > in the light of #1055955 (perl5.38 transition bug) -- do you think > you can upload a fixed version (the current version plus a patch or a > new release) in the near future, or should I upload an NMU with your > upstream commit or should we just ignore docknot for the transition … > or something else? :) I've uploaded a fix; I'm so sorry for the absurd delay. I'd meant to get to this months ago and kept not making time to finish it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
"G. Branden Robinson" writes: > How about this? > \- Minus sign. \- produces the basic Latin hyphen‐minus > specifying Unix command‐line options and frequently used in > file names. “-” is a hyphen in roff; some output devices > replace it with U+2010 (hyphen) or similar. Sorry for my original message, which was very poorly worded and probably incredibly confusing. Let me try to make less of a hash of it. I think what I'm proposing is something like: \- Basic Latin hyphenminus (U+002D) or ASCII hyphen. This is the character used for Unix commandline options and frequently in file names. It is non-breaking; roff will not wrap lines at this character. "-" (without the "\") is a true hyphen in roff, which is a different character; some output devices replace it with U+2010 (hyphen) or similar. What I was trying to get at but didn't express very well was to include the specific Unicode code point and to avoid the term "minus sign" because this character is not a minus sign in typography at all (although it is used that way in code). A minus sign is U+2212 and looks substantially different because it is designed to match the appearance of the plus sign. (For example, the line is often at a different height.) I don't know if *roff has a way of producing that character apart from providing it as Unicode. The above also explicitly says that it's non-breaking (I believe that's the case, although please tell me if I got that wrong) and is more (perhaps excessively) explicit about distinguishing it from "-" because of all the confusion about this. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
Minor point, but since you posted it "G. Branden Robinson" writes: > ... > \- Minus sign or basic Latin hyphen‐minus. \- produces the > Unix command‐line option dash in the output. “-” is a > hyphen in the roff language; some output devices replace it > with U+2010 (hyphen) or similar. The official name of "the Unix command-line option dash" is the hyphen-minus character (U+002D). Given how much confusion there is about this, and particularly given how ambiguous the word "dash" is in typography (the hyphen-minus is one of 25 dashes in Unicode), you may want to say that explicitly in addition to saying that it's the character used in UNIX command-line options (and, arguably as importantly, in UNIX command names). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: Hyphens in man pages
Wookey writes: > I was left not actually know what - and \- represent, nor which one I > _should_ be using in my man pages. And that seems to be the one thing we > should be telling the 'average maintainer'. - turns into a real hyphen (, U+2010). \- turns into the ASCII hyphen-minus that we use for options, programming, and so forth (U+002D). I think my position at this point as pod2man maintainer (not yet implemented in podlators) is that every occurrence of - in POD source will be translated into \-, rather than using the current heuristics, and people who meant to use ‐ should type it directly in the POD source. pod2man now supports Unicode fairly well and will pass that along to *roff, which presumably will do the right thing with it after character set translation. Currently, pod2man uses an extensive set of heuristics, but I think this is a lost cause. I cannot think of any heuristic that will understand that the - in apt-get should be U+002D (so that one can search for the command as it is typed), but the - in apt-like should be aptlike, since this is an English hyphenated expression talking about programs that are similar to apt. This is simply not information that POD has available to it unless the user writing the document uses Unicode hyphens. I believe the primary formatting degredation will be for very long hyphenated phrases like super-long-adjectival-phrase-intended-as-a-joke, because *roff will now not break on those hyphens that have been turned into \-. People will have to rewrite them using proper Unicode hyphens to get proper formatting. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1041731: groff-base: "-" mapped as HYPHEN
Guillem Jover writes:
> On Mon, 2023-08-14 at 14:18:51 +0200, Samuel Thibault wrote:
>> Yes, we'd ideally want to fix all manpages to have everything set
>> alright. But we have to do that before the release. And if that's not
>> complete, release with the
>>
>> .char - \-
>>
>> workaround.
> Whenever I've maintained man pages in roff I tend to be precise in
> the usage of - and \-, but TBH this has seemed like a lost battle,
> more so since at least lintian stopped emitting tags for it. And
> another problem which I think it's going to be very hard to fix is
> with man page generators from other formats, such as pod2man, where
> it currently has heuristics to determine when to use - or \-, but it
> does not currently has a way to accurately do this always.
Yes, I understand why upstream really wants to find a way to make the
distinction between a language hyphen and an ASCII hyphen to work. They
are different characters in the *roff language, and in a proper
typesetting system such as troff is intended to be, it is important to
distinguish between them for the best output.
That said, I was surprised to see the attempt to go down this path again
given how many problems we had the last time, and I am quite dubious that
we will be successful. Not only is this a fiddly point of *roff that a
lot of people writing man pages simply don't pay attention to, man pages
are also generated from a host of other formats that simply do not have
this distinction in their language and therefore *cannot* make this
distinction in generated *roff except by guessing.
Just to give you an idea of the sort of thing that I'm trying to maintain
in order to be "correct" about this distinction, here is the current code
from podlators:
s{
( (?:\G|^|\s|$NBSP) [\(\"]* [a-zA-Z] ) ( \\- )?
( (?: [a-zA-Z\']+ \\-)+ )
( [a-zA-Z\']+ ) (?= [\)\".?!,;:]* (?:\s|$NBSP|\Z|\\\ ) )
\b
} {
my ($prefix, $hyphen, $main, $suffix) = ($1, $2, $3, $4);
$hyphen ||= '';
$main =~ s/\\-/-/g;
$prefix . $hyphen . $main . $suffix;
}egx;
This is still obviously buggy, though. For example, command names
mentioned in the text look like words with hyphens and I don't think
there's any real way to tell the difference.
I have to admit that I am somewhat tempted to at least make this
transformation optional and instead let people configure pod2man to simply
escape every single - character as \- in the output. This is not
"correct", but I think it's more correct than what is happening now, and
it's at least consistent. However, I have a note that I have to do this
translation or *roff will produce unacceptable output, and I don't
remember what problem there was that made me write that comment in the
first place. Maybe the problem with breaking long lines with
lots-of-words-that-are-all-conncted-by-hyphens, although that's somewhat
rare.
My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
Adrian Bunk writes: > The image creators could just set the features they enable to what they > copied from /etc/mke2fs.conf from the target distribution, a label with > a timestamp wouldn'tbring much benefit here. That's a very good point and I'm embarrassed it wasn't immediately obvious to me. Sorry about the noise. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
"Theodore Ts'o" writes:
> As a long-term solution, one could image changing the various image
> creation tools to do something like "mfks.ext4 -T grub2_dumbdown
> /dev/XXX", and then have something like the following in
> /etc/mke2fs.conf:
> [fs_types]
> grub2_dumbdown = {
> features = ^metadata_csum_seed,^casefold
> }
This is considerably more specific than what I had in mind, but maybe I'm
misunderstanding the problem. Here's a slightly more fleshed out version
of what I was thinking:
mke2fs when run without any options has some default upstream-shipped set
of options that it enables (possibly via the upstream-shipped mke2fs.conf,
possibly in the binary, however it works). Those defaults presumably work
with the kernel and other system tools shipped at the time, due to the
normal compatibility due diligence that you'd naturally do while doing
file system development.
When you make changes to the *defaults* (not just the addition of any
options in general), this presumably is also aligned with what you think
is generally supported by other system tools at the time.
Each time you change the defaults in a way that could be
backward-incompatible, you could capture those new defaults in a
permanently-fixed label of, say, 20230616, which is the defaults on that
date. Probably in the default /etc/mke2fs.conf. I don't expect you to
care about what systems they work with, what distributions they work with,
or anything else other than the timeline of when you decided to change the
defaults, something you're presumably already doing as a maintainer. The
only additional work would be to update these labels with the settings
required to make mke2fs with its current defaults behave compatibly with
whatever the defaults had been at each of those captured points in time.
(And obviously eventually you could drop the really old ones if it made no
sense to keep supporting them, or have some single really-ancient fallback
for really old systems, etc.)
Then, image creators can look in /etc/mke2fs.conf for the timestamp that
most closely aligns with the target system they want to create and use
that group of settings. If that turns out to be inadequate, they can go
back to a previous date. Some work on their part is still required, but
from their perspective I think this would have the advantage of not having
to do research to reconstruct what all the options could be and how they
changed and which ones were potentially backward-incompatible, which are
all things you would generally already know and have in mind when you
changed the defaults and thus could capture for them.
That said, this is an architectural stab in the dark and I obviously don't
work on file system development, so maybe this isn't viable for some
reason that I'm not seeing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
Sam Hartman writes: > * Anyone could prepare patches to image building software to use mkfs > options that will work with bullseye. You could also try to prepare > patches to run mkfs out of a chroot or container of the guest OS for > the image. I appreciate Russ strongly favors this solution, but as > someone who has dug into image building tools a fair bit over the > years, I think there are significant complexity and performance > downsides to that approach. I also think that changing the mkfs > options is more likely to get an unblock than changing the structure > of how the tool works. Yes, I'm probably understating the difficulty of making this change in practice inside image building software as it's currently constructed. My concern about changing mkfs options is that I worry that this would be a constantly-changing target that has to be synchronized across multiple pieces of software that are not currently well-aligned with file system development. One thing that would make this much easier would be for mkfs to support some sort of compatibility level flag that sets all of the options, whatever they may be, to their defaults as of some point in the past. Image building software could then pick a conservative default set point when building images for older distributions. That change still has to be added to all of the image building software, but it might be easier than building a local chroot of the target distribution before using it to build the file system the actual installation is going into. I suspect this won't be Ted's favorite option because this isn't a natural way to think about the option space from a file system developer perspective, but maybe we could find some compromise along those lines? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
"Theodore Ts'o" writes: > On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote: >> You argue about shared libraries for non-packaged binaries. I think we >> mostly don't care about that, and again, I think that's at least a >> generally recognized thing that came out of our focus on packages and >> package dependencies. > Note that package dependencies doesn't allow a binary created on Debian > N to work on Debian N-1. It just *prevents* the package from being > installed on Debian N-1. If you care about allowing the package to be > instaslled on Debian N-1, that's what build chroots are for. That's how > we create packages for backports, after all. > I'm making a similar argument for mkfs and bootable images for older > distributions. Just as you use a build chroot when you build a package > for Debian N-1, you should use a chroot when building a bootable image > for Debian N-1. And that means using the chroot for *everything*; not > just installing the grub bootloader, but also running mkfs. Regardless of which analogy feels more correct here, the reality on the ground is that using a current mke2fs to create file systems for older Debian versions, unlike running new binaries on old systems, is something that used to work. People have been doing that and relied on it working. We've made a change that broke it. That change has benefits and justifications as all changes do, but from the perspective of the people with that use case, it's a regression. So we should either document it or revert it, and I think the debate is over which of those two to do. Ideally we do this with an eye to what reduces this problem in the future. It had never occurred to me before that the version of the system on which I run mke2fs would matter as long as I didn't pick a newer file system type (ext5 or something). Now I know! Until today, I had no idea ext4 even *had* "incompat" features or that mke2fs could make file systems that grub couldn't understand. I'm sure this is well-documented in the ext4 world (although ext4(5) could both be advertised a bit more prominently and be more explicit about this problem, IMO). I'd just never had any reason to seek out that documentation, since creating file systems with the defaults has always just worked for me. In that sense, it's a testament to the maintenance quality of ext4, but the result of mke2fs just working all these years is that most users do not read the details of the ext4 man page since they've never needed to. That would make me lean towards making documentation a large part of the solution here. I'm sure I'm not alone in having no idea that the version or configuration of mk2efs mattered at this level unless I'd changed the defaults. It seems like we'd save people a lot of future trouble if we could find ways to communicate to system constructors that the file system needs to be built from a chroot. In other words, if this is a compatibility rule that is important when using these tools, it needs to be WAY more prominently documented than it is right now. That that feels more important to me than adding a one-release backward-compatibility guarantee. A lot of environments regularly use oldstable or even oldoldstable for specific applications, so we'd still break people's use cases if they don't know about the need to build file systems from a chroot. Given that this will presumably happen again in the future since it's apparently a normal part of ext4 development, it's not a one-time problem and it's something that we somehow have to communicate to users to avoid ongoing fragility. It feels to me (not a release team member!) like the strongest argument for making a change other than documentation is the proximity to the release at which the change was made (which is indeed quite late in the release process for this critical of a component of the operating system). But I'm also not sure that matters to most of our users? I think most users are only going to care when stable is released; people doing production work on unstable or testing already know that they're signing up for occasional breakage. So the proximity-to-release argument to me feels most relevant if this change is specifically a problem for the release process and would hold up things Debian itself needs to do, due to (for example) it being difficult to change tooling so that file systems are generated from a chroot. I have no idea if that's the case. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1022791: tripwire --check segfaults on startup (probably needs rebuild)
Package: tripwire Version: 2.4.3.7-4+b3 Severity: grave X-Debbugs-Cc: r...@debian.org Looks like tripwire needs another rebuild against the latest libc6. tripwire --check and tripwire --init both segfault once they start analyzing the file system. Rebuilding the package with no changes causes it to work again. (This is probably the standard problem with statically linked binaries loading nsswitch modules from libc versions other than the one that they're statically linked with.) -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tripwire depends on: ii debconf [debconf-2.0] 1.5.79 ii postfix [mail-transport-agent] 3.7.3-2 tripwire recommends no packages. tripwire suggests no packages. -- Configuration Files: /etc/cron.daily/tripwire changed [not included] /etc/tripwire/twcfg.txt changed [not included] /etc/tripwire/twpol.txt changed [not included] -- debconf information: * tripwire/installed: * tripwire/rebuild-config: true tripwire/change-in-default-policy: * tripwire/rebuild-policy: true * tripwire/use-localkey: true tripwire/upgrade: true tripwire/local-passphrase-incorrect: false * tripwire/use-sitekey: true * tripwire/site-passphrase-incorrect: true tripwire/broken-passphrase: tripwire/email-report:
Bug#1017739: emacs-lucid cannot start after upgrade
Control: severity -1 important Adam Lackorzynski writes: > I had the same issue. Turned out my personal .emacs.d/eln-cache > directory and its folders belonged to root: > $ ls -la $HOME/.emacs.d/eln-cache > total 16 > drwxr-xr-x 4 root root 4096 Aug 21 19:32 . > drwx-- 4 adam users 4096 Aug 19 19:43 .. > drwxr-xr-x 2 root root 4096 Aug 21 19:32 28.1-20961986 > drwxr-xr-x 2 root root 4096 Aug 19 19:43 28.1-aa5da5cc > chown'ing it to me fixed it. Oh, good catch! The same thing was true of mine. I think the dates were when I upgraded Emacs. Let me take a guess: are you also old-school and use su from a regular user account when installing new packages? HOME gets overridden by su, but LOGNAME and USER do not, and I suspect something in Emacs is deciding where to write files based on USER, and the installation process of emacs-lucid creates the eln-cache directory for some reason. I'm downgrading the severity of this bug because I suspect the average user using sudo may not run into it (although the maintainer should feel free to raise the severity again if they disagree). If I'm right, the best place to solve the problem may be in the Debian maintainer scripts, overwriting USER (and possibly LOGNAME, not sure if it matters) to some safe value like root while performing the installation. This may also be necessary to do when installing Emacs add-on packges; I'm not sure. I've removed the directory with the wrong ownership and upgraded again with USER and LOGNAME set to root, and now everything works fine. (Well, my laptop gets extremely hot the first time I start the new Emacs, but I assume that's expected for the new compilation system.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1017739: emacs-lucid cannot start after upgrade
Stefan Monnier writes: > I don't know why it fails to find a writable directory. Maybe > emacs --debug-init` would help > or > emacs -e '(message "%S" comp-native-load-path)' > might help track down the origin of the problem. % emacs --debug-init Cannot find suitable directory for output in ‘comp-native-load-path’. % emacs -e '(message "%S" comp-native-load-path)' Cannot find suitable directory for output in ‘comp-native-load-path’. If instead I run: % emacs -q --no-site-file -e '(message "%S" comp-native-load-path)' then Emacs opens a window and starts, but just produces the error message: command-line-1: Symbol’s function definition is void: \(message\ \"%S\"\ comp-native-load-path\) Trying to run the same elisp with M-: in that running Emacs just says: defalias: Cannot find suitable directory for output in ‘comp-native-load-path’. Looks like I may need a build with your patch before I can figure out what's going wrong with that variable, since Emacs seems to be so broken that it doesn't know how to introspect itself. I'm a bit mystified as to why everyone else on Debian isn't seeing this. I would have assumed it must be something in my startup files that is incompatible with the latest release of Emacs, except I thought -q --no-site-file should completely disable loading anything from my local configuration. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1017739: emacs-lucid cannot start after upgrade
Package: emacs-lucid Version: 1:28.1+1-1 Severity: grave X-Debbugs-Cc: r...@debian.org The 28.1 version of emacs-lucid fails on startup with a cryptic error message: % emacs Cannot find suitable directory for output in ‘comp-native-load-path’. Running emacs -q allows it to start, but it still reports the same error immediately during startup, and attempting to do someting as basic as M-x set-variable (to try to enable debug-on-error) fails with a similar error message: defalias: Cannot find suitable directory for output in ‘comp-native-load-path’. emacs -q --no-site-file avoids the error on startup, but M-x set-variable still immediately fails with the same error. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-lucid depends on: ii emacs-bin-common 1:28.1+1-1 ii emacs-common 1:28.1+1-1 ii libacl1 2.3.1-1 ii libasound2 1.2.7.2-1 ii libc62.34-4 ii libcairo21.16.0-6 ii libdbus-1-3 1.14.0-2 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.12.1+dfsg-3 ii libgccjit0 12.1.0-8 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libgif7 5.2.1-2.5 ii libglib2.0-0 2.72.3-1+b1 ii libgmp10 2:6.2.1+dfsg1-1 ii libgnutls30 3.7.7-2 ii libgpm2 1.20.7-10 ii libharfbuzz0b2.7.4-1+b1 ii libice6 2:1.0.10-1 ii libjansson4 2.14-2 ii libjpeg62-turbo 1:2.1.2-1 ii liblcms2-2 2.13.1-1 ii libm17n-01.8.0-4 ii libotf1 0.9.16-3 ii libpng16-16 1.6.37-5 ii librsvg2-2 2.54.4+dfsg-1 ii libselinux1 3.4-1+b1 ii libsm6 2:1.2.3-1 ii libsystemd0 251.4-1 ii libtiff5 4.4.0-4 ii libtinfo66.3+20220423-2 ii libx11-6 2:1.8.1-2 ii libxext6 2:1.3.4-1 ii libxfixes3 1:6.0.0-1 ii libxinerama1 2:1.1.4-3 ii libxml2 2.9.14+dfsg-1+b1 ii libxmu6 2:1.1.3-3 ii libxpm4 1:3.5.12-1 ii libxrandr2 2:1.5.2-2+b1 ii libxrender1 1:0.9.10-1.1 ii libxt6 1:1.2.1-1 ii xaw3dg 1.5+F-1 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages emacs-lucid recommends: pn fonts-noto-color-emoji Versions of packages emacs-lucid suggests: pn emacs-common-non-dfsg -- no debconf information
Bug#1016884: heimdal: FTBFS with glibc >= 2.34
Brian May writes: > On Tue, Aug 09, 2022 at 01:11:53AM +0200, Samuel Thibault wrote: >> Now that glibc provides a closefrom function, heimdal doesn't build its >> own rk_closefrom function any more, and thus the >> libroken18-heimdal.symbols check complains: >> >> - rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226 >> +#MISSING: 7.7.0+dfsg-4+b1# rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226 > What would be considered an acceptable solution here? > Presumably I can't just delete the symbol, that might break stuff. > Also see https://github.com/heimdal/heimdal/issues/1006 Yeah, it's kind of a problem that the libroken ABI isn't stable depending on what facilities are available on the local system, although it looks like the only other package in Debian that uses it is openafs. I think the options are to either bump the SONAME for the dropped symbol, or add an rk_closefrom wrapper around the glibc closefrom to keep the same ABI. (Or break the ABI without changing the SONAME on the grounds that only a few packages use it, but I'm pretty hesitant to recommend doing that since who knows what outside of Debian might break and we try hard not to do that.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1000233: php-remctl lost its phpapi-20190902 dependency
Control: reassign -1 dh-php Control: severity -1 important Control: affects -1 + php-remctl Control: affects -1 + kopanocore Control: affects -1 + libguestfs Control: affects -1 + libvirt-php Control: affects -1 + mapserver Control: affects -1 + php-excimer Control: affects -1 + php-facedetect Control: affects -1 + php-horde-lz4 Control: affects -1 + php-luasandbox Control: affects -1 + php-wmerrors Control: affects -1 + php-sass Control: affects -1 + php-tideways Control: affects -1 + php-wikidiff2 Control: affects -1 + php-zeroc-ice Replaying the control commands from the below message because it looks like they didn't take for some reason (maybe because there was a Control: line with no command at the start of the message). Ondřej Surý writes: > Hi Russ, > I am reassigning this bug to dh-php as I need to figure out what to > do with non-PECL extensions in the long run. The dh-php might > need some compatibility layer to support packages that bundle PHP > with something else. > I rewrote dh-php >= 4 to generate phpX.Y- out of the template > and there are couple more loose ends that needs either fix in the > package or in the dh-php. > The whole perl + shell + makefile has also lot of duct tape included. > I’ll either fix this directly in dh-php or provide the affected packages > with a patch. > 1. I don’t think missing dependency on PHP is a serious bug, it doesn’t > prevent usage of the extension, it just doesn’t pull the interpreter in. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#1000233: php-remctl lost its phpapi-20190902 dependency
Adrian Bunk writes:
> Package: php-remctl
> Version: 3.17-1
> Severity: serious
> Tags: bookworm sid
> After the src:remctl rebuild to add Python 3.10 as supported version,
> php-remctl lost its phpapi-20190902 dependency:
> Package: php-remctl
> Source: remctl
> Version: 3.17-1
> Installed-Size: 109
> Depends: php-common (>= 1:7.0+33~), phpapi-20190902, libc6 (>= 2.14),
> libremctl1 (>= 3.1)
> Package: php-remctl
> Source: remctl (3.17-1)
> Version: 3.17-1+b2
> Installed-Size: 106
> Depends: php-common (>= 1:7.0+33~), libc6 (>= 2.14), libremctl1 (>= 3.1)
This appears to be intentional in dh-php 4.2:
# Disable the dependency on the phpapi for the transition period
# $depends .= ", " . join(" | ", @api_versions);
PHP maintainers, do you have guidance on this? Should I be doing anything
as a package maintainer, or is this expected? Should it be a serious bug?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#996037: docknot: autopkgtest regression: Can't open /tmp/autopkgtest-lxc.91wiy1gt/downtmp/autopkgtest_tmp/smokenyzokG/lib/App/DocKnot.pm
Paul Gevers writes: > With a recent upload of docknot the autopkgtest of docknot fails in > testing when that autopkgtest is run with the binary packages of docknot > from unstable. It passes when run with only packages from testing. In > tabular form: Thanks for the report and apologies for the delay in fixing this! There was a test suite change that requires an additional file from the source tree be available and I need to fix the test configuration. Will fix this shortly. Thank you so much for generating these bug reports. They're incredibly helpful! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#994910: tripwire segfaults while reading files in /etc
Package: tripwire Version: 2.4.3.7-3+b3 Followup-For: Bug #994910 Reproduced here following a libc6 upgrade. I suspect this is because tripwire is statically linked and there has been a new release of libc6, so I suspect the nsswitch interface has broken (which is a standard problem with statically linking with libc6 on Linux). This would also explain why rebuilding the package made the problem go away. If this is correct, a BinNMU should fix the problem. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tripwire depends on: ii debconf [debconf-2.0] 1.5.77 ii postfix [mail-transport-agent] 3.5.6-1+b1 tripwire recommends no packages. tripwire suggests no packages. -- Configuration Files: /etc/tripwire/twcfg.txt changed [not included] /etc/tripwire/twpol.txt changed [not included] -- debconf information: * tripwire/installed: * tripwire/use-sitekey: true tripwire/local-passphrase-incorrect: false tripwire/broken-passphrase: tripwire/upgrade: true tripwire/email-report: tripwire/change-in-default-policy: * tripwire/use-localkey: true tripwire/site-passphrase-incorrect: false * tripwire/rebuild-config: true * tripwire/rebuild-policy: true
Bug#981765: docknot: autopkgtest failure
Adrian Bunk writes: > Source: docknot > Version: 4.00-1 > Severity: serious > https://ci.debian.net/data/autopkgtest/testing/amd64/d/docknot/10221864/log.gz Thank you for relaying those results! I forgot to go explicitly check. Will fix shortly. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#976056: nvidia-legacy-340xx-driver: requires DRM_LEGACY, disabled from Linux 5.9.11 onwards
jim_p writes: > First of all, I am really sorry about the annoying logs that spawn under > every message of mine. I am not putting them there on purpose, this is > all reportbug's work. I tried setting it to advanced and expert, hoping > that it will be less spammy, but it isn't. I admit I have no idea on how > to report a bug outside reportbug. To add additional information to a bug, you can just send mail directly to 976...@bugs.debian.org with a regular mail client if you want. (reportbug is very useful for getting all the right bits in place to open a new bug, though.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#974024: inn2 FTBFS on IPV6-only buildds
Russ Allbery writes: > Adrian Bunk writes: >> ... >> lib/network/server..MISSED 34-42 (killed by signal 14) >> ... >> Failed Set Fail/Total (%) Skip Stat Failing Tests >> -- -- >> lib/network/server9/3426%8 -- 34-42 >> Failed 9/3631 tests, 99.75% okay, 55 tests skipped. >> Files=60, Tests=3631, 12.90 seconds (2.43 usr + 1.92 sys = 4.35 CPU) >> make[2]: *** [Makefile:38: test] Error 1 > I'm working on a fix. It's unfortunately rather complicated because the > assumption that binding on any address will provide two sockets ran fairly > deep. > I think the problem only affects the test suite. This is fixed by upstream commits r10388 (trunk) and r10396 (stable). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#974024: inn2 FTBFS on IPV6-only buildds
Adrian Bunk writes: > https://buildd.debian.org/status/fetch.php?pkg=inn2=armhf=2.6.3%2B20200601-1=1591433398=0 > https://buildd.debian.org/status/fetch.php?pkg=inn2=armel=2.6.3%2B20200601-1%2Bb1=1604879007=0 > ... > lib/network/server..MISSED 34-42 (killed by signal 14) > ... > Failed Set Fail/Total (%) Skip Stat Failing Tests > -- -- > lib/network/server9/3426%8 -- 34-42 > Failed 9/3631 tests, 99.75% okay, 55 tests skipped. > Files=60, Tests=3631, 12.90 seconds (2.43 usr + 1.92 sys = 4.35 CPU) > make[2]: *** [Makefile:38: test] Error 1 I'm working on a fix. It's unfortunately rather complicated because the assumption that binding on any address will provide two sockets ran fairly deep. I think the problem only affects the test suite. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#972206: remctl ftbfs in unstable (failing tests)
Matthias Klose writes: > https://buildd.debian.org/status/fetch.php?pkg=remctl=amd64=3.16-4%2Bb7=1602646591=0 > [...] > make check-local > make[2]: Entering directory '/<>' > tests/runtests -l '/<>/tests/TESTS' Thanks, this is probably because that's one of the buildds with only IPv6 addresses. Working on a fix, will try to get it uploaded soon since I know a Python transition is coming. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#962784: [Pkg-puppet-devel] Bug#962784: facter aborts with free(): invalid pointer
Stig Sandbeck Mathisen writes: > Looks like the same bug as http://bugs.debian.org/962692 and related to > https://bugs.debian.org/962320 Ah, indeed, thank you! Somehow I missed those. #962320 seems like it should be assigned to facter and merged with this bug; I don't think it's Boost's fault that a binary links with two versions of the same shared library (unless the contention is that symbol versioning should make this safe, which can be quite challenging for C++ libraries). > A quick workaround to get facter to run is to create the three > directories: > /etc/facter/facts.d > /etc/puppetlabs/facter/facts.d > /opt/puppetlabs/facter/facts.d Yup, confirmed that works. Thank you! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#962784: facter aborts with free(): invalid pointer
Package: facter Version: 3.11.0-4.1 Severity: grave facter no longer works at all on amd64. When invoked, it dies with an invalid pointer error: % facter free(): invalid pointer Aborted (core dumped) gdb backtrace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x779cb55b in __GI_abort () at abort.c:79 #2 0x77a24038 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x77b30f3e "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x77a2b3da in malloc_printerr ( str=str@entry=0x77b2f0e0 "free(): invalid pointer") at malloc.c:5339 #4 0x77a2cdcc in _int_free (av=, p=, have_lock=0) at malloc.c:4173 #5 0x77e835d4 in ?? () from /usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0 #6 0x77e83bd8 in facter::facts::collection::add_external_facts(std::vector, std::allocator >, std::allocator, std::allocator > > > const&) () from /usr/lib/x86_64-linux-gnu/libfacter.so.3.11.0 #7 0x5557154c in main () This also renders Puppet unusable. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages facter depends on: ii libboost-program-options1.67.0 1.67.0-18 ii libc6 2.30-8 ii libfacter3.11.0 3.11.0-4.1 ii libgcc-s1 10.1.0-3 ii libleatherman1.4.2 1.4.2+dfsg-2+b1 ii libstdc++6 10.1.0-3 ii ruby1:2.7+1 facter recommends no packages. facter suggests no packages. -- no debconf information
Bug#959063: src:yadm: fails to migrate to testing for too long
Paul Gevers writes: > Your package is only blocked because the arch:all binary package(s) > aren't built on a buildd. Unfortunately the Debian infrastructure > doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will > shortly do a no-changes source-only upload to DELAYED/15, closing this > bug. Please let me know if I should delay or cancel that upload. Oh, whoops, sorry. Thank you for letting me know! I'll do the source upload myself, since that way it's easy for me to keep the Git history consistent. I can do that this evening. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
Marco d'Itri writes: > On Jan 20, Russ Allbery wrote: >> This also implies that there is arguably an SONAME issue with this library >> given that two versions of the library with the same SONAME don't provide >> the same symbols, but I suspect there were really, really good reasons to >> not change the SONAME. > The upstream maintainers choose to provide backward compatibility to old > binaries but not forward compatibility from old libraries. Oh, yes, that makes sense and is entirey normal. I was thinking about it the wrong way around. So the root problem is that the dependency was satisfied for the binary but there was a stray copy of the old library with the same SONAME in an earlier directory on the search path, which shadowed the correct library. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2
Clément Hermann writes: > I have the same issue. The symbol is in the file provided by libcrypt1, > however, it is in /usr/lib. > what I have in /lib is: > ``` > ls -l /lib/x86_64-linux-gnu/libcrypt.so.1 > lrwxrwxrwx 1 root root 16 déc. 27 20:31 /lib/x86_64-linux-gnu/libcrypt.so.1 > -> libcrypt-2.25.so > ls -l /lib/x86_64-linux-gnu/libcrypt-2.25.so > -rw-r--r-- 1 root root 39272 déc. 2 2017 libcrypt-2.25.so > ``` > The version (2.25) looks like it's a leftover from an older libc6 > package ? no package provides libcrypt-2.25.so as a file. libcrypt has > been disabled in libc6 2.29-4. In further support of this theory, neither my continuously-upgraded unstable system nor my continuously-upgraded testing system have that file. The testing system was built in 2014; the unstable system in late December 2017 (so that may not be as interesting). (Neither of those hosts are using merged-/usr, just to say explicitly.) I think that argues that there was some cleanup step that happened for some systems but not for others. > It looks like a leftover or something. Removing the file and running > ldconfig fixes the issue for me (but now I wonder if I have other > leftover files like this…). This also implies that there is arguably an SONAME issue with this library given that two versions of the library with the same SONAME don't provide the same symbols, but I suspect there were really, really good reasons to not change the SONAME. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#932351: gnubg: Crashes on launch
Andreas Beckmann writes: > Followup-For: Bug #932351 > Control: tag -1 pending > buster-pu request: https://bugs.debian.org/948796 Oh, thank you! I was going to get to that and then didn't. Much appreciated and let me know if I can help in any way. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944152: network access during the build
Now fixed, although I got the changelog message wrong because I still didn't understand properly. Ugh. I could have sworn that Debian buildds didn't allow network access. I'll fix the changelog message in a future upload. Thank you! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944151: remctl: attempts internet connection during testsuite
Now fixed, although I got the changelog message wrong because I still didn't understand properly. Ugh. I could have sworn that Debian buildds didn't allow network access. I'll fix the changelog message in a future upload. Thank you! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944152: network access during the build
Matthias Klose writes: > The package tries to access the network during the build to download test > dependencies. > from > https://buildd.debian.org/status/fetch.php?pkg=remctl=amd64=3.16-3=1572810461=0: Thank you! I thought setuptools was smarter than apparently it actually is (I thought it would know that an unversioned dependency on typing was already satisfied by Python 3 stdlib). Will fix tonight. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#944151: remctl: attempts internet connection during testsuite
Gianfranco Costamagna writes: > Hello, according to build log: > Testing Python extension > running pytest > Searching for typing > Reading https://pypi.org/simple/typing/ > Downloading > https://files.pythonhosted.org/packages/fe/2e/b480ee1b75e6d17d2993738670e75c1feeb9ff7f64452153cf018051cc92/typing-3.7.4.1-py3-none-any.whl#sha256=f38d83c5a7a7086543a0f649564d661859c5146a85775ab90c0d2f93ffaa9714 > Best match: typing 3.7.4.1 > Processing typing-3.7.4.1-py3-none-any.whl > Installing typing-3.7.4.1-py3-none-any.whl to /<>/python/.eggs Ah, thank you, I thought setuptools was much smarter than apparently it actually is. I'll look at this tonight; I may fix this upstream instead of only in the Debian package if it doesn't take too long to do. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Bug#932351: gnubg: Crashes on launch
Manuel Laínz writes: > I get this: > #10 0x7f2d89fcd07f in ___vsprintf_chk (s=0x7ffd889939e0 "Juego de > fichas para movimientos posteriores en simulaciones de lanzamientos (para > el jugador 0) usará ruido pseudo-aleatorio.\216pb\265z\340U", flags=1, > slen=128, format=0x7f2d866afc46 0x7f2d866afc46>, args=args@entry=0x7ffd88993870) at vsprintf_chk.c:83 > #11 0x7f2d89fccfaa in ___sprintf_chk (s=, > flags=, slen=, format=) at > sprintf_chk.c:31 Thanks, that's exactly what I needed. I should have thought to test with locales. The problem is that gnubg is allocating a static buffer to hold one of its output messages, and the Spanish translation is long enough that it's overflowing the buffer. If you change your locale when running gnubg, that will fix the problem (LC_ALL=C.UTF-8 gnubg), at the cost of losing the translations. I'll fix this for unstable and will see about getting a targeted fix into stable as well, although it won't go out, at best, until the next point release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#932351: gnubg: Crashes on launch
Control: tags -1 unreproducible moreinfo mlainz writes: > Package: gnubg > Version: 1.06.002-1 > Severity: grave > Justification: renders package unusable > gnubg crashes on launch on debian buster with the following message: > *** buffer overflow detected ***: gnubg terminated > I got the same result on two different machines, over Wayland and X11. I can't reproduce this. Can you enable core dumps (ulimit -c unlimited) and then run gdb on the corresponding core dump (gdb /usr/games/gnubg core) and then run backtrace and show the backtrace for this? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#929834: Buster/XFCE unlock screen is blank
Yves-Alexis Perez writes: > Actually it seems to me that the bug is a bad interaction with light- > locker/lightdm locking system (which relies on vt switch) and the Intel > driver. It only seems to happens on this driver, and I think it's also > been reproduced just by doing vt-switches (but can't remember where it > was reported). Ah, good call. I was also seeing other problems with the Intel driver in combination with light-locker where the monitor resolution would be set to some incorrect value after restore from lock. This would come with kernel errors like: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun and then lots and lots of: [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#923930: FTBFS: FAIL test_chain
Brian May writes: > Brian May writes: >> This implies it should be possible for ap application to request 64 bit >> time_t, but not sure how. > I see proposals to setting _TIME_BITS=64 from 2015, however I don't > actually see any reference to this being implemented yet. > https://lwn.net/Articles/664800/ The work is actively underway in both the kernel and in glibc, but I don't think it's fully working in buster. I would expect it to be there by the next Debian release, though. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#919623: Remote code execution in scp support
Package: rssh
Version: 2.3.4-8
Severity: grave
Tags: security upstream
https://sourceforge.net/p/rssh/mailman/message/36519118/ is the upstream
report. The reporter indicated they asked for a CVE but didn't include it
in the message.
scp allows remote code execution inside the server environment via several
methods due to inadequate command-line verification. This bug has been
present since the beginning of rssh.
I have a completely untested patch but haven't had time to test it yet.
Attaching it to this report for whatever it's worth.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages rssh depends on:
ii debconf [debconf-2.0] 1.5.69
ii libc6 2.28-4
ii openssh-server 1:7.9p1-4
rssh recommends no packages.
Versions of packages rssh suggests:
ii cvs 2:1.12.13+real-26
pn makejail
pn rdist
ii rsync 3.1.3-1
ii subversion 1.10.3-1+b1
-- Configuration Files:
/etc/logcheck/ignore.d.server/rssh [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.server/rssh'
/etc/rssh.conf changed [not included]
-- debconf information excluded
diff --git a/util.c b/util.c
index 56f67ad..4dde1a0 100644
--- a/util.c
+++ b/util.c
@@ -268,6 +268,45 @@ static int rsync_e_okay( char **vec )
}
+/*
+ * scp_okay() - take the command line and check that it is a hopefully-safe scp
+ * server command line, accepting only very specific options.
+ * Returns FALSE if the command line should not be allowed, TRUE
+ * if it is okay.
+ */
+static int scp_okay( char **vec )
+{
+ int saw_file = FALSE;
+ int saw_end = FALSE;
+
+ for ( ; vec && *vec; vec++ ){
+ /* Allowed options. */
+ if ( !saw_end ) {
+ if ( strcmp(*vec, "-v") == 0 ) continue;
+ if ( strcmp(*vec, "-r") == 0 ) continue;
+ if ( strcmp(*vec, "-p") == 0 ) continue;
+ if ( strcmp(*vec, "-d") == 0 ) continue;
+ if ( strcmp(*vec, "-f") == 0 ) continue;
+ if ( strcmp(*vec, "-t") == 0 ) continue;
+ }
+
+ /* End of arguments. One more argument allowed after this. */
+ if ( !saw_end && strcmp(*vec, "--") == 0 ){
+ saw_end = TRUE;
+ continue;
+ }
+
+ /* No other options allowed, but allow file starting with -. */
+ if ( *vec[0] == '-' && !saw_end ) return FALSE;
+ if ( saw_file ) return FALSE;
+ saw_file = TRUE;
+ }
+
+ /* We must have seen a single file. */
+ return saw_file;
+}
+
+
/*
* check_command_line() - take the command line passed to rssh, and verify
* that the specified command is one the user is
@@ -283,8 +322,11 @@ char *check_command_line( char **cl, ShellOptions_t *opts )
return PATH_SFTP_SERVER;
if ( check_command(*cl, opts, PATH_SCP, RSSH_ALLOW_SCP) ){
- /* filter -S option */
- if ( opt_filter(cl, 'S') ) return NULL;
+ if ( !scp_okay(cl) ){
+ fprintf(stderr, "\ninsecure scp option not allowed.");
+ log_msg("insecure scp option in scp command line");
+ return NULL;
+ }
return PATH_SCP;
}
Bug#917050: Bug#917072: [Pkg-emacsen-addons] Bug#917050: Hangs infinitely when compiling for emacs 1:26.1+1-2
Axel Beckert writes: > Hence reassigning all other bugs to the one against mmm-mode (and > reassigning that one from source package to binary package) and > setting according "affects". (Bcc'ed control@bugs.d.o) I can confirm: during upgrade, emacs went into some sort of infinite loop during byte compilation and consumed 100% of a CPU. Checking with ps showed that it was trying to byte-compile mmm-mode at the time. I was able to reproduce reliably via different ways of kicking off configuration, and removing mmm-mode made everything configure correctly. (An infinite loop during byte-compilation does make it feel like there may be some underlying but in Emacs as well, since that doesn't feel like something that should be possible, but it may not be detectable or avoidable depending on what the cause was.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant
Jonathan Nieder writes: > Jeremy Bicha wrote: >> chrome-gnome-shell (in this case) is an addon for the Google Chrome web >> browser. Since Chrome installs to /opt/ (which is encouraged by FHS), >> /etc/opt/ is the only standards-compliant location for >> chrome-gnome-shell to ship the configuration files it needs to provide >> its core functionality. >> There is no reason this functionality cannot be offered in Debian. We >> got complaints when we supported other browsers but not Google Chrome. > Since Google Chrome is not part of Debian, shouldn't this > functionality be offered in contrib, not Debian? chrome-gnome-shell supports all of Chromium, Chrome, and Firefox in the same package, two of which are in Debian. It only installs one file in /etc/opt for Chrome, namely: /etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json Splitting that single config file into a separate contrib package feels like overkill here. It shouldn't hurt anything on a system without Chrome and it doesn't create any sort of dependency on Chrome, which is the normal case for contrib. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#908568: nvidia-driver: build error
Vincent Lefevre writes: > On 2018-09-11 15:29:02 -0700, Russ Allbery wrote: >> Vincent Lefevre writes: >>> This would mean that a breakage is possible after any patch (in >>> particular with those "Update to SVN..." in the changelog). Thus this >>> means that the kernel module build system must check that the GCC >>> Debian package version number matches the one used to build the >>> kernel. For sid, GCC is often not in sync with the one used to build >>> the kernel. This is a really big problem. >> I don't think it's an NVIDIA-specific problem, though, right? Doesn't >> this happen with any kernel module build? > I assume that this depends on which features of the interface are > used. Sorry, I should have checked before replying. This is indeed an NVIDIA-specific check in conftest.sh, not a general Linux issue. It's not doing any complicated logic; it's just parsing the version string and aborting the compilation if it doesn't match. If you set IGNORE_CC_MISMATCH=1 in the environment before installing the package, does everything build and work correctly? Apparently fglrx had a similar check, and the package maintainers chose to patch it out. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#908568: nvidia-driver: build error
Vincent Lefevre writes: > This would mean that a breakage is possible after any patch (in > particular with those "Update to SVN..." in the changelog). Thus this > means that the kernel module build system must check that the GCC Debian > package version number matches the one used to build the kernel. For > sid, GCC is often not in sync with the one used to build the > kernel. This is a really big problem. I don't think it's an NVIDIA-specific problem, though, right? Doesn't this happen with any kernel module build? Or am I confused and this is an NVIDIA-specific check? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#908568: nvidia-driver: build error
Vincent Lefevre writes: > Even with just a differing *minor* version? Note that since GCC 5, > an update of the minor version should just be bug fixes: > https://gcc.gnu.org/develop.html The kernel uses GCC-specific features in an extremely aggressive way. I'm not particularly surprised that ABI compatibility might break across minor versions. Normally the linux-compiler-gcc-* packages express the required compiler version for building kernel modules and handle this, but they're only an upgrade ratchet, not a downgrade ratchet. (Plus, that would just create an unsatisfiable dependency since the compiler packages aren't broken apart that way.) > If the minor version really matters, why Debian doesn't ship different > packages, such as gcc-6.3 and gcc-6.4? I suspect that usually only the kernel is affected. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy
Control: severity -1 normal Norbert Preining writes: > The recent addition to the Debian Policy to require a Perl shebang of > /usr/bin/perl is inconsistent with the rest of script usage, and hinders > the user/system administrator to freely override Perl. This isn't recent. All we did was change should to must in the main policy, and it was already must in the Perl policy. > If a user/system admin wants to replace Perl by prepending the path to a > self compiled Perl to the PATH, it is his right to do so, and Perl > scripts are expected to follow this decision. It is the obligation of > the one doing the change to ensure proper availability of modules and > support files. There were literally zero packages in Debian that did this that Lintian could find. Did we miss something? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#873125: debian-policy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Control: tag -1 pending Dmitry Shachnev <mity...@debian.org> writes: > debian-policy fails to build with Sphinx 1.6, currently available in > experimental: > sphinx-build -M latexpdf policy policy/_build > Running Sphinx v1.6.3 > [...] > build succeeded. > make[2]: Entering directory '/<>/policy/_build/latex' > make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > latexmk -pdf -dvi- -ps- 'policy.tex' > make[2]: latexmk: Command not found > Makefile:33: recipe for target 'policy.pdf' failed > make[2]: *** [policy.pdf] Error 127 > Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1]. > Adding a build-dependency on latexmk should help. Thanks, fixed in Git. We'll need to make a new upload shortly. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#824839: librrd-simple-perl: FTBFS on armhf and arm64: t/23graph.t failures
intrigeri <intrig...@debian.org> writes: > You did the initial upload of librrd-simple-perl to Debian back in 2013, > so I'm seeking your opinion wrt. removing it from sid as part of the > pkg-perl ongoing effort towards removing the most hopeless of our > RC-buggy packages. > Summary: > * This package was not shipped in Stretch due to this bug. > * On https://rt.cpan.org/Public/Bug/Display.html?id=78785 you've >attached a patch that fixed the problem on x86_64, but sadly it >doesn't fix it on armhf and arm64. > * This is a leaf package and popcon is fairly low: >Inst = 43, Vote = 5. > Are you interested in working further on this problem? > Would you mind if we removed this package from sid? Yeah, go for it. I was using it for a specific project, and I think I ended up abandoning that project anyway (and I'm no longer working for the employer who had that problem). If someone runs into a need for it, they can always circle back and look at the package again. It seemed pretty seriously unmaintained. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#704303: violates Debian Policy 2.3 Copyright considerations
"Pirate Praveen" <prav...@onenetbeyond.org> writes: > On Sun, 19 Feb 2017 12:43:30 +0530 Pirate Praveen <prav...@debian.org> wrote: >> On Sun, 1 Jan 2017 16:55:52 +0500 Andrey Rahmatullin <w...@debian.org> wrote: >>> Note that since Policy 3.9.9 MPL should be in common-licenses. >> Reassigning to firefox, which also has the same issue. When is Policy >> 3.9.9 expected to be released, would it be before stretch release? > since this will not be an issue after debian-policy 3.9.9 release, can > this get a stretch-ignore tag? I'm currently holding off on releasing debian-policy 3.9.9 until the corresponding base-files change has been uploaded. (It will probably actually be 3.10.0.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#854487: [Pkg-puppet-devel] Bug#854487: Bug#854487: Bug#854487: Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service
Apollon Oikonomopoulos <apoi...@debian.org> writes: > Additionally, all the setups I know of use cron for running the puppet > agent, so these admins will want the service disabled anyway (of course > this is argumentum ad populum, but it serves as an indication that this > is not an unreasonable course of action). Yeah, this is a good argument. Works for me! It's also good to use a more robust mechanism for doing this so that we don't get accidental problems in the future when the locking stuff changes again. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#854487: [Pkg-puppet-devel] Bug#854487: Bug#854487: Bug#854487: Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service
Apollon Oikonomopoulos <apoi...@debian.org> writes: > Actually, it is much simpler than that: adding an `update-rc.d defaults > puppet && update-rc.d disable puppet` before the debhelper stanzas just > works and does the right thing. > Given that in either case (service disabled, or agent locked) manual > intervention is required (and desirable), I think it is best to just > disable the service. I'll prepare an upload shortly. I had completely forgotten about the logic to disable it by default. My recollection is that this was the result of some discussion about disabling the init script and this ended up being better, but I forget the history. I think restoring the disable logic may be all that's required. Thank you for looking at this! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#854487: [Pkg-puppet-devel] Bug#854487: Binary-only package puppet was silently converted into a package shipping and running a service
Alexander Kurtz <alexan...@kurtz.be> writes: > However, now somebody decided, that it's a good idea to drop the > puppet-agent package and move the service file back to the puppet > package [1]. This is bad, very, very bad. Here's why: I don't think this is the problem. I think the problem is that the service is enabled by default. There's no harm in having everything in one package provided that the service defaults to *disabled*, not enabled. My recollection is that this is even what the puppet-agent package did, although maybe I'm misremembering. But it looks like the default installation logic may have been lost with the merge into a single puppet package. For systemd, I think the fix may be as easy as using --no-enable in a dh_systemd_enable override. I'm not sure how this used to be done for dh_installinit. (Completely agreed that having the daemon start and try to use the server named "puppet" as a Puppet master on package installation is pretty bad.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#847301: libpam-krb5: PAM error message "adding faulty module pam_makedir.so (and many others)
Control: tags -1 moreinfo -security jessie Control: severity -1 normal Duncan Hare <d...@synoia.com> writes: > Package: libpam-krb5 > Version: Jessie Latest > Severity: grave > Tags: security > Justification: renders package unusable I'm going to need more details than that. :) The error message you give doesn't even have anything to do with this module? Lots of people are using this package in jessie, so the chances are extremely low that it's actually broken for everyone. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844160: openssl 1.1 and apache2
Stefan Fritsch <s...@debian.org> writes: > I must admit that I did not think of php when doing that change, sorry. > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and there > have been some indications that shibboleth won't be switching to openssl 1.1 > for stretch. See https://lists.debian.org/debian-release/2016/11/msg00024.html It turns out that Shibboleth will be okay if Apache goes to 1.1. The Shibboleth code that goes into Apache is isolated from the OpenSSL use inside Shibboleth, so we can keep building Shibboleth against 1.0 and Apache can go to 1.1 and all the pieces are happy. (The OpenSSL work is done in a separate daemon, shibd, that the Apache module talks to.) (Not that this solves all the problems, but just FYI.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools
wf...@niif.hu (Ferenc Wágner) writes: > Just adding that Shibboleth itself is also problematic, because > XMLTooling, which is incompatible with OpenSSL 1.1, uses libcurl, which > already switched to OpenSSL 1.1. So switching xml-security-c to OpenSSL > 1.0 did not actually solve the problem for Shibboleth because of the > above version clash in XMLTooling. It's worth noting that Apache also requires OpenSSL 1.0, which may also affect what the Shibboleth stack can link against. > Shall I bring it up with the curl maintainers? Or wait for the > conclusion on debian-devel? This seems like something we're going to have to figure out project-wide, since the way the transition is currently set up doesn't seem likely to work. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#844263: libxml-security-c-dev: depending on libssl1.0-dev breaks open-vm-tools
Bernd Zeimetz <b...@debian.org> writes: > unfortunately your decision to depend on libssl1.0-dev breaks the build > open-vm-tools as most other build-dependencies decided to migrate to > the new openssl version. > I know that shibboleth is the issue, but the current situation breaks > open-vm-tools, which is a requirement if you want to run Debian on > vmware - and there are *loads* of installations out there. Well, my understanding is that xml-security-c doesn't support OpenSSL 1.1 upstream, the porting is not trivial, and will not be completed in the release time frame. So I'm not sure there's any other alternative. Whatever dependencies that were pushing open-vm-tools to 1.1 may have to be reverted back to 1.0. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#838760: perl: Perl/Perl-base upgrade removes 141 packages (Sid/Unstable)
Cindy Sue Causey <butterflyby...@gmail.com> writes: > Hi! Thank you for all the hard work you all to so #poverty level folks > have a chance to keep up with the tech world, too! As to why I'm > writing, just tried to upgrade a select 30+ packages in > Sid/Unstable. Apt-get is my chosen method to do so. Received the message > that Received the advisement that: > 2 upgraded, 2 newly installed, 141 to remove > ALMOST let it happen because I was in a hurry and didn't immediately > catch that message. Only thing I know to do in this kind of situation is > to set Perl and Perl-base aside and wait for the next release so that's > how I'm approaching it today. For future reference, you get results like this mostly from apt-get install of specific packages, since then apt-get goes to considerably more lengths to try to do what you're telling it to do (including contemplating removing temporarily conflicting packages). If instead you do a whole-system upgrade with apt-get upgrade, you'll see all these packages will just be held back until they can be safely upgraded. Even if you use the more aggressive apt-get dist-upgrade, right now you get something (depending on the packages you have installed) like: # apt dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Error! Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libenchant1c2a : Depends: aspell-en but it is not going to be installed or myspell-dictionary or aspell-dictionary or ispell-dictionary or hunspell-dictionary E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. which is not horribly informative but at least doesn't do the wrong thing. You probably have reasons to want to upgrade specific packages instead of your system in better, but it's worth being aware that this is one case where this can be less safe (if you don't watch apt-get closely) than letting it use its normal upgrade semantics. (Also, a general upgrade is safer in that you'll always get security updates.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#835677: remctl: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
Control: severity 835677 normal Lucas Nussbaum <lu...@debian.org> writes: > Source: remctl > Version: 3.12-1 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160828 qa-ftbfs > Justification: FTBFS on amd64 > During a rebuild of all packages in sid, your package failed to build on > amd64. >> server/shell-misc...FAILED 8 This appears to be another oddity of the testing environment: 127.0.0.1 apparently doesn't resolve to a string containing the word "localhost." I'll try to make the test more robust against this by also checking for a string containing $(hostname), but if you happen to know what the reverse DNS is for 127.0.0.1 in the test environment, I'll make sure this is caught. Downgrading since this shouldn't be a problem for Debian proper; this seems to work fine on all the buildds. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#830452: lbcd: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
Lucas Nussbaum <lu...@debian.org> writes: > I found the source (or more exactly: Antonio Terceiro and Eric Wong did > in #830353). > It seems that the Debian EC2 image uses non-default TCP buffer sizes. > (see https://lists.debian.org/20160719211715.ga8...@xanadu.blop.info ) > When setting them back to the default value, both lbcd and remctl build > fine. Ah, thank you! I'll see if I can adjust the test to be less fragile. Usually some minor tuning will resolve issues like this. (It's irritatingly difficult to properly test network code because the OS loves hiding things like this.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#815765: #815765: remctl: FTBFS against ruby2.3
Christian Hofstaedtler <z...@debian.org> writes: > During a follow-up rebuild of remctl in an unmodified sid chroot > using sbuild, your package FTBFS in the very same way - phpize not > finding libtool. > Therefore I'm raising the bug's severity as it's likely the package > will FTBFS for anyone building it. Thanks for the report! I won't get a chance to get to this until this weekend, but I'll definitely take a look and try to get it fixed then. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#797623: opensaml2: transition needed for g++-5 ABIs
Ferenc Wagner <wf...@niif.hu> writes: > That's great! Let's start with log4shib, another immediate BD of > OpenSAML2, which also has a not-yet-packaged upstream release. I > applied the DEP-14 transformation (branch renaming) to the Alioth repo, > and did some streamlining, similarly to xmltooling. The result is > available at https://mentors.debian.net/package/log4shib. Please review > and upload if suitable. I'm doing OpenSAML itself tomorrow. Uploaded log4shib. We're going to need to ask for a binNMU for xmltooling as well to pick up the new dependency. I forgot about that until just after I uploaded it. I'll open a bug against release.debian.org for the mini-transition. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#797623: opensaml2: transition needed for g++-5 ABIs
Ferenc Wagner <wf...@niif.hu> writes: > Thanks. Regarding xmltooling, We could as well do a regular upload > replacing the liblog4cpp5-dev dependency of libxmltooling-dev with > liblog4shib-dev. I only noticed this yesterday when building opensaml > pulled in log4cpp, sorry. I think I was just confused and everything is fine, since the transition already happened after the previous NMU. There's still a transition for opensaml2 and shibboleth-sp2, I think, but that's tiny and not a big deal. It's probably fine to upload opensaml2 right away, but I'll wait until log4shib propagates everywhere just in case. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#797623: opensaml2: transition needed for g++-5 ABIs
Ferenc Wagner <wf...@niif.hu> writes: > Russ Allbery <r...@debian.org> writes: >> I think I was just confused and everything is fine, since the >> transition already happened after the previous NMU. There's still a >> transition for opensaml2 and shibboleth-sp2, I think, but that's tiny >> and not a big deal. > Do you mean the library name transition (+v5), of which this bug is > about? I got confused and thought that we were uploading liblog4shib1v5 for the first time, which would mean that everything would need to be rebuilt against it so that the old library could be removed. I'd missed that was just incorporating an NMU, and liblog4shib1v5 had already been introduced. We're still going to rename (+v5) opensaml2 per this bug, yeah, but that only affects two packages, so it's not that big of a deal. > Looks like it won't, the builds fail everywhere. At first sight the > problem seems to be that on amd64: > checking if gcc static flag -static works... no > which leads to liblog4shib.la being created, while on other arches: > checking if gcc static flag -static works... yes > and liblog4shib.la is not created, leading to an error when debian/rules > tries to remove it. While this would be easy to work around, I really > wonder what's going on. Looking at my older build logs, the -static > flag occasionally worked on amd64, but most of the it does not work > (according to configure). Why does this happen? The rm command for removing liblog4shib.la hard-coded the multiarch path for amd64. I just uploaded a new version of the package that should fix it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#797623: opensaml2: transition needed for g++-5 ABIs
Ferenc Wagner <wf...@niif.hu> writes: > Please wait a little, I'm packaging the new upstream anyway and will > introduce this change soon (I'll need a sponsor, though). I should be able to help with sponsorship. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#807756: gnubg: fails to start. hangs using 100% of one cpu core
Control: reassign -1 gcc-5.0 Control: severity -1 important Andreas Metzler <ametz...@bebt.de> writes: > Some more points of strangeness: > jessie's gnubg package (1.04.000-1) works on current stretch. > Rebuilding the jessie source on current sid produces a binary which > fails. > Rebuilding with DEB_BUILD_OPTIONS=noopt works > Rebuilding on current sid with gcc-4.9 produces a working package. > Rebuilding either the jessie or the sid source with -O1 segfaults at > start: > (gdb) run > Starting program: /usr/games/gnubg > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Program received signal SIGSEGV, Segmentation fault. > memcpy (__dest=0x833070, > __dest@entry= detected (257).>, __src=0x7fffea09a46e, > __src@entry= detected (257).>, __len=6, > __len@entry= detected (257).>) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 > 53 Hrm. Okay, so the compiler is doing something weird, and this isn't a problem with libtasn1. Thanks for the additional information! I'm going to reassign this to gcc-5, and might upload a package built explicitly with gcc-4.9 as a workaround. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#807756: gnubg: fails to start. hangs using 100% of one cpu core
Julian Hughes <julianhug...@gmail.com> writes: > when starting gnubg it uses 100% of one cpu core and then apparently > hangs with no output and without starting the gui. Hm, that sounds like it somehow got built with PIE. I was experimenting with that and it definitely doesn't work, but I could have sworn the version I uploaded wasn't built with PIE. I can reproduce this, trying to figure out what's going on right now. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#807756: gnubg: fails to start. hangs using 100% of one cpu core
Control: reassign -1 libtasn1-6 Control: affects -1 gnubg Julian Hughes <julianhug...@gmail.com> writes: > Package: gnubg > Version: 1.05.000-2 > Severity: grave > Justification: renders package unusable > when starting gnubg it uses 100% of one cpu core and then apparently > hangs with no output and without starting the gui. So, I'm not sure what's going on here, but it seems to be some sort of weird bug in libgnutls/libtasn1. gnubg is going into an infinite loop before any gnubg code actually runs at all, during shared library initialization. This is the backtrace of the infinite loop: #0 memcpy (__dest=0x83e070, __src=0x7fffea09a46e, __len=6) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #1 0x7fffe838eee2 in strcpy (__src=0x7fffea09a46e "PKIX1", __dest=0x83e070 "") at /usr/include/x86_64-linux-gnu/bits/string3.h:104 #2 _asn1_str_cpy (dest=dest@entry=0x83e070 "", dest_tot_size=dest_tot_size@entry=65, src=0x7fffea09a46e "PKIX1") at gstr.c:59 #3 0x7fffe838f43b in _asn1_set_name (node=node@entry=0x83e070, name=) at parser_aux.c:379 #4 0x7fffe8390489 in asn1_array2tree (array=, definitions=definitions@entry=0x7fffea2d0f20 <_gnutls_pkix1_asn>, errorDescription=errorDescription@entry=0x0) at structure.c:199 #5 0x7fffe9ff4edd in gnutls_global_init () at gnutls_global.c:257 #6 0x7fffe9fd6ed9 in lib_init () at gnutls_global.c:434 #7 0x77dea26a in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffe098, env=env@entry=0x7fffe0a8) at dl-init.c:72 #8 0x77dea37b in call_init (env=0x7fffe0a8, argv=0x7fffe098, argc=1, l=) at dl-init.c:30 #9 _dl_init (main_map=0x77ffe188, argc=1, argv=0x7fffe098, env=0x7fffe0a8) at dl-init.c:120 #10 0x77ddbcca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #11 0x0001 in ?? () #12 0x7fffe42a in ?? () #13 0x in ?? () So for some reason it's going into an infinite loop inside a memcpy of only six bytes? I'm really boggled by this behavior, but I'm not seeing the mechanism where gnubg could cause this. Reassigning to the libtasn1-6 package for help. Maybe they have some idea what's going on here. libtasn1-6 maintainers, this is 100% reproducible by just installing gnubg from unstable and running gnubg. To get the above backtrace, I just grabbed the source package, did apt-get build-dep gnubg, debian/rules build, and installed the debugging packages for libgnutls and libtasn1. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#807086: perl/experimental: FTBFS: cpan/podlators/t/devise-date failure
Niko Tyni <nt...@debian.org> writes: > This package failed to build on ppc64el and mips64el: > cpan/podlators/t/devise-date .. # Failed > test 'devise_date matches strftime' > # at t/devise-date.t line 20. > # got: '2015-12-04' > # expected: '2015-12-05' > # Looks like you failed 1 test of 6. > FAILED at test 1 > > This is because we now set SOURCE_DATE_EPOCH to the latest > debian/changelog time stamp, and those builds happened on the next day. > Turns out the backported SOURCE_DATE_EPOCH support from podlators-4.00 > doesn't itself survive being build with SOURCE_DATE_EPOCH (or > POD_MAN_DATE, for that matter) set. Patch attached. podlators 4.03 released with this fix. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#807086: perl/experimental: FTBFS: cpan/podlators/t/devise-date failure
Niko Tyni <nt...@debian.org> writes: > Turns out the backported SOURCE_DATE_EPOCH support from podlators-4.00 > doesn't itself survive being build with SOURCE_DATE_EPOCH (or > POD_MAN_DATE, for that matter) set. Patch attached. Doh. Thanks. :) I'll kick out a new version, probably this weekend. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#802988: File conflict with golang-go 2:1.5.1-1 (/usr/lib/go/pkg/tool/linux_amd64/cover)
Package: golang-golang-x-tools Version: 1:0.0~git20150716.0.87156cb+dfsg1-4 Severity: serious Unpacking golang-golang-x-tools (1:0.0~git20150716.0.87156cb+dfsg1-4) ... dpkg: error processing archive /var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20150716.0.87156cb+dfsg1-4_amd64.deb (--unpack): trying to overwrite '/usr/lib/go/pkg/tool/linux_amd64/cover', which is also in package golang-go 2:1.5.1-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#797623: Bug#797625: xmltooling: transition needed for g++-5 ABIs
Ferenc Wagner <wf...@niif.hu> writes: > Thanks for the detailed report. Right now I'm doing urgent work on HA > packages, but once that's done, I'll package new upstream versions of > the whole Shibboleth stack to fix the outstanding OpenSAML security bug > in unstable. This will change the SO version of xml-security-c and > probably all other library packages in the stack. Does this change the > big picture somehow? I don't understand the interdependencies of this > transition. Anyway, feel free to NMU these packages if that helps > unblocking other stuff, just don't be too concerned about the fate of > the current versions in unstable, expect new upstream versions after a > couple of weeks. If you're changing the SONAME anyway, you don't have to do the renaming described here. That's actually an even cleaner solution. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#795639: assword fails with Decryption error: Decryption failed
Just one more data point: I just upgraded another system using assword, with a separate private key that was generated on 2014-08-20, and everything worked fine with it. And I don't get the legacy keys errors on that system either. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Bug#795639: assword fails with Decryption error: Decryption failed
Daniel Kahn Gillmor d...@fifthhorseman.net writes: interesting. what is the history of this secret key material? Was it generated fresh on 2009-05-29? or was it converted from some other (older) key source? It was generated fresh on 2009-05-29 using gpg at the time. Aha. Okay, I seem to have fixed it, although I still don't really understand what happened. On a hunch, I ran: $ gpg2 --import ~/.gnupg/pubring.gpg That spat out a bunch of output (tons and tons of those legacy key messages), and then I ran: $ gpg2 --import ~/.gnupg/secring.gpg again. Did you happen to compare your test commands (e.g. looking at files, running gpg -kv $FPR) between these two --import operations? I'm assuming that the last one is the one that fixed things, but i'd like to make sure... Sadly, I didn't, but I do know for certain that just doing the second did not fix the problem. It just declined to import the key with the legacy key message and then another message about how there was no self-sig. (Actually, you probably already know that since I think that was a previous message -- now I'm forgetting what I did when.) I started wondering if it couldn't see the self-sig because it didn't have the corresponding public key and wondered what would happen if I imported the public key ring. After I did that, the second command actually imported the secret key as well (in that I saw 1 key imported in the resulting message). For some reason, all my other secret keys were successfully imported. Just not that one. do you know if there were more legacy key messages for the second --import command? Oh, yeah, there are tons every time I run that command. Basically one for every key. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Bug#795639: assword fails with Decryption error: Decryption failed
Daniel Kahn Gillmor d...@fifthhorseman.net writes: ok, so the keygrip for 0x7CE29A76E9769486 is FD1DA474D3DF3C728C54F9E479EDFC5BBE2E14EA (via gpg2 --with-keygrip --list-keys 7CE29A76E9769486) do you see ~/.gnupg/private-keys-v1.d/FD1DA474D3DF3C728C54F9E479EDFC5BBE2E14EA.key ? No, that file doesn't exist. So it looks like you've located the problem. I agree with you that this key clearly has valid self-sigs. it does in my copy as well. can you show the same output from gpg2 as well as gpg ? I can't, no, because I get the same problem: mithrandir:~$ gpg2 -kv D15D313882004173 gpg: using classic trust model gpg: keydb_get_keyblock failed: Legacy key gpg: error reading key: No public key Aha. Okay, I seem to have fixed it, although I still don't really understand what happened. On a hunch, I ran: $ gpg2 --import ~/.gnupg/pubring.gpg That spat out a bunch of output (tons and tons of those legacy key messages), and then I ran: $ gpg2 --import ~/.gnupg/secring.gpg again. That prompted me for the passphrase for the private key for D15D313882004173, and then apparently successfully imported it. Now, the gpg2 command works: mithrandir:~$ gpg2 -kv D15D313882004173 gpg: using classic trust model pub rsa4096/D15D313882004173 2009-05-29 [expires: 2017-09-17] uid [ultimate] Russ Allbery ea...@eyrie.org uid [ultimate] Russ Allbery r...@stanford.edu uid [ultimate] Russ Allbery r...@debian.org uid [ revoked] Russ Allbery ea...@windlord.stanford.edu uid [ultimate] Russ Allbery r...@cs.stanford.edu sub rsa4096/7CE29A76E9769486 2009-05-29 [expires: 2017-09-17] sub rsa2048/7D80315C5736DE75 2010-09-17 [expires: 2016-03-20] and now assword works again. So, something weird about the automated key import process for gpg2? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Bug#795639: assword fails with Decryption error: Decryption failed
Jameson Graef Rollins jroll...@finestructure.net writes:
Thanks for the report, Russ, and sorry about the trouble.
I'm actually unable to reproduce this bug by just installing gnupg2 from
unstable (2.1.7-2). However, my /usr/bin/gpg is from the gnupg package,
not gnupg2. I'm guessing that maybe you're using gnupg2 as gnupg in
this case?
Hm, nope, I'm similarly using /usr/bin/gpg from the gnupg package. Is
that what assword is using? Now I'm quite confused
I should mention that I upgraded both gnupg2 and gnupg-agent and it broke,
and then I downgraded both and it started working. I was assuming that it
was gnupg2, but maybe the problem is actually the agent, and only people
using the agent will have trouble?
strace seems to back that up. It chats with the agent for a bit, and then
it fails. See the partial trace below. It seems to get as far as
realizing that I don't currently have the secret key unlocked, but then
rather than popping up a dialog to prompt me, just immediately fails.
Running gpg manually on a file pops up the agent dialog like I would
expect.
I tried killing all the agents and logging out and then back in again to
force the agent to respawn, but unfortunately there was no change in
behavior.
It's quite possible that this is a bug somewhere in the new version of
gnupg and it just happens to break assword.
read(4, [GNUPG:] PROGRESS -10 ? 0 0\n, 1024) = 29
select(9, [4 8], [], NULL, {1, 0}) = 1 (in [4], left {0, 89})
select(5, [4], [], NULL, {0, 0})= 1 (in [4], left {0, 0})
read(4, [GNUPG:] ENC_TO 7CE29A76E9769486..., 1024) = 37
select(9, [4 8], [], NULL, {1, 0}) = 1 (in [4], left {0, 984921})
select(5, [4], [], NULL, {0, 0})= 1 (in [4], left {0, 0})
read(4, [GNUPG:] NO_SECKEY 7CE29A76E9769..., 1024) = 145
select(9, [4 8], [], NULL, {1, 0}) = 1 (in [8], left {0, 23})
select(9, [8], [], NULL, {0, 0})= 1 (in [8], left {0, 0})
read(8, , 4096) = 0
close(8)= 0
select(5, [4], [], NULL, {1, 0})= 1 (in [4], left {0, 99})
select(5, [4], [], NULL, {0, 0})= 1 (in [4], left {0, 0})
read(4, , 1024) = 0
close(4)= 0
open(/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libgpg-error.mo, O_RDONLY) =
-1 ENOENT (No such file or directory)
open(/usr/share/locale/en_US.utf8/LC_MESSAGES/libgpg-error.mo, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/locale/en_US/LC_MESSAGES/libgpg-error.mo, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/locale/en.UTF-8/LC_MESSAGES/libgpg-error.mo, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/locale/en.utf8/LC_MESSAGES/libgpg-error.mo, O_RDONLY) = -1
ENOENT (No such file or directory)
open(/usr/share/locale/en/LC_MESSAGES/libgpg-error.mo, O_RDONLY) = -1 ENOENT
(No such file or directory)
close(3)= 0
munmap(0x7f988d24e000, 4096)= 0
write(2, Assword database error: Decrypti..., 59Assword database error:
Decryption error: Decryption failed) = 59
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Bug#795639: assword fails with Decryption error: Decryption failed
Daniel Kahn Gillmor d...@fifthhorseman.net writes: does this succeed with gpg2 --decrypt as well, or just gpg --decrypt? Aha. Here's a problem: mithrandir:~/private/db$ gpg2 --decrypt personal gpg: error reading keyblock: Legacy key gpg: keydb_get_keyblock failed: Legacy key gpg: encrypted with RSA key, ID 7CE29A76E9769486 gpg: decryption failed: No secret key I have no idea what that means, and Google was not particularly enlightening. do you see files listed when you look at the GnuPG 2.1 secret key storage: ls -l ~/.gnupg/private-keys-v1.d/*.key Yes. what about checking to see the date that GnuPG 2.1 did the keyring migration: ls -l ~/.gnupg/.gpg-v21-migrated ? Looks like this afernoon just when this problem started. Depending on the output of the above, maybe you can try importing your secret keyring again: gpg2 --import ~/.gnupg/secring.gpg (this should have been imported automatically for you upon your first use of gpg 2.1 after the upgrade) I get a lot more legacy key errors, and this weird error that I don't understand: gpg: key D15D313882004173: no valid user IDs gpg: this may be caused by a missing self-signature gpg: keydb_get_keyblock failed: Legacy key gpg: key D15D313882004173: failed to re-lookup public key That key definitely has a self-signature. It's the same key I use for Debian. mithrandir:~/private/db$ gpg -kv D15D313882004173 pub 4096R/D15D313882004173 2009-05-29 [expires: 2017-09-17] uid [ultimate] Russ Allbery ea...@eyrie.org uid [ultimate] Russ Allbery r...@stanford.edu uid [ultimate] Russ Allbery r...@debian.org uid [ revoked] Russ Allbery ea...@windlord.stanford.edu uid [ultimate] Russ Allbery r...@cs.stanford.edu sub 4096R/7CE29A76E9769486 2009-05-29 [expires: 2017-09-17] sub 2048R/7D80315C5736DE75 2010-09-17 [expires: 2016-03-20] -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Bug#795639: assword fails with Decryption error: Decryption failed
Package: assword Version: 0.8-2 Severity: grave assword can no longer decrypt any of my password stores. It fails with the error: mithrandir:~$ assword dump foo Assword database error: Decryption error: Decryption failed The data store is not corrupt; running GnuPG on it manually works fine. This appears to be caused by the upgrade of gnupg2 to 2.1.7-2. Downgrading to 2.0.28-3 makes everything start working properly again. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages assword depends on: ii python2.7.9-1 ii python-gpgme 0.3-1+b1 ii python-gtk2 2.24.0-4 ii python-pkg-resources 18.0.1-2 Versions of packages assword recommends: pn python-xdo none ii xclip 0.12+svn84-4 assword suggests no packages. -- no debconf information
Bug#781231: [Pkg-puppet-devel] Bug#781231: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unsupported osfamily (Debian) or lsbdistid () at /usr/share/puppet/modules/apt/manif
Control: severity -1 important Christoph Berg christoph.b...@credativ.de writes: The Apt module seems to require the presence of the $lsbdistid fact, which is only available when lsb-release is installed. Neither puppet-module-puppetlabs-apt, puppet, nor facter have a Dependency (or any weaker relation) on that. puppet-common Recommends lsb-release for exactly this sort of reason, so it will be installed on Puppet clients in a default configuration. It's long been the case that you probably want to install lsb-release on any system on which you're running Puppet, or you'll be missing a pile of pretty significant facts that are widely used in Puppet manifests. We started doing that at Stanford back in the 0.20 days. I agree that the module should be more robust, and would be happy to see this fixed prior to the release if possible, but I don't think this is release-critical. (Meaning that I don't think we should remove this package from the release if no one gets to this.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
Chris Knadle chris.kna...@coredump.us writes: At present the openssh-server and openssh-client packages are altering /etc/ssh/ssh_config and /etc/ssh/sshd_config without prompting the user beforehand, even when they've been locally modified. I've pointed section § 10.7.3 of Debian Policy: • local changes must be preserved during a package upgrade (Appendix E also discusses this which I saw later) however the argument being made now is that the particular section of the config being altered wasn't changed by the user. Correct. The Policy statement is about preserving user changes, not about never touching any file that a user has modified in any way. The package is free to modify unchanged portions of the configuration file, and this has been routinely done during package updates in Debian for as long as I've been involved in the project. This is the current bug (severity serious): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780797 I think the maintainer should downgrade the severity of this bug, since I don't think it meets the definition of serious, but I'll leave that to Colin. Separately, I personally am not fond of this change and would rather that it only take effect on new installations, not existing installations. I find the security argument for this change to be rather dubious. But this is not a Policy violation; it's a judgement call by the maintainer whether the benefit of the change is worth the disruption of changed behavior on upgrades. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780797: Package modifying a user-modified config file? [Bug #780797]
Vincent Lefevre vinc...@vinc17.net writes: On 2015-03-21 13:14:08 -0700, Russ Allbery wrote: Correct. The Policy statement is about preserving user changes, not about never touching any file that a user has modified in any way. The package is free to modify unchanged portions of the configuration file, and this has been routinely done during package updates in Debian for as long as I've been involved in the project. I disagree. You disagree that this is what Policy says, or you disagree that this is a good idea? If it's the latter, I understand your point. If it's the former, well, you can disagree, but you're incorrect. Sorry. You have probably been misled by dpkg's behavior with conffiles, but that's primiarly because dpkg conffile handling is at the per-file level, and only knows whether the file has changed at all. This is not how configuration files that are not conffiles have been handled, and it applies only at the file granularity with conffiles. Consider a configuration that's broken into four or five separate conffiles. The ones that the user didn't change have always been updated silently. The Policy statement here is primarily about semantics, not about files. In such a case there would be *no way* for the user to tell Debian not to modify his configuration, i.e. an upgrade could silently break the user configuration, like this happened here. Policy does not prohibit every thing that a maintainer might want to do that may not be a good idea. I get that you find the change surprising. I don't particularly agree with it either. But Policy is not the stick with which to solve every problem you might have with what a package maintainer chooses to do. Sometimes things are just old-fashioned bug reports. :) The only time where a maintainer script could change a config file modified by the user is when this is absolutely necessary, e.g. because the behavior changed in the software, an option has been renamed, and things like that. That's certainly a valid point of view, but this is not the line that Debian has historically drawn. And drawing that line would result in a lot more prompting during dist-upgrades, so there's a tradeoff here. But even in these cases, this should be announced in the NEWS file. I'm inclined to agree with you in this case, but Policy doesn't currently make that a requirement. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
Ian Jackson ijack...@chiark.greenend.org.uk writes: But it mostly occurs when a dependency is indirected through an intermediate package. That is, A uses some feature in C, but the dependency is declared on B which depends on C. This is (perhaps surprisingly) not particularly common. That's partly because those of us who work on Lintian have been annoying maintainers about this as much as possible to try to get them not to do that. :) But in the case of perl it's nearly universal, because of the policy recommendation to depend on the metapackage `perl' rather than perl-base or perl-modules. I suspect this is an outgrowth of the fact that we've always felt that the split of the perl package was sort of wrong, in the sense that we did it for internal reasons that are valid, but the average user should not perceive it as being divided into multiple packages, and we generally should try to avoid treating it as such. I don't think `requires strict dependencies' is a very useful concept here. That xfonts-traditional uses (in a maintainer script) a perl module which has always been implied by `perl' can hardly be unusual. I don't think it makes sense to regard that as a particularly `strict'. There are certainly other packages in the archive with Perl maintainer scripts, although the ones I'm aware of I don't think use modules that have moved. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775795: [Pkg-puppet-devel] Bug#775795: puppet: Service's debian provider assumes SysV init
Faidon Liambotis parav...@debian.org writes: On Debian systems (i.e. on $::operatingsystem == debian), the default provider is debian; this is a separate provider that inherits the init provider but overrides a few methods to add invoke-rc.d support. The systemd provider, on the other hand, is default only for osfamily archlinux and for osfamily redhat operatingsystemmajrelease 7. Is Puppet *using* invoke-rc.d for all actions? If so, this should actually work properly, I think, since that should use systemd where appropriate. Or did you mean update-rc.d instead of invoke-rc.d? However, this means that Service (without an explicit provider) is broken for at least those two use cases: - enable = false/true doesn't work for packages that ship a systemd unit file, - Service doesn't work at all with user-supplied systemd units or for (custom, mostly) packages that do not ship init.d scripts. At first glance, and without looking at any of the details, it seems like an appropriate fix would be for Puppet to just use the service command for start/stop/restart/reload/status, and update-rc.d for enable/disable. That should do the right thing in all three init systems. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771126: Bug#771191: Bug#771126: Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright
Fabian Greffrath fab...@greffrath.com writes: Am Dienstag, den 02.12.2014, 23:29 +0100 schrieb Bastien ROUCARIES: And offencive (sexist) for 50% of the population the women... Now it's getting really ridiculous. Gosh, it's a picture of a woman! Er, no, it's not just a picture of a woman. It's a cropped Playboy centerfold. In other words, it's a porn shot (if one from the fairly artistic side of that spectrum) that's been cropped to remove the explicit sexual content. The image itself is one thing; the surrounding context of the image makes it a bit worse. Obviously, in terms of great problems facing the world, this isn't the worst. But having the standard test picture for image software be a porn image does send certain messages, and they're probably not messages that we (by which I mean the general software and tech industry as a whole) actually want to be sending. This is not a problem of Debian's creation, and we can't fix the world, but insofar as we can contribute to not sending those messages, I think that makes the world, and Debian, a better place. Thank you very much to Reinhard for doing the irritating and tedious work of starting to replace it. It feels like a distraction from other work and a thankless task, I know, but small things like this really do make people happier and help people in tiny ways. Software became a bit less off-putting, a bit less locked into a particular model of how genders are supposed to interact, and a tiny bit more welcoming. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758600: shibboleth-sp2-utils: postinst fails on initial installation
Luca Bruno lu...@debian.org writes: As I didn't see much reaction, I went ahead and did some testing with a patched postinst. It seems to be ok in both cases (apache2 and nginx), I'm attaching the patch here. I've recently rotated my key, and my new one is not yet included in the bpo keyring. Can anybody please double-check the attached patch and upload it to bpo? Hi Luca, Thanks for taking care of this, and sorry about the delay. I see that this is waiting backports processing. I committed your upload to the packaging repository and then also added a patch that I think is a bit cleaner should a later backport be done, but I think your change will work fine. Sorry about that oversight! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758600: shibboleth-sp2-utils: postinst fails on initial installation
Luca Bruno lu...@debian.org writes: I'm raising the severity of this, since the backported package is currently unusable in this case, due to the hard-coupled implicit dependency on Apache. Russ, can you please revert/modify your a2enmod changes for the ~bpo revision? I'll try to take a look, but I no longer use Shibboleth and handed the package maintenance off. Copying the general mailing list. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742140: [oss-security] Re: Bug#742140: libpam-oath: PAM module does not check whether strdup allocations succeeded
Andreas Barth a...@ayous.org writes: we have the following debian bug report about an security isuse in libpam-oath (source oath-toolkit, upstream web page http://www.nongnu.org/oath-toolkit/ ). What is the appropriate process to get an CVE number on it? This issue is already public, as it is documented in the debian bug tracking system. Is not checking memory allocations for failure in this fashion considered CVE-worthy? I'm probably missing something, but this seems difficult to exploit: the first strdup is only trying to allocate a byte of memory, and the second will not allocate more than MAX_OTP_LEN memory due to an earlier check. This means the attacker would have to have essentially exhausted system memory already to force strdup to return NULL. And, even if that happens, strdup returns NULL, which leads immediately to a NULL pointer dereference and presumably a process crash. But to create this situation, the attacker has to nearly exhaust all process memory, and could just go a step farther and exhaust all memory, which would almost certainly result in a process crash anyway, or an OOM kill. Am I overlooking something? -- Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760804: serf: FTBFS: Directory /usr/include/mit-krb5 found where file expected.
James McCoy james...@debian.org writes: I understand that using -isystem works around FTBFS in other packages which are using very high warning levels. However, it seems to me those packages should reduce their use of -W flags instead of assuming all the libraries they depend on live up to those flags (i.e., require all dependencies to use -isystem instead of -I). Well, it's more complicated than that. Most libraries aren't fully warning-clean, and most packages don't use -isystem, and yet this usually doesn't come up. That's because the headers are installed in /usr/include, and there GCC has special code that marks those as system headers and suppresses the warnings. The problem here is that, to support the co-installability of krb5-dev and heimdal-dev, the header files are moved into a path that GCC doesn't recognize as being a system header path. So... maybe those two libraries have to be treated very specially for warnings and live up to a higher standard than the rest of the archive, but that's rather unappealing, since there are a lot of different warning flags. Or we have to revert the changes to allow the dev packages to be co-installed more clealy, but that seems bad too. I think fixing scons is actually the path of least resistance here, and anything else leads to regressions in other things we care about in the archive. It shouldn't require anything more than treating -isystem identically to -I, which I would hope is a very small change, and it's one that upstream should accept fairly readily. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760804: serf: FTBFS: Directory /usr/include/mit-krb5 found where file expected.
James McCoy james...@debian.org writes: On Tue, Sep 09, 2014 at 12:48:11AM -0400, Benjamin Kaduk wrote: krb5 has started supplying pkgconfig files in 1.12; would it be easier for serf to use gssapi.pc instead of parsing krb5-config's output? No, since the issue is the lack of understanding of the -isystem flag, which is still going to be emitted by pkg-config, twice in fact: $ pkg-config --cflags krb5-gssapi -isystem /usr/include/mit-krb5 -isystem /usr/include/mit-krb5 I suspect Ben's hope was that, if using pkgconfig, scons would not make an attempt to parse the flags and split them apart, and would instead just use them as-is in the compiler invocation. I must say that I've come to consider build systems that think they know more than I do about what compiler flags mean to be a latent bug. Libtool has had no ends of problems and irritating behavior because it likes to think that it knows what all the compiler and linker flags are and how to rearrange them. Given that one of scons's goals was to be simpler and more predictable than the Autotools, it's unfortunate it fell into the same trap in this specific instance. (That said, this is also partly pkgconfig's fault for not separating CFLAGS and CPPFLAGS.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758533: [Pkg-utopia-maintainers] Bug#758533: network-manager: wifi connected, internet connection does not work
Michael Biebl bi...@debian.org writes: we just discussed this issue. It's most likely caused by a systemd update where we restart journald in postinst. That somehow seems to break the stdout-jounal forwarding, e.g. from NM to its dhclient child process If you restart NetworkManager.service, this will reset the state and fix the issue. By downgrading to -1, you triggered such a restart of NetworkManager, so the downgrade is a red herring. Ah! Yes, that exactly matches the situation where this bug showed up. I was confused, too, since I thought I'd upgraded Network Manager a while back, so this explains that as well. Sorry about the incorrect diagnosis! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753589: systemd: missing pre-dependencies for runlevel(8) etc.
Andreas Metzler ametz...@bebt.de writes: Could you use this opportunity to move to libgcrypt20? It would be nice to avoid adding th pre-dependency on libgcrypt11 now and later have another discussion when replacing with one on libgcrypt20. Obviously it's a good idea to move with SONAME changes, but for the record, there's no need to have the discussion again after a library SONAME change. Pre-Depends on libraries should be assumed to track SONAME changes in that library. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Gerrit Pape p...@dbnbgs.smarden.org writes: I looked into latest policy, but did not find anything about systemd support. I'm surprised that this is now a release critical bug, and the package marked for removal. What's the justification? I'm very dubious about this being release-critical. This package hooks into /etc/inittab, does systemd not automatically manage services from inittab? Correct, systemd doesn't use inittab. Isn't it systemd having release critical bug then? I don't think it's likely that systemd will support inittab. The semantics of inittab are quite a bit inferior to what's available with very little additional work using the native configuration format, and the regular inittab jobs are provided by regularly-configured services. Yes, that is a disruptive change for people who were using inittab to run other things. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: RFH: Re: Bug#752075: daemontools-run: Add systemd support
Gerrit Pape p...@dbnbgs.smarden.org writes: Important thing to know is: init scripts don't work out for this. The service management concept of daemontools and runit is, amongst other things, a process tree with guaranteed process state, including envrionment. init scripts don't provide that. There's no reason to switch away from inittab for sysvinit. For systemd, a unit file can easily do everything that you would get from inittab. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747805: duo-unix: FTBFS: error: OpenSSL not found
Control: tags -1 patch Looks like the package is just missing a Build-Depends on libssl-dev. Presumably previously libcurl4-openssl-dev depended on libssl-dev, and this package was (incorrectly) relying on that continuing. Once I add libssl-dev to Build-Depends, the package builds fine for me. Let me know if I can assist with an NMU. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748425: needs update for new iptables-persistent
Package: puppet-module-puppetlabs-firewall Version: 1.0.2-1 Severity: grave With version 1.0.1 of iptables-persistent, this module fails with the error: Error: /Stage[main]/Firewall::Linux::Debian/Service[iptables-persistent]: Could not evaluate: Could not find init script for 'iptables-persistent' It looks like the latest version converts iptables-persistent to a set of modules for netfilter-persistent, and has renamed the init configuration to netfilters-persistent. The Puppet module will need a corresponding update. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/1 CPU core) 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 puppet-module-puppetlabs-firewall depends on: ii puppet-common 3.5.1-1 puppet-module-puppetlabs-firewall recommends no packages. Versions of packages puppet-module-puppetlabs-firewall suggests: pn ebtables none ii iptables 1.4.21-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746395: FTBFS for binary-indep builds (missing python build dependency)
Source: krb5 Version: 1.12.1+dfsg-1 Severity: serious When the documentation is built, 1.12.1+dfsg-1 fails to build with the following error: cd build/doc make substhtml substpdf make[1]: Entering directory '/«BUILDDIR»/krb5-1.12.1+dfsg/build/doc' sed -e 's|@SRC@|../../src|g' \ -e 's|@DOC@|../../src/../doc|g' ../../src/doc/Doxyfile.in Doxyfile rm -f ../../src/../doc/version.py gcc -E -I../../src - ../../src/doc/version.py.in ../../src/../doc/version.py rm -rf doxy rst_apiref rst_composite doxygen /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6456: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6471: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6526: warning: Unsupported xml/html tag string found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6526: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6533: warning: Unsupported xml/html tag string found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6533: warning: Unsupported xml/html tag string found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6456: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6471: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6526: warning: Unsupported xml/html tag string found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6526: warning: Unsupported xml/html tag number found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6533: warning: Unsupported xml/html tag string found /«BUILDDIR»/krb5-1.12.1+dfsg/src/include/krb5/krb5.hin:6533: warning: Unsupported xml/html tag string found cwd=`pwd`; cd ../../src/../doc/tools \ doxy.py -i $cwd/doxy/xml -o $cwd/rst_apiref /bin/sh: 2: doxy.py: not found This is because $(PYTHON) expands to the empty string and is therefore omitted in front of doxy.py, which in turn is because no Python is found during the build due to the missing build dependency. Caught by the archive-wide rebuild to test GNU make 4.0. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746395: FTBFS for binary-indep builds (missing python build dependency)
Control: severity -1 minor Sam Hartman hartm...@debian.org writes: I'm kind of surprised that python-lxml doesn't pull in python. Will confirm that sbuild -A dtrt though before marking closed. It would have. The problem was actually that make 4.0 breaks build-arch target detection, which meant that dpkg-buildpackage fell back on debian/rules build but didn't install B-D-I. That said, adding python to B-D-I is still correct since the build uses Python directly, not only via something provided by python-lxml. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743991: FTBFS: Failed 3/1877 tests, 99.84% okay, 42 tests skipped.
Christian Hofstaedtler z...@debian.org writes: During a test rebuild your package failed to build. The test rebuild was done using sbuild, in unstable. The build produced this output: util/network/client.FAILED 21-22 util/network/server.ok util/tokens.FAILED 10 util/vector.ok util/xmallocskipped (xmalloc tests only run for maintainer) util/xwrite.ok Hm. Those are timing-sensitive tests that can fail on extremely slow systems, but I did have them tweaked so that they pass on all of Debian's buildds. I notice that this also uses an obsolete version of Ruby (1.9). Please update your package to use either the meta package (ruby) or ruby2.1. Yeah, I was getting ready to make that change. (There's no way for this package to use the metapackage.) It currently builds against 1.9 and 2.0; I'll change that to build against 2.0 and 2.1 and upload without any changes to the tests and see if the buildds are still happy. If so, I think the FTBFS is spurious. I've been monitoring the progress on the Ruby migration and thought I had a bit of grace period before that became urgent, and was trying to get a new release out, but I'll go ahead and do the packaging changes now and worry about that later. Thanks for the report! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743991: FTBFS: Failed 3/1877 tests, 99.84% okay, 42 tests skipped.
Christian Hofstaedtler z...@debian.org writes: * Russ Allbery r...@debian.org [140409 02:46]: Hm. Those are timing-sensitive tests that can fail on extremely slow systems, but I did have them tweaked so that they pass on all of Debian's buildds. Actually this should be quite a fast system. Yeah, I just reproduced. I should have checked first, sorry. This was a different problem. Looks like Linux changed the amount of data that it's willing to buffer yet again, so tests that have to write enough data so that a network write will actually block are not blocking again. I'll change the thresholds in this upload. Yeah, I was getting ready to make that change. (There's no way for this package to use the metapackage.) It currently builds against 1.9 and 2.0; I'll change that to build against 2.0 and 2.1 and upload without any changes to the tests and see if the buildds are still happy. If so, I think the FTBFS is spurious. Note that there's also a ruby-all-dev metapackage. Maybe you can make use of it... Unfortunately, Ruby's mkmf system doesn't, so far as I can tell, have any way of building for all installed versions, so I need to know what versions to build for so that I can iterate through the Ruby interpreters. If there are tools available to do this for a build system that uses mkmf directly, I'd be happy to switch over. (But I don't mind doing uploads for new Ruby versions; it's not hard, and I should be able to generally do so quickly.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743991: FTBFS: Failed 3/1877 tests, 99.84% okay, 42 tests skipped.
Christian Hofstaedtler z...@debian.org writes: I've attached a patch that uses dh_ruby to build the Ruby extensions; I haven't done any further checking other than it builds. Note that this still builds with `--enable-ruby` to get `extconf.rb` in ruby/, and then `make install` ends up installing an additional copy of the .so into a weird path in debian/tmp. (dh_ruby takes care of installing into the correct paths in debian/ruby-remctl.) Awesome, thank you! That's just what I was looking for. I didn't know that dh_ruby could deal with that build system and deal with the root being a subdirectory. Very nice. The only thing I had to change is that dh_ruby isn't actually automatically invoked by adding the ruby sequence, since it expects debhelper to see Ruby as the top-level build system. So I had to add an explicit call to dh_ruby --install in the override_dh_install rule. But then everything worked great. I also added the XB-Ruby-Versions header, since that seems to be best practice these days (although I didn't manage to find it in the Ruby packaging policy). Now uploaded, with ruby-remctl built against 2.0 and 2.1. Thank you for your work on this! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739505: libcgi-application-perl: CVE-2013-7329: information disclosure flaw
An API change indroduced in 2008 alrealy (commit 61d327646f01fe) may cause unexpected and unwanted data dumps of a complete set of web query data and environment to the public. Developers of web apps written before the change are probably unaware of the problem since the general behaviour does change only in the case of a software error. For those who haven't looked at it in detail, the bug here is that CGI::Application will dump the script environment to the web client if the Perl application that uses it doesn't define a start runmode. However, not defining a start runmode is an erroneous use of the library and a bug in the calling application, and all the examples in the documentation do set a start runmode. I agree that the behavior when a runmode is not defined is surprising and a bug, but I think treating it as a full-blown security vulnerability in CGI::Application (as opposed to the calling application) may be overkill. That said, it looks like Fedora did treat it as a security update. The patch in the Github pull request does look correct (although it's an irritating patch from a security perspective since it includes apparently arbitrary code reformatting). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740226: does not work with python-lxml 3.3.1-1
Package: xml2rfc Version: 2.4.3-1 Severity: serious Since python-lxml was upgraded to 3.3.1-1, xml2rfc no longer works. It fails with the following backtrace: Traceback (most recent call last): File /usr/bin/xml2rfc, line 225, in module main() File /usr/bin/xml2rfc, line 139, in main xmlrfc = parser.parse() File /usr/lib/python2.7/dist-packages/xml2rfc/parser.py, line 373, in parse context.resolvers.add(caching_resolver) AttributeError: 'lxml.etree.iterparse' object has no attribute 'resolvers' Downgrading python-lxml to 3.2.0-1+b1 from snapshot.debian.org fixes the problem. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xml2rfc depends on: ii python 2.7.5-5 ii python-lxml 3.2.0-1+b1 pn python:any none ii sgml-base1.26+nmu4 xml2rfc recommends no packages. xml2rfc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
