Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
On Fri 2022-03-18 09:13:08 +, Adam D. Barratt wrote: > Unfortunately it looks like the upload failed: > > gnupg2_2.2.27-2+deb11u1.dsc: Refers to non-existing file > 'gnupg2_2.2.27.orig.tar.bz2.asc' Sigh. thanks for the note. I've just tried again, this time including the orig.tar.bz2.asc in the upload. --dkg signature.asc Description: PGP signature
Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
On Thu 2022-03-17 17:49:04 +, Adam D. Barratt wrote: > On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote: >> On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote: >> > Control: tags -1 + confirmed d-i >> > > [...] >> > That looks fine to me, but will need a d-i ack as the package >> > builds a >> > udeb; tagging and CCing accordingly. >> >> Understood -- i'll wait for a d-i ack before uploading. > > As we're getting very close to the window for 11.3 closing, please feel > free to upload. I've just uploaded gnupg2/2.2.27-2+deb11u1 to bullseye now. Please let me know if there are any problems. thanks for your ongoing work maintaining debian stable! --dkg signature.asc Description: PGP signature
Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed d-i > > On Thu, 2022-01-27 at 17:02 -0500, Daniel Kahn Gillmor wrote: >> Please consider an update to GnuPG in debian bullseye, from version >> 2.2.27-2 to 2.2.27-2+deb11u1. >> > > The version mentioned above is correct, but the proposed changelog is > not: > > +gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium > > (it should be "deb11u1", not "deb11+1"). thanks for catching that, i've corrected it and pushed the corrected version to the debian/bullseye branch in salsa. > That looks fine to me, but will need a d-i ack as the package builds a > udeb; tagging and CCing accordingly. Understood -- i'll wait for a d-i ack before uploading. --dkg signature.asc Description: PGP signature
Bug#951367: [PATCH] don't pass an empty arg to wget when --verbose is applied (Closes: #951367)
If NVSWITCH is empty, the old code was running wget '' …
But this causes wget to fail to fetch the empty URL, which means the
return code ends up being non-zero. This breaks sbuild-createchroot,
which apparently always passes --verbose to debootstrap.
This error was introduced in 14f0b7aafb4d568b027baeecee08cfac6c4f874d,
so is relatively recent.
---
functions | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/functions b/functions
index a3c93e9..d6725f7 100644
--- a/functions
+++ b/functions
@@ -93,7 +93,7 @@ wgetprogress () {
ret=$({ { wget $@ 2>&1 >/dev/null || echo $? >&2; } |
"$PKGDETAILS" "WGET%" "$PROGRESS_NOW" "$PROGRESS_NEXT" "$PROGRESS_END" >&3; }
2>&1)
: ${ret:=0}
else
- wget "$NVSWITCH" "$@"
+ wget $NVSWITCH "$@"
ret=$?
fi
return $ret
--
2.25.0
Re: Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Hi Adam-- On Tue 2018-10-23 16:18:05 +0100, Adam D. Barratt wrote: > Sure, but that's not what I said. My distinction was between including > the gnupg update in the point release versus pushing it more urgently > via stable-updates. I never implied the updates shouldn't be released at > all. thanks for the clarification, i didn't understand that distinction. I'm glad you're considering it at least for the point release. > FWIW I don't recognise that characterisation. Yes, I should have > confirmed the Security Team's intentions at an earlier point, but I > don't consider that buck-passing or the situation deadlocked. fwiw, i'd heard privately earlier from the security team that they don't see this fix as in their bailiwick, but they hadn't responded to my requests for comments in public on the BTS. So the deadlock misperception may have been due to what looked like a longer delay from my vantage point. I'm glad it's not deadlock! --dkg
Re: Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On Tue 2018-10-23 20:00:06 +0100, Adam D. Barratt wrote: > From discussions elsewhere, I understand that the "raw" upstream > enigmail - i.e. installed via upstream's addons service - is actually > already compatible with the new Thunderbird version, and the problem > only affects the Debian packages - is that correct? (Specifically, > upstream includes some kind of compatibility shim, which is not shipped > in our packages for DFSG reasons.) the version of enigmail shipped in the mozilla add-ons has at least two problems, both arguably DFSG-free-related, and both described in #909000, i believe. 0) it ships a pre-built copy of OpenPGP.js, which i have not been able to build directly in debian due to a deep dependency mess (see #787774) 1) by default it downloads a binary from the internet, stores it in the user's thunderbird profile, and executes it as the user without checking its integrity with anything beyond an HTTPS (see #891882) Encouraging users with sensitive communication needs to install something with either of these choices made this way is pretty problematic. And users who install enigmail from the add-on store will most likely never revert to the debian packages that fix these misfeatures :/ > Explicitly CCing KiBi is generally more effective, as -boot@ is a > fairly busy list at times. I imagine he'll want the SRM review > completed first, but that also depends on whether the changes actually > impact d-i's usage, which I'm not entirely clear on - could you provide > any insight there? d-i's usage is limited to gpgv; the gpgv-udeb is deliberately narrowly targeted, since all d-i needs from gpgv is (a) interpret the debian distro public keys, and (b) verify signatures on the apt manifests. None of the changes in this update should affect gpgv's behavior in either of these tasks. hope that helps to clarify, --dkg signature.asc Description: PGP signature
Re: Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
Thanks to Adam for your ongoing work on the stable releases! I just wanted to clarify a few points here. On Tue 2018-10-23 08:57:08 +0100, Adam D. Barratt wrote: > An issue is that the gnupg update itself doesn't really qualify for > stable-updates any more than it qualifies for stable-security. The > changes to gnupg itself are at best security improvements, which isn't > justification for forcing all stretch users to install the new version > as a matter of urgency - indeed, if the new version of enigmail weren't > relying on new functionality no-one would be suggesting pushing gnupg so > urgently - nor, I imagine, backporting all of the mentioned features. I would be pushing for a stable point release for GnuPG at least for the cryptographic defaults refresh, and the series of minor bugfixes that resolve outstanding problems. I brought up the idea of a cryptographic defaults refresh nearly a year ago [0], and it's overdue (my fault). i don't think it's responsible for us to ship a new stable installation in 2019 that by default creates 2048-bit RSA keys that claim to be valid through 2021. The problems with bugs like handling import of malformed keys (#906545), for example, are bad enough to have already caused extra labor in the form of stretch-backports maintenance to work around the fact that these bugs are present in debian stretch. Thanks are due to Roger Shimizu (cc'ed) for handling that ongoing task! Note that malformed keys are significantly more present today than they were when stretch was released, due to ongoing attacks on the keyserver infrastructure. :( The fact that the upstream-supported version of enigmail that works with the upcoming stretch version of thunderbird depends on these fixes is, as you say, another reason to suggest inclusion in debian stretch. > It's also going to need a d-i sign-off, because gnupg produces a udeb. I've added debian-boot@lists.debian.org in the hopes that someone from there can supply a d-i sign-off. I've done my best with this series of patches to minimize disruption to this critical part of debian stretch while still supporting the shifting network ecosystem that depends on it. If these changes cause any significant disruption, please point it out to me so that i can try to repair it. But if debian's policies and practices don't have a way to get these fixes to stable users who might depend on them for matters of critical security (even if the gnupg updates are not in themselves deemed to be critical security updates), then we're failing our stable users. If that's the case, then either debian's policies or practices need to change, or debian needs to get a more capable maintainer for GnuPG who can figure out how to effectively navigate or avoid what feels like a buck-passing deadlock between two (maybe three) overworked/underresourced teams. I welcome any help in that regard. All the best, --dkg [0] https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2017-October/006148.html signature.asc Description: PGP signature
Bug#795735: partman-crypto: always encrypt swap
It's a shame that encrypted swap by default hasn't happened yet for debian. As i see it, the three outstanding concerns are: a) source of entropy at boot time b) actual hardware performance c) suspend-to-disk boot time entropy - The linux kernel's getrandom() situation is much better today than it was two years ago. It's actually possible to get blocking bytes when needed early, without forcing yourself into a blocking situation later once the kernel's prng is initialized. See getrandom(2) and random(4) for more details. actual hardware performance --- I suspect the cost is negligible on most hardware today, particularly when compared to the disk I/O. If you're swapping, you're likely to be waiting for the disk, not waiting for the CPU. That said, i agree that users with specialized situations ought to be able to disable this. But the default should still be on. suspend-to-disk --- If the user suspends to disk, then the memory will be written to disk. this is definitely a leak. However, we currently write the memory to disk *without* suspending to disk, so even if we don't handle suspend-to-disk "safely" it's still a win to encrypt swap, because we protect the people who do *not* suspend to disk. So that's the simplest solution to the suspend-to-disk problem: just punt on it for now, and leave that case unprotected. If suspend-to-disk (or rather, resume-from-disk) is the only problem, then we should look for ways to opportunistically take advantage of other non-disk hardware on which we could store any ephemeral keys needed for restoration. For example, on systems with rewritable nvram, it's conceivable that we could suspend to the encrypted volume, and then stash the ephemeral encryption key in nvram. Upon resume, read the key from nvram into main memory, clear the nvram, and restore from the encrypted volume. This isn't perfectly secure (an attacker with both the disk and the nvram can recover your memory from the suspend file) but it is a significant win against an attacker who physically removes the hard disk. So i think we ought to outline the steps that need to be taken to make this happen by default. Which pieces need to be updated, and how? --dkg signature.asc Description: PGP signature
Bug#877012: apt-setup: debian sources.list entries should have signed-by options pointing to specific keys
Package: apt-setup
Severity: wishlist
Control: clone -1 -2
Control: retitle -2 set up local repository keys using signed-by option, and do
not use "apt-key add"
Control: block -1 861695 -2
Control: affects 861695 + apt-setup
When apt-setup creates a sources.list, it currently just expects every
repository key to be already present in /etc/apt/trusted.gpg or
/etc/apt/trusted.gpg.d/*.gpg.
collecting all keys in one repository means that each key is
authorized to sign other repositories as well. This lack of scoping
makes it difficult to constrain repository owners from malicious
behavior. It also makes it difficult to know when to remove old keys
-- should the wheezy archive signing key still be enabled on my buster
system?
In #861695, i'm trying to get debian-archive-keyring to ship the
standard repository keys in /usr/share/keyrings/. on a system where
that's done, apt-setup should write the sources.list snippets for the
debian repos with a "signed-by" option (see sources.list(5), which
points specifically to the key that should be used to authorize this
repo.
I think doing this right for debian repositories is going to require
#861695 to be corrected first, which is why the first bug report here
("debian sources.list entries should have signed-by options pointing
to specific keys") is marked as blocked by that bug.
But apt-setup can fix its configuration of any pre-seeded local
repositories without waiting on the debian-archive-keyring package,
which is the point of the second bug ("set up local repository keys
using signed-by option, and do not use "apt-key add"").
In particular, generators/60local can place the proposed key into a
file *outside* of /etc/apt/trusted.gpg.d/, and can add the signed-by
argument to the sources.list stanza it creates.
The result of fixing these two bugs should be that new installations
can have an empty /etc/apt/trusted.gpg and nothing in
/etc/apt/trusted.gpg.d/*.gpg, and each repository added will be
individually authenticated. This is a pre-requisite for being able to
more tightly constrain software repositories (e.g. pinning, etc), and
should be the default of the future.
Thanks for helping to maintain debian-installer!
--dkg
Re: [pkg-gnupg-maint] Last chance for d-i changes in stretch
On Mon 2017-05-29 08:16:11 +0200, Didier 'OdyX' Raboud wrote: > If I upload win32-loader now, it will embed gpgv-win32 2.1.18-8, no matter > which gnupg2 version will be part of stretch. There are three alternatives, > in > decreasing order of preference: > * get gnupg2 in testing, upload win32-loader to unstable, migrate it I've just filed unblock request #863734, which will hopefully achieve this result. --dkg signature.asc Description: PGP signature
Bug#851774: [pkg-gnupg-maint] Bug#851774: Stop using apt-key add to add keys in generators/60local
On Sat 2017-02-04 19:48:54 -0500, Cyril Brulebois wrote: > I'm fine with (discovering and) following best practices. :) > [ dkg wrote: ] >> Regardless of the choice of filesystem location (fragment directory or >> elsewhere), gpgv does want to see the curated keyrings it depends on >> in binary format, so on to the next bit: > > I'm a bit confused here: apt-get update (in a sid chroot, not attempted > in d-i) is fine with an armor key in the fragment directory; are you > saying that using the Signed-by option for sources.list would mean > having to have a (curated) keyring, and an non-armored version, hence > the need for the transformation you're suggesting below? Sorry, i guess it's possible that apt is doing something fancier that i don't know about, then. gpgv on its own expects the --keyring files it encounters to be either a sequence of raw OpenPGP packets that together form a series of OpenPGP certificates (a.k.a. "a keyring") or GnuPG's "keybox" format. AFAIK, gpgv does not accept ascii-armored files for its --keyring argument. maybe the apt folks can weight in on what's going on with armored fragments? If it's converting them before handing them off to gpgv, maybe you can just count on it to convert the files that aren't in the fragment directory as well? > Remember we're talking about adding extra repositories with custom d-i > configuration, so I'm fine with people having broken stuff because they > pasted a whole mail… agreed, we can expect these folks to get the details right. > No awk in d-i, so I'll go with the strict version and we'll see if we > have users who could complain and why. bummer, no awk! > Depending on answers to various questions above, we'll see about adding > new applets to busybox if needed. I hope you saw my followup using uudecode instead of base64. However, it's still awk-dependent. :/ --dkg signature.asc Description: PGP signature
Bug#851774: [pkg-gnupg-maint] Bug#851774: Stop using apt-key add to add keys in generators/60local
On Sat 2017-02-04 19:35:58 -0500, Daniel Kahn Gillmor wrote:
> Over in #831409, i mentioned this simple pipeline to perform the actual
> transformation:
>
> awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d
>
> Unfortunately, it looks to me like busybox doesn't offer a base64 applet
> at the moment, which would otherwise allow d-i to do the de-armoring
> entirely with busybox. I could probably knock that applet together if
> people want it -- it looks like busybox already has b64 subroutines in
> it.
ah, no need for a base64 applet, since busybox has a uudecode applet.
using only busybox, the following pipeline should be fine for
de-armoring:
awk 'BEGIN{ print "begin-base64 644 -" } /^$/{ x = 1; } /^[^=-]/{ if (x) {
print $0; } ; } END{ print "" }' | uudecode
hth,
--dkg
signature.asc
Description: PGP signature
Bug#851774: [pkg-gnupg-maint] Bug#851774: Stop using apt-key add to add keys in generators/60local
Hi all--
On Sat 2017-02-04 18:25:52 -0500, Cyril Brulebois wrote:
> I'm adding gnupg maintainers in cc since they might have interesting
> tips for the implementation. Context: we need to replace apt-key add
> calls with dropping files under the appropriate names for extra
> repositories in a Debian Installer context.
Thanks for the Cc, KiBi.
I think that extra repositories should *not* have their keys added to
/etc/apt/trusted.gpg.d/*.gpg ("the fragment directory") by default,
since that authorizes the extra key to make valid signatures for the
main archive.
If the extra repo has its own key, it should be authorized to make
signatures only for the extra repo, and nothing else (similarly, the
official debian archive keys *shouldn't* be authorized to make
signatures for the extra repo).
So if we're talking about adding extra repositories for a debian stretch
installer, as i said over on #853858:
for Debian 9 ("stretch") and later, you should place these keys (in
binary form) someplace within /usr/local/share/keyrings/ and add a
"Signed-By:" option to the relevant apt sources (see sources.list(5)).
Does that strategy sound right overall to the rest of you?
Regardless of the choice of filesystem location (fragment directory or
elsewhere), gpgv does want to see the curated keyrings it depends on in
binary format, so on to the next bit:
> so I think we need to have some kind of autodetection code. gnupg
> maintainers: is grepping for “BEGIN PGP PUBLIC KEY BLOCK” enough to
> decide between armored and non-armored? Or do you have any better
> solutions?
If the keyring is non-armored, i assume that we're just going to try to
use it as-is, without transformation. So the question is: which
incoming keys do we want to try to transform?
I'd err on the strict side and say that we really only want files that
contain nothing but a public key block. That is, if there's any garbage
text before the ASCII-armored header, we probably want to reject the
file rather than trying to transform it. This strictness avoids
tripping up in really bizarre corner cases (like if someone provides an
non-armored key that contains a notation, uid, uat, or other embedded
data that itself has the string "BEGIN PGP PUBLIC KEY BLOCK" in it). I
can cook up such a perversity if it would make anyone happy ;)
The strictness does mean that people who'd, say, copied and pasted an
entire e-mail message that includes a key and expected it to JustWork™
might be disappointed, but i might be OK with that. Being clean about
what's in your repo keyrings is a habit we want to cultivate.
If you agree with being strict, then the following pipeline should
return 0 if the keyring is ASCII-armored:
head -n1 | grep -Fxq -e '-BEGIN PGP PUBLIC KEY BLOCK-'
If you want to be a little less strict and permit arbitrary whitespace
before the block, you could do:
awk '/[^[:space:]]/{ print $0; exit }' | grep -Fxq -e '-BEGIN PGP
PUBLIC KEY BLOCK-'
I've tested and both of these pipelines appear to work with their
busybox variants using busybox 1:1.22.0-19+b1 on amd64.
So if you're OK with that test, then you need the transformation:
Over in #831409, i mentioned this simple pipeline to perform the actual
transformation:
awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d
Unfortunately, it looks to me like busybox doesn't offer a base64 applet
at the moment, which would otherwise allow d-i to do the de-armoring
entirely with busybox. I could probably knock that applet together if
people want it -- it looks like busybox already has b64 subroutines in
it.
Hope this helps! I'm happy to follow up on it with you.
--dkg
signature.asc
Description: PGP signature
Bug#823982: debootstrap: --variant=fakechroot fails when host system does not have dbus installed
Package: debootstrap Version: 1.0.81 Severity: wishlist Control: affects -1 fakechroot dbus debirf On a very minimal/lean system running debian sid, i tried to do the following as a non-privileged user: fakechroot fakeroot /usr/sbin/debootstrap --variant=fakechroot --include=dbus sid ~/target the result was a failed install: [...] W: Failure while configuring base packages. This will be re-attempted up to five times. W: See /home/dkg/target/debootstrap/debootstrap.log for details (possibly the package dbus is at fault) 1 dkg@demo:~$ looking in ~/target/debootstrap/debootstrap.log shows the following error message repeated five times: 1 dkg@demo:~$ tail -n 6 ~/target/debootstrap/debootstrap.log Setting up dbus (1.10.8-1) ... dbus-uuidgen: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory dpkg: error processing package dbus (--configure): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: dbus 0 dkg@demo:~$ weirdly, dbus-uuidgen works fine under fakeroot and fakechroot, which is what makes me suspect debootstrap being the cause of the problem: 0 dkg@demo:~$ fakechroot fakeroot chroot ~/target dbus-uuidgen c53d40afb5e8a5a5788f7c4e573267bf 0 dkg@demo:~$ This also has an effect on debirf, since debirf depends on debootstrap's fakechroot functionality to build an iso as a non-privileged user. This is reproducible from an amd64 host system with the following packages: 0 dkg@demo:~$ dpkg -l fakeroot fakechroot debootstrap libdbus-1-3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii debootstrap1.0.81 all Bootstrap a basic Debian system ii fakechroot 2.18-1 all gives a fake chroot environment - ii fakeroot 1.20.2-1 amd64tool for simulating superuser pri dpkg-query: no packages found matching libdbus-1-3 1 dkg@demo:~$ --dkg signature.asc Description: PGP signature
Re: [pkg-gnupg-maint] Bug#814027: "ts209" d-i image failed to build due to size
On Mon 2016-02-15 22:47:11 -0500, Martin Michlmayr wrote: > I had an idea on how to solve this problem: in addition to building > gpgv-udeb from gnupg2, you could build a gpgv1.4-udeb on armel. I > could then use that gpgv1.4-udeb on the armel subarch with the size > issues. > > Would that work for you? I've attached a proposed patch. I've uploaded this patch for now so that the stretch installers can be rebuilt for the tighter armel platforms. But i'd really like to pursue Werner's suggestion about minimizing the libgcrypt udeb where possible, so we can drop gpgv1.4-udeb entirely. --dkg
Re: shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)
Hi Stephen--
Thanks for the prompt response!
On Mon 2016-02-15 07:26:14 -0500, Stephen Kitt wrote:
> This is where header files and DLLs should go; the compiler and linker
> look there by default (/usr/{i686,x86_64}-w64-mingw32/{include,lib}).
>
> The overrides mention "For now" because the long-term plan is to add the
> MinGW-w64 targets as Debian (partial) architectures
> (https://bugs.debian.org/606825). Then the appropriate directories would
> be /usr/{include,lib}/{i686,x86_64}-w64-mingw32 as per multi-arch...
Thanks for the explanation. I've subscribed to that bug report (though
i confess i don't understand all the details discussed there) and i'm
happy to help make the per-package transitions necessary whenever the
shift to "true multiarch" happens. Feel free to open bug reports
against any of the packages needed to be touched when that happens.
> Option 0 for header files and libraries, option 1 for executables. It
> should be documented but isn't yet...
Ok, works for me. The one possible exception, i think, will be the
${FOO}-config executable POSIX shell scripts, like gpg-error-config.
These will likely need to be carried forward for as long as upstream
objects to pkg-config [0]. I'm inclined to ship them in e.g.,
/usr/i686-w64-mingw32/bin/gpg-error-config, so that rdeps can
./configure --with-libgpg-error-prefix=/usr/i686-w64-mingw32 for now.
Does this make sense?
[0] https://bugs.debian.org/643341
http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html
> Sounds good; I should really write up a Windows policy of some sort.
Please do write one up, even if only a wiki page at the moment. I'd be
happy to read it and give feedback.
> Please use lib...-mingw-w64 and lib...-mingw-w64-dev packages if
> possible; see libz-mingw-w64 for an example (although that particular
> package is rather inefficient since it's a new source package rather
> than extra binary packages produced by zlib1g).
hm, I'm not convinced i want to introduce two new arch-independent
packages in each of these dependencies; it seems excessive when most of
these are just going to be used as build-dependencies. I'm currently
thinking of making them strictly lib...-mingw-w64-dev, and leaving the
.dlls in that package.
Is there a practical reason to split out the .dlls separately from the
.dll.a's for debian systems?
Thanks for pointing out the libz-mingw-w64, also. My attempted builds
have thus far only targeted i686-w64-mingw32. I note that
libz-mingw-w64 additionally targets x86_684-w64-mingw32. I'm inclined
to keep my current work focused just on the i686-w64-mingw32, but if you
have a good argument for why you'd want them both, please let me know.
> I'm thinking that upstream might be interested in this too, since having
> those particular DLLs available as native Debian packages would be
> helpful for building GnuPG Windows binaries in general!
Yep, agreed. The current upstream approach to building GnuPG for
windows is a bit scary. Hopefully this will make it easier for future
versions, and will make it easier for other people to hack on GnuPG for
Windows too.
Regards,
--dkg
shipping libraries in debian for use when cross-building with mingw-w64-i686-dev (for win32-loader)
Hi Stephen and the d-i installer team--
(and hi Andreas, cc'ed here as libgcrypt maintainer in debian)
I'm trying to sort out the cross-building toolchain in debian for making
windows binaries, for the sake of making things that will contribute to
win32-loader.
My main question is: when shipping cross-built libraries (.dll, .dll.a,
.la, and .a files) and header files for use on debian by other
cross-builders targetting win32, where do you think those libraries
should be placed in the filesystem? I see two options:
0) /usr/i686-w64-mingw32
This is where a bunch of dll's and header files already shipped by
mingw-w64-i686-dev live.
/usr/share/lintian/overrides/mingw-w64-i686-dev says in part:
> # For now files are in /usr/${target}
> mingw-w64-i686-dev: file-in-unusual-dir
> mingw-w64-i686-dev: non-standard-dir-in-usr
I'm not sure what the "For now" is about. is there a larger plan?
1) /usr/share/win32
This is currently where the files that target win32-loader live, like
gzip-win32 and cpio-win32. It's possible that this is only desirable
for the final .exe files produced for win32-loader, and that it should
not be used for the "intermediate" products like win32 libraries.
Do you have a preference? Do you see other options? Is any of this
documented somewhere i should read up on?
Background: i'm currently working on updating gpgv-win32 to build it
From the "modern" GnuPG suite (2.1.x) instead of the "classic" suite
(1.4.x). Unlike the classic suite, the modern suite depends on a small
number of libraries that themselves need to be cross-built and available
before gpgv.exe can be linked. I plan to build gpgv.exe statically so
that win32-loader doesn't have to deal with any dll's explicitly, but to
do that i want to make sure that we have the underlying libraries
packaged and available properly.
At the minimum, this will include win32 builds for:
* libgpg-error
* libgcrypt
And it might be simplest for the overall process of producing gpgv.exe
From 2.1.x to produce win32 builds for (even though gpgv itself doesn't
depend on them):
* libassuan
* libksba
I'm preparing all the source changes needed for these -- i'll file bugs
with patches for the ones handled by Andreas, but i want to be sure that
i'm putting things in the right place.
any thoughts?
--dkg
signature.asc
Description: PGP signature
Re: gpgv udebs
On Wed 2015-08-12 01:51:35 +0200, Daniel Kahn Gillmor wrote: > i believe the installer relies on gpgv for archive manifest signature > verification. we have gpgv-udeb for that purpose, i think. One more followup about gnupg and udebs-- The gnupg packaging currently makes a gnupg-udeb in addition to a gpgv-udeb. This post is about gnupg-udeb, and not gpgv-udeb. I'm proposing to drop the gnupg-udeb entirely. It looks like it was used at one point in the past for partman-crypto, but it is no longer used there. I searched here: http://codesearch.debian.net/results/gnupg-udeb/ and the only places it shows up are the changelong for partman-crypto, and a test case for python-debian. the package isn't actually used any more. So i plan to drop the gnupg-udeb in a future release of the gnupg package, unless i hear a report that it's something people need. Anyone want to speak up in favor of keeping it? --dkg
Re: [pkg-gnupg-maint] gpgv udebs
On Wed 2015-08-12 02:38:48 -0400, Werner Koch wrote: > The use of libksba is unfortunate: > > # FIXME: Libkeybox.a links to libksba thus we need to add libksba > # here, even that it is not used by gpg. A proper solution would > # either to split up libkeybox.a or to use a separate keybox daemon. > > libkeybox implements the keybox format, which supports X.509 and > OpenPGP. It is required to insert or search X.509 certificates but gpg > does not do this. Thus we can split it up and build two of the keybox > convenience libraries - one for general use and one for use by gpg and > gpgv. > > Shall I do that for 2.1.8? yes, this sounds like the right solution. thanks for coming up with it so quickly, Werner! I've filed https://bugs.gnupg.org/gnupg/issue2068 upstream to track the proposal. --dkg signature.asc Description: PGP signature
gpgv udebs
hi debian installer folks-- this message is not urgent, just a heads-up to the debian installer folks (and the pkg-gnutls folks, since libksba comes up later) from a gnupg maintainer. (i don't think i'm subscribed to debian-boot, please keep me cc'ed!) i believe the installer relies on gpgv for archive manifest signature verification. we have gpgv-udeb for that purpose, i think. It's likely that at some point (i'm hoping before stretch) we'll want to move most of our GnuPG reliance to the 2.1 branch, since that will allow us to take advantage of stronger, smaller, faster cryptography and will also help to keep our tools aligned with where upstream's main development focus is. As a result, i'd like to consider moving the gpgv udeb over to the gnupg2 package sometime soon. gpgv2 has more dependencies than gpgv, though: gpgv2 Depends: libbz2-1.0, libc6 (>= 2.14), libgcrypt20 (>= 1.6.1), libgpg-error0 (>= 1.14), libksba8 (>= 1.2.0), zlib1g (>= 1:1.1.4) gpgv Depends: libbz2-1.0, libc6 (>= 2.14), zlib1g (>= 1:1.1.4) so we're talking about adding three dependencies as udebs: libgcrypt20, libgpg-error0, libksba8 Of these three dependencies: * gpg-error is simple/small/trivial: i don't think it's particularly objectionable, and there's already a udeb for it. * libgcrypt is the actively-developed crypto library that the we want to rely on instead what's effectively an embedded stripped-down copy in gpgv, so i think this is an actively good dependency to add. libgcrypt also already has a udeb. * libksba8 is the X.509 and CMS support library used by GnuPG. we probably don't strictly need this for the installer (our archive signatures use OpenPGP signatures and not CMS). I can work on a stripped-down build of gpgv2 that doesn't have this dependency if we think that would be useful for minimizing the installer. Alternately, I can work with pkg-gnutls to add a udeb for libksba (we've already discussed the possibility of transferring the libksba from pkg-gnutls to pkg-gnupg) let me know if you have any concerns, preferences, or questions about this work, and if you have specific time windows that it would be good to aim for. Regards, --dkg signature.asc Description: PGP signature
Re: [pkg-gnupg-maint] Bug#753163: Bug#753163: Fix before first point release ?
over on https://bugs.debian.org/753163 ... On Tue 2015-04-28 03:14:45 -0400, Werner Koch wrote: > On Tue, 28 Apr 2015 06:32, raphael.hal...@gmail.com said: >> Will this bug be fixed before the first point release ? [...] > For the dependency problem there is a way out: Since GnuPG 2.1.2: > > * agent: Now tries to use a fallback pinentry if the standard >pinentry is not installed. > > Thus depending on a "pinentry-basic" binary (which may either be -curses > or -dumb) you have a working setup. Any desktop may then install -gtk or > -qt as "pinentry" and you get want you want. We should already be able to support this approach in debian with /etc/alternatives, i think. This should be satisfied with the default /usr/bin/pinentry being pinentry-curses if no other one is installed, and then if -gtk or -qt are installed, /etc/alternatives will be updated to point to the newer one. Fixing https://bugs.debian.org/765406 in tasksel by making the desktop tasks recommend the matching graphical pinentry would resolve this problem. There's even a patch for it: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;filename=tasksel.diff;att=1;bug=765406 If we could get that patch into the next point release for tasksel, i'd be happy to move pinentry-curses to the front of the gpg-agent Recommends pinentry disjunction for the point release as well. This is not an increase in the dependencies for the graphical environments, since they likely already depend on pinentry through the current dependency chain. But it will be a reduction in the dependencies for server users. If we just update the gpg-agent recommends pinentry disjunction, it's likely that some desktop jessie users will be stuck behind pinentry-curses, which would be a bad user experience. Making a coordinated change with both of these updates seems like the right way to go. tasksel folks, are you OK with this? --dkg -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbg3k62y@alice.fifthhorseman.net
Bug#774332: Bug#763391: chfn and fakechroot
Control: forcemerge 774332 745082 763391 Le vendredi 20 février à 19h 02mn 31s (+0100), John Paul Adrian Glaubitz a écrit : >> PS: I would suggest merging 745082, 763391 and 774332. They seem to >> describe the exact same bug. I agree they look similar, and i'm inclined to think that the problem is with debootstrap itself. I'm doing the merge here into the bug that's open against debootstrap. hopefully it won't need to be split out again in the future :P On Fri 2015-02-20 18:24:18 -0500, jhcha54008 wrote: > May I ask if debootstrap ran in a fakechroot environment or as real root ? I'm curious about this too. Adrian, can you give more details? --dkg -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq3c5g91@alice.fifthhorseman.net
Bug#699136: installation-reports: partman hangs on Dell Optiplex 960
On Sun 2013-01-27 14:40:19 -0500, Daniel Kahn Gillmor wrote:
> partman hung at either 50% or 54% during the "Partition hard drives"
> phase of the installer.
>
> switching to a vt, i was able to see that it appeared to be hung
> during 35dump.
>
> killing parted from a vt was successful, but each time i tried to
> re-run partman, it hung on 35dump again.
Correction: this is happening with the wheezy beta4 installer, not a
daily build.
I've just debugged this further. the first hang is on the 30 hook
(50%), not 35; subsequent killing and re-running of partman makes it
hang on 35 (54%).
And, even more interesting: this only happens when a particular USB
stick is installed. And, it's the same USB stick that causes parted to
assert, as documented in http://bugs.debian.org/698609. (that bug report
also includes an image of the mbr for the particular USB stick.
I'm pretty sure that the weirdness in that mbr is what causes partman to
hang, and i've just been able to verify that using kvm and the mbr from
that image, like so:
0 dkg@alice:~/tmp/699136$ wget -q -O sdb.mbr
'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=sdb.mbr;att=1;bug=698609'
0 dkg@alice:~/tmp/699136$ wget -q
http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/netboot/debian-installer/i386/{linux,initrd.gz}
0 dkg@alice:~/tmp/699136$ sha1sum *
60e7842e55a60631291390a98334a95a59426ab7 initrd.gz
46753db4103c8cc0a55e8040aa652bb4e7cea916 linux
6e69b9c81e9f4fe3773d18ff9aac7006ca852962 sdb.mbr
0 dkg@alice:~/tmp/699136$ qemu-img create -f qcow vda.img 4G
Formatting 'vda.img', fmt=qcow size=4294967296 encryption=off
0 dkg@alice:~/tmp/699136$ dd if=sdb.mbr of=usb.img
1+0 records in
1+0 records out
512 bytes (512 B) copied, 2.5861e-05 s, 19.8 MB/s
0 dkg@alice:~/tmp/699136$ dd if=/dev/zero of=usb.img bs=1M count=1 seek=4096
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00085567 s, 1.2 GB/s
0 dkg@alice:~/tmp/699136$ kvm -kernel linux -initrd initrd.gz -usb -usbdevice
disk:format=raw:usb.img -drive file=vda.img,format=qcow,if=virtio
if you step through the installer in this guest, it hangs at the
described point.
--dkg
pgpqkwLtgCGuR.pgp
Description: PGP signature
Bug#699136: installation-reports: partman hangs on Dell Optiplex 960
Package: installation-reports Severity: normal -- Package-specific info: Boot method: network Image version: wheezy non-graphical netboot from 2013-01-13 (i think) Date: Machine: Dell Optiplex 960 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: partman hung at either 50% or 54% during the "Partition hard drives" phase of the installer. switching to a vt, i was able to see that it appeared to be hung during 35dump. killing parted from a vt was successful, but each time i tried to re-run partman, it hung on 35dump again. I ultimately installed manually, thanks to parted-deb and debootstrap :( --dkg -- I'm attaching the output of lshw -- i'm not sure what else would be useful. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127194019.2187.6962.reportbug@thesavage
Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
On 10/22/2012 05:55 PM, Milan Kupcevic wrote: > We can allow d-i grub installation on powerpc machines for wheezy, but > not make it default. [...] > Manual creation of the appropriate partition in d-i (/boot/grub) will > enable grub installation in wheezy d-i. Thus, we will be able to > experiment with d-i grub installation on powerpc machines. ok, this sounds like a good step to me. Are you saying this is present in the current wheezy beta3 ? >> I'm also happy to test powerpc d-i images that use grub-ieee1275 if you >> need testers. > > Do you have access to any IBM Power machines? I have no IBM Power machines, but i have older PowerPC Apple hardware coming out of my ears. Let me know if you want specific tests run. --dkg signature.asc Description: OpenPGP digital signature
Bug#690017: gnome-session craps out when cups not available.
Control: retitle 690017 "Oh no! Something has gone wrong" when /var/run/cups/cups.sock is not accessible at login I wouldn't be surprised if #690017 and #687978 are caused by the same underlying problem. --dkg -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwzwl6p7@pip.fifthhorseman.net
Bug#690017: task-gnome-desktop: first login on minimal "Graphical Desktop Environment" system yields "Oh no! Something has gone wrong."
On 10/08/2012 09:56 PM, Daniel Kahn Gillmor wrote: > > Oh no! Something has gone wrong. > A problem has occured and the system can't recover. > Please log out and try again. > [Log Out] > [...] > I find that if i add the "Print Server" task from tasksel, log out, > and then log back in again, i don't get this mysterious message. i've narrowed this down further. If the cups service isn't running when the user logs in, they get this unhelpful error message and are prevented from doing anything else in their login. This seems like an dangerous bug in gnome -- if the CUPS service is stopped (for whatever reason, including it not being installed, or having crashed, or simply being), then no gnome login is possible. ... a bit more digging around ... i find the same crash even if cups is running, as long as /var/run/cups/cups.sock is not present or just isn't accessible to the user. This is pretty clearly an unacceptable failure mode for a graphical environment used by regular people. If CUPS crashes or refuses to respond, the appropriate thing to do is to disable printing. It is not appropriate to disable the rest of the entire desktop environment. --dkg signature.asc Description: OpenPGP digital signature
Bug#690017: task-gnome-desktop: first login on minimal "Graphical Desktop Environment" system yields "Oh no! Something has gone wrong."
Package: task-gnome-desktop Version: 3.13 Severity: important I just did an install from the nightly debian-installer, in text mode, choosing default options all the way up to the tasksel screen. In the tasksel screen, i chose "Graphical Desktop Environment" and "Standard System Utilities", and nothing else. The desktop environment selection appears to have chosen task-gnome-desktop for me. After the reboot following the installation, i am greeted with gnome's nearly-content-free error message screen, complete with frowny-face computer: Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again. [Log Out] weirdly, this screen seems to be a normal window thrown on top of a functional destkop environment. If i press Alt+Spacebar, i can get the window manager's menu, from which i can select "close", revealing the desktop. Most users won't be able to figure out this workaround, and instead will repeatedly click the "log out" button, only to log in again and be stymied again. I don't know where to find debugging information to sort this out. there are many spurious-looking messages in ~/.xsession-errors. I'm attaching one .xsession-errors from a failed session to this bug report. maybe the ones about gnome-settings-daemon failing to register are the relevant ones? I find that if i add the "Print Server" task from tasksel, log out, and then log back in again, i don't get this mysterious message. Perhaps gnome needs to be more resilient on systems where normal printer daemons aren't installed? or some extra dependency is missing? or both? --dkg -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages task-gnome-desktop depends on: ii gnome-core1:3.4+2 ii task-desktop 3.13 ii tasksel 3.13 Versions of packages task-gnome-desktop recommends: ii gimp2.8.2-1 ii gnome 1:3.4+2 ii hunspell-en-us 20070829-6 ii hyphen-en-us2.8.3-2 ii iceweasel 10.0.7esr-2 ii libreoffice 1:3.5.4+dfsg-2 ii libreoffice-evolution 1:3.5.4+dfsg-2 pn libreoffice-gcj ii libreoffice-gnome 1:3.5.4+dfsg-2 ii libreoffice-help-en-us 1:3.5.4+dfsg-2 ii mythes-en-us1:3.3.0-4 ii synaptic0.75.12 ii system-config-printer 1.3.7-3 task-gnome-desktop suggests no packages. -- no debconf information /etc/gdm3/Xsession: Beginning session setup... localuser:dkg being added to access control list gnome-session-is-accelerated: No hardware 3D support. gnome-session-check-accelerated: Helper exited with code 256 x-session-manager[19325]: WARNING: Session 'gnome' runnable check failed: Exited with code 1 GNOME_KEYRING_CONTROL=/home/dkg/.cache/keyring-JQqfLg SSH_AUTH_SOCK=/home/dkg/.cache/keyring-JQqfLg/ssh GNOME_KEYRING_CONTROL=/home/dkg/.cache/keyring-JQqfLg SSH_AUTH_SOCK=/home/dkg/.cache/keyring-JQqfLg/ssh GPG_AGENT_INFO=/home/dkg/.cache/keyring-JQqfLg/gpg:0:1 GNOME_KEYRING_CONTROL=/home/dkg/.cache/keyring-JQqfLg SSH_AUTH_SOCK=/home/dkg/.cache/keyring-JQqfLg/ssh GPG_AGENT_INFO=/home/dkg/.cache/keyring-JQqfLg/gpg:0:1 GNOME_KEYRING_CONTROL=/home/dkg/.cache/keyring-JQqfLg SSH_AUTH_SOCK=/home/dkg/.cache/keyring-JQqfLg/ssh GPG_AGENT_INFO=/home/dkg/.cache/keyring-JQqfLg/gpg:0:1 x-session-manager[19325]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout (gnome-panel:19589): Gtk-CRITICAL **: gtk_accelerator_parse_with_keycode: assertion `accelerator != NULL' failed ** (gnome-panel:19589): WARNING **: Unable to parse mouse modifier '(null)' Initializing tracker-store... Tracker-Message: Setting up monitor for changes to config file:'/home/dkg/.config/tracker/tracker-store.cfg' Tracker-Message: Setting up monitor for changes to config file:'/home/dkg/.config/tracker/tracker-store.cfg' Starting log: File:'/home/dkg/.local/share/tracker/tracker-store.log' Initializing tracker-miner-fs... Tracker-Message: Setting up monitor for changes to config file:'/home/dkg/.config/tracker/tracker-miner-fs.cfg' Starting log: File:'/home/dkg/.local/share/tracker/tracker-miner-fs.log' ** Message: applet now removed from the notification area (gnome-panel:19589): Gtk-CRITICAL **: gtk_accelerator_parse_with_keycode: assertion `accelerator != NULL' failed ** (gnome-panel:19589): WARNING **: Unable to parse mouse modifier '(null)' ** (gnome-screensaver:19614): WARNING **: Config key not handled: disable-application-handlers ** (gnome-screensaver:19614): WARNING **: Config key not handled: disable-command-line ** (gnome-screensaver:19614): WARNING **: Config key not handled: disable-log-out ** (gnome-screensaver:19614
Bug#664128: followup from phcoder
phcoder gave me the following information on IRC about this transition: 15:13 < phcoder> dkg: install method can be changed to whatever yaboot currently uses for the ease of transition if I get enough info about what it does 15:13 < phcoder> And HFS+ works as well Regards, --dkg -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f62423d.6090...@fifthhorseman.net
Bug#664128: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot
Package: debian-installer Severity: wishlist grub-ieee1275 is a powerful and effective bootloader for powerpc machines. It is significantly more flexible at runtime than yaboot, and provides a user experience more roughly comparable with installs on i386 and amd64 machines. Please have debian-installer on powerpc default to grub-ieee1275 instead of yaboot. Differences in the setup: yaboot expects a ~1MiB bootstrap partition in an apple-formatted disk that is openfirmware-visible. This partition isn't mounted on the running host, but is managed/updated when the admin runs ybin. grub-ieee1275 expects a larger bootstrap partition (~10MiB should be fine) in an apple-formatted disk that is openfirmware-visible. This partition should have a plain HFS (not HFS+) filesystem on it, and should be mounted by the host at /boot/grub. Users of grub-ieee1275 probably therefore also want to have hfsprogs installed on their system for /sbin/fsck.hfs so that routine filesystem checks at boot time can proceed for the filesystem mounted at /boot/grub. - If you need help or advice on pursuing this transition, phcoder has indicated that he would be happy to discuss it on the upstream mailing list: Grub 2 Development List I'm also happy to test powerpc d-i images that use grub-ieee1275 if you need testers. Thanks for your work on d-i! Regards, --dkg pgpOJlg0iywNl.pgp Description: PGP signature
debian #624343 affects debian-installer
affects 624343 debian-installer thanks I note that debian-installer happily creates LVM-over-RAID and dmcrypt-over-RAID setups (and lvm-over-dmcrypt-over-RAID setups, for that matter), and provides no warnings to the admin that these RAiD setups may not be re-syncable in the face of hardware failure without taking their associated filesystems offline (or obeying some other unnamed constraints). I've marked this bug as affecting debian-installer because this seems to potentially surprising to administrators using d-i to set up their systems. Perhaps d-i should prefer alternate block device layerings that do not have these constraints? Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#624481: debian-installer: kfreebsd-i386 unstable d-i cannot fetch partman-zfs
On 04/28/2011 03:31 PM, Miguel Figueiredo wrote: > According the changelog [1] it was reenabled on partman-zfs version 6, > currently available on testing and sid. yes, that's the one i found and downloaded. The bug appears to be that d-i doesn't know about it. --dkg signature.asc Description: OpenPGP digital signature
Bug#624481: debian-installer: kfreebsd-i386 unstable d-i cannot fetch partman-zfs
Package: debian-installer Severity: normal I pulled the kfreebsd-i386 installer from here: http://d-i.debian.org/daily-images/kfreebsd-i386/daily/netboot/debian-installer/kfreebsd-i386/ and i launched it in expert mode. I looked for the partman-zfs udeb in the list of "download installer components" but i couldn't find it. I also tried (from the terminal): anna-install partman-zfs but that failed with the usual warning about package not found (sorry, i don't have the exact error message handy). however, i was able to fetch the package from the web with wget, unpack it with ar, and install it with tar, which ultimately enabled zfs support in partman. I'm not sure why it wasn't listed as available. --dkg -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110428185050.4910.18785.reportbug@localhost.localdomain
Bug#610206: partman-auto: please make larger newworld bootblock by default (maybe 5MiB?)
Package: partman-auto Severity: wishlist I recently did an install of the squeeze beta2 d-i on powerpc. partman-auto set up a New World Bootloader partition with something around 800KiB of space. While this is fine for yaboot, grub-ieee1275 seems to prefer a larger partition. If i'm understanding grub-ieee1275 correctly, i think it wants the newworld bootloader partition to be mounted explicitly at /boot/grub, and it seems to want to keep around 2MiB of data in there. I figure a 5MiB newworld bootblock partition wouldn't be unreasonable -- i have never seens a powerpc machine that would fail with such a setup, and 5MiB would easily fit both the yaboot files and the grub files, in case someone wanted to try to transition their machine's bootloader. I'm not advocating d-i switching from yaboot to grub for powerpc right now, but it would be nice to leave the user with space to make such a transition when they're ready. --dkg -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.32-5-powerpc 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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110116060518.1304.60523.report...@clam.lair.fifthhorseman.net
Bug#591016: flash-kernel: /usr/share/initramfs-tools/hooks/flash_kernel_set_root mis-detects root filesystems for systems using ubifs
On 07/31/2010 12:54 AM, Martin Michlmayr wrote: > * Daniel Kahn Gillmor [2010-07-30 19:32]: >> There are recent changes in initramfs-tools to accommodate root >> filesystems on ubifs. flash-kernel should inherit these changes if >> possible, especially since ubifs is likely to be correlated with the >> presence of the flash-kernel package. > > Maybe. In the meantime, you can simply dpkg --purge flash-kernel > if your kernel is on ubifs. I could, but flash-kernel is useful for knowing the correct incantation of uboot-mkimage's mkimage for my architecture. Otherwise, i'd have to track the generation of /boot/uImage myself, which seems like a poor tradeoff. i also note that there is no command in flash-kernel for the guruplug to actually write the kernel to NAND storage -- it generates uImage and uInitrd, but does not store them to /dev/mtd1 as i'd expect something like: nandwrite /dev/mtd1 /boot/uImage But i understand not everyone would necessarily arrange the NAND on the GuruPlug in the same way. Perhaps we could verify that: fw_printenv x_bootcmd_kernel emits: x_bootcmd_kernel=nand read.e 0x640 0x10 0x40 since in that case, the nandwrite command is more likely to be correct. --dkg signature.asc Description: OpenPGP digital signature
Bug#591016: flash-kernel: /usr/share/initramfs-tools/hooks/flash_kernel_set_root mis-detects root filesystems for systems using ubifs
Package: flash-kernel Version: 2.32 Severity: normal When using an armel system with the root filesystem on ubifs, update-initramfs spews this error message: Warning: /etc/fstab parse error; guessing that the root device is /dev/sda2 it appears to be due to /usr/share/initramfs-tools/hooks/flash_kernel_set_root (i'm doing this on a guruplug, but filing the report from my laptop). There are recent changes in initramfs-tools to accommodate root filesystems on ubifs. flash-kernel should inherit these changes if possible, especially since ubifs is likely to be correlated with the presence of the flash-kernel package. --dkg -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (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/bash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100730233240.13350.17733.report...@localhost.localdomain
Bug#532852: console-setup during initrd would also affect crypted-root systems
it seems like #532852 (Please run console-setup during initrd phase) would also affect systems with a crypted root. that is, entering the passphrase to unlock the block device backing the root filesystem could be done with the machine's "preferred" keymap, instead of with whatever default appears. --dkg signature.asc Description: OpenPGP digital signature
Bug#496727: partman fails with LVM over dm-crypt over RAID with the lenny beta2 d-i
On Thu 2008-08-28 11:40:51 -0400, Jérémy Bobbio wrote: > On Tue, Aug 26, 2008 at 09:45:33PM -0400, Daniel Kahn Gillmor wrote: >> Image version: lenny d-i beta2 >> FWIW, this arrangment (LVM over dm-crypt over RAID) seems like a >> reasonable common one, so it should be easy to configure from d-i. > > See the wiki page about the issue [1]. > > [1] http://wiki.debian.org/DebianInstaller/RAIDvsCrypto Thanks for the followup! This link seems to report a different problem, though. The link refers to a problem with population of /target/etc/crypttab during crypto-over-RAID. The problem i reported has to do with misbehavior during the partman. It tried to create a partition table on the crypted volume (over RAID), rather than letting me use it directly as an LVM PV. I'll see what i can do with a daily build over the next few days to try to confirm or deny the problem. Regards, --dkg pgpGwowSQnU8b.pgp Description: PGP signature
Bug#496727: partman fails with LVM over dm-crypt over RAID with the lenny beta2 d-i
Package: installation-reports Boot method: netboot Image version: lenny d-i beta2 Date: Tue, 26 Aug 2008 21:22:47 -0400 Machine: monkeyman Processor: Intel(R) Xeon(TM) CPU 3.20GHz Memory: 1G Partitions: 0 shoveler:/# df -Tl FilesystemType 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_shoveler0-root ext3 1032088 75104904556 8% / /dev/md0 ext3 474348 16593433263 4% /boot /dev/mapper/vg_shoveler0-usr ext3 5160576334816 4563616 7% /usr /dev/mapper/vg_shoveler0-var ext3 5160576292336 4606096 6% /var tmpfstmpfs 45320440453164 1% /dev 0 shoveler:/# cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 1 489951 sda1 8 2 979965 sda2 8 3 486914085 sda3 816 488386584 sdb 817 489951 sdb1 818 979965 sdb2 819 486914085 sdb3 9 0 489856 md0 9 1 486913984 md1 254 0 486912956 dm-0 254 1 979965 dm-1 254 2 979965 dm-2 254 31048576 dm-3 254 45242880 dm-4 254 55242880 dm-5 0 shoveler:/# cat /etc/crypttab sda2_crypt /dev/sda2 /dev/urandom cipher=serpent-xts-plain,size=256,swap sdb2_crypt /dev/sdb2 /dev/urandom cipher=serpent-xts-plain,size=256,swap 0 shoveler:/# cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] md1 : active raid1 sdb3[1] sda3[0] 486913984 blocks [2/2] [UU] [==>..] resync = 52.4% (255497664/486913984) finish=44.5min speed=86491K/sec md0 : active raid1 sdb1[1] sda1[0] 489856 blocks [2/2] [UU] unused devices: 0 shoveler:/# lvs File descriptor 3 left open File descriptor 4 left open File descriptor 5 left open File descriptor 6 left open LV VG Attr LSize Origin Snap% Move Log Copy% Convert root vg_shoveler0 -wi-ao 1.00G usr vg_shoveler0 -wi-ao 5.00G var vg_shoveler0 -wi-ao 5.00G 0 shoveler:/# pvs File descriptor 3 left open File descriptor 4 left open File descriptor 5 left open File descriptor 6 left open PV VG Fmt Attr PSize PFree /dev/dm-0 vg_shoveler0 lvm2 a- 464.36G 453.36G 0 shoveler:/# cat /proc/swaps FilenameTypeSizeUsedPriority /dev/mapper/sda2_crypt partition 979956 0 -1 /dev/mapper/sdb2_crypt partition 979956 0 -2 0 shoveler:/# Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The partitioner seems to have a problem when placing LVM PVs on top of encrypted volumes on top of RAID devices. I saw no mention of this in the errata (http://www.debian.org/devel/debian-installer/errata), but i haven't tested it against a daily build yet either. In this example, there is a 2-component RAID1 mirror /dev/md1 from /dev/sda3 and /dev/sdb3. /dev/mapper/md1_crypt is created by layering an encrypted volume over /dev/md1, and configured via partman. At this point, i was returned to the main partman screen, but if i select the md1_crypt device to try to make it an LVM2 physical volume, partman instead offers to put a partition table on the device, which doesn't make any sense. Perhaps dm-crypt over RAID devices are somehow not being flagged as "loop" or something? Partman seems to work as i expect it to if it's just dm-crypt over a raw device. I was able to work around this by getting as far as the above, opening a shell in a separate session, doing pvcreate, vgcreate, and lvcreate From the separate shell, and then restarting partman via "Go Back" and "Partition Disks". At that point, partman recognized the LVM pieces and let me work with them as i intended. FWIW, this arrangment (LVM over dm-crypt over RAID) seems like a reasonable common one, so it should be easy to configure from d-i. Thanks for making a very useful installer! Regards, --dkg PS Reports that seem related: http://bugs.debian.org/435834 http://bugs.debian.org/303914 (supposed to be fixed years ago!) pgpJmmu8Drapb.pgp Description: PGP signature
Bug#466771: busybox cpio: double free or corruption during cpio extraction of hardlinks
Package: busybox Version: 1:1.1.3-5 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 busybox cpio seems to corrupt its memory (maybe with a double free?) when extracting a hardlink. Here's a transcript of a simple case to trigger the failure: 0 [EMAIL PROTECTED]:/tmp$ mkdir tt 0 [EMAIL PROTECTED]:/tmp$ touch tt/x 0 [EMAIL PROTECTED]:/tmp$ ln tt/x tt/y 0 [EMAIL PROTECTED]:/tmp$ mkdir xx 0 [EMAIL PROTECTED]:/tmp$ find tt | cpio -H newc --create | (cd xx && busybox cpio -i) 1 block 1 blocks cpio: TRAILER!!! not created: cannot resolve hardlink cpio: (null) not created: cannot resolve hardlink *** glibc detected *** busybox: double free or corruption (fasttop): 0x08178048 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7dd8915] /lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7ddc380] busybox[0x805378b] === Memory map: 08048000-080ac000 r-xp fd:0a 65545 /bin/busybox 080ac000-080ae000 rwxp 00064000 fd:0a 65545 /bin/busybox 080ae000-08199000 rwxp 080ae000 00:00 0 [heap] b7c0-b7c21000 rwxp b7c0 00:00 0 b7c21000-b7d0 ---p b7c21000 00:00 0 b7d6c000-b7d6d000 rwxp b7d6c000 00:00 0 b7d6d000-b7eb4000 r-xp fd:0a 114782 /lib/i686/cmov/libc-2.7.so b7eb4000-b7eb5000 r-xp 00147000 fd:0a 114782 /lib/i686/cmov/libc-2.7.so b7eb5000-b7eb7000 rwxp 00148000 fd:0a 114782 /lib/i686/cmov/libc-2.7.so b7eb7000-b7eba000 rwxp b7eb7000 00:00 0 b7eba000-b7edd000 r-xp fd:0a 114787 /lib/i686/cmov/libm-2.7.so b7edd000-b7edf000 rwxp 00023000 fd:0a 114787 /lib/i686/cmov/libm-2.7.so b7edf000-b7ee8000 r-xp fd:0a 114784 /lib/i686/cmov/libcrypt-2.7.so b7ee8000-b7eea000 rwxp 8000 fd:0a 114784 /lib/i686/cmov/libcrypt-2.7.so b7eea000-b7f12000 rwxp b7eea000 00:00 0 b7f1a000-b7f26000 r-xp fd:0a 114764 /lib/libgcc_s.so.1 b7f26000-b7f27000 rwxp b000 fd:0a 114764 /lib/libgcc_s.so.1 b7f27000-b7f29000 rwxp b7f27000 00:00 0 b7f29000-b7f45000 r-xp fd:0a 114725 /lib/ld-2.7.so b7f45000-b7f47000 rwxp 0001b000 fd:0a 114725 /lib/ld-2.7.so bffb3000-bffc8000 rw-p bffeb000 00:00 0 [stack] e000-f000 r-xp 00:00 0 [vdso] 134 [EMAIL PROTECTED]:/tmp$ The standard cpio doesn't seem to have this problem: 0 [EMAIL PROTECTED]:/tmp$ rm -rf xx 0 [EMAIL PROTECTED]:/tmp$ mkdir xx 0 [EMAIL PROTECTED]:/tmp$ find tt | cpio -H newc --create | (cd xx && cpio -i) 1 block 1 block 0 [EMAIL PROTECTED]:/tmp$ ls -lR xx xx: total 0 drwxr-xr-x 2 wt215 wt215 80 2008-02-20 15:26 tt xx/tt: total 0 - -rw-r--r-- 2 wt215 wt215 0 2008-02-20 15:26 x - -rw-r--r-- 2 wt215 wt215 0 2008-02-20 15:26 y 0 [EMAIL PROTECTED]:/tmp$ This seems to happen with -t (list) the same as -i (extract), so i expect it's a problem with parsing, not file creation. fwiw, it doesn't seem to be a problem with busybox 1.9.1, as built with waldi's debian packaging at: svn://svn.debian.org/d-i/people/waldi/packages/busybox/debian With version 1.9.1, it still doesn't unpack the hardlinks, but it doesn't double-free, at least: 0 [EMAIL PROTECTED]:/tmp$ find tt | cpio -H newc --create | (cd xx && ~/src/busybox/busybox-1.9.1/debian/busybox/bin/busybox cpio -i) 1 block 1 blocks cpio: tt/x not created: cannot resolve hardlink cpio: tt/y not created: cannot resolve hardlink 0 [EMAIL PROTECTED]:/tmp$ find xx xx xx/tt 0 [EMAIL PROTECTED]:/tmp$ Thanks for maintaining busybox in debian! --dkg - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (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/bash Versions of packages busybox depends on: ii libc6 2.7-6 GNU C Library: Shared libraries busybox recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBR7yP7szS7ZTSFznpAQKKqw/+MzMP1qA+Ips+xfvshkybvzi436MaDdCM byP3jbAK0JHvH4Yp4d80ZZD09S21LhlEIfMvPfrZmjmnrWw89QiTB61mNuJHq8xB JmaHZku/5uXsM5xhk8aTv9xLWrC0R/6iUu3r+9sUwWKwcg3SwCeFeLitV08TYlgM pO7Fr1uVpBd13A5JZiLvgoSEC6BIjR1ct3yzDbi7B1oOMwPQBF+BkSxUmOsEsQU1 C4VhS+kvQ6YLFqc07PlXbaGH78waWbo2z3Oacsn7gEVbbNKjTIorwcvlAu9fYPHy MbufuWlVQyddJIwHj9b3Qtq28xHDDyZYn5pnSJ2xjl7Q4OZcbUCSUWnRjUp2SJGH ZQJZpEBE7utYBDWYFsAuq8vGVziOk47/TZSgWqWvCxHt/ZqBrkGsAlrItL9Ies+C VmQGU7yqbouRHovrc2vwDsB1j8MjUt2DfrHNt+7ElSBcGwKnhdkeK7gEfLFRuLUp jvOAzFISdGurDEgkNkmZRKinS+/98xy4RvxKXkp4JpVXiF+SNMAwzsgivuYdYQ+g /UKSLVHEgly4KogPYXwEAT7/GD6jkgZgmVnJycAdhXSMGyGWUF6AkAFfuqPHk8u3 d5tB72G8jhkVu9IPx/g2fhczu1BNKXllOQBpzGnYkMbUPSKj8xgvn761zZeYKaZM 9bihbCO4/mQ= =vs9z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#233864: man-db error on debian-installer beta3
On April 14, [EMAIL PROTECTED] said:
> Any chance you can get to this point again, then, from the console on
> Alt-F2, run 'nano /target/var/lib/dpkg/info/man-db.postinst', put the
> command 'set -x' on the second line, run 'chroot /target dpkg
> --configure man-db', and send the output to this bug report?
sure. There was a ton of spew, though.
this is from a different machine of the same vintage ("mau"),
which also seems to have a defunct motherboard battery.
since the hwclock epoch date on these systems seems to be 1904-01-01,
the logs are also reporting "implausibly old timestamp" all over the
place.
i've tried to capture the output of the requested command to a file,
which i've attached below. i grabbed that output with the command:
chroot /target dpkg --configure man-db 2> /save/man-db.err
(/save was a separate partition which i mounted to be able to grab
output without having it be rewritten when i reinstalled later)
there was also a debconf step where it asked me if i wanted man-db to
run setuid, which i answered no.
Then i used date and hwclock to reset the system clock time, restarted
the installation process, and everything proceeded as normal (despite
the autopartitioner's problem setting up yaboot's 800K Apple_Bootstrap
partition, but that's another bug)
+ '[' configure = configure ']'
+ oldcatdir=/var/catman
+ catdir=/var/cache/man
+ maybesetuid=man mandb
+ conffile=/etc/manpath.config
+ . /usr/share/debconf/confmodule
++ '[' '!' '' ']'
++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/man-db.postinst configure ''
+ '[' configure = configure ']'
+ oldcatdir=/var/catman
+ catdir=/var/cache/man
+ maybesetuid=man mandb
+ conffile=/etc/manpath.config
+ . /usr/share/debconf/confmodule
++ '[' '!' 1 ']'
++ '[' -z '' ']'
++ exec
++ DEBCONF_REDIR=1
++ export DEBCONF_REDIR
++ _old_opts=configure
++ set -- capb CAPB
++ eval 'db_capb () {
echo "CAPB $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- set SET
++ eval 'db_set () {
echo "SET $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- reset RESET
++ eval 'db_reset () {
echo "RESET $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- title TITLE
++ eval 'db_title () {
echo "TITLE $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- input INPUT
++ eval 'db_input () {
echo "INPUT $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- beginblock BEGINBLOCK
++ eval 'db_beginblock () {
echo "BEGINBLOCK $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
# preserving all other whitespace.
RET="${_LINE#[! ][ ]}"
return ${_LINE%%[ ]*}
}'
++ set -- endblock ENDBLOCK
++ eval 'db_endblock () {
echo "ENDBLOCK $@" >&3
# Set to newline to get whole line.
local IFS='\''
'\''
local _LINE
read -r _LINE
# Disgusting, but it'\''s the only good way to split the line,
Bug#233864: man-db error on debian-installer beta3
i just experienced the same error with man-db using debian-installer beta3 for powerpc. i'm running this on a blue iMac G3 (named "kodkod"), and i get the same error Laurent described during installation of the base system: dpkg:error processing man-db (--configure): subprocess post-installation script returned error exit status 1 i found that this was related to the system clock on the motherboard being set to something absurd like 1904 (i think the motherboard battery is dead on kodkod). when i forced the motherboard's clock to show something close to the correct time, and then restarted the installation process (without removing power from the machine), the installation continues on. here's how i reset the system clock after man-db failed: Alt-2 to activate another console, then: # export LD_LIBRARY_PATH=/target/lib # /target/bin/date -s '14 April 2004' # /target/sbin/hwclock --systohc hth, --dkg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
