Re: Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Fri, Mar 18, 2022 at 10:22:57PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-18 14:51:32 [+], Adam D. Barratt wrote: > > Boo. Hope you're doing better. > > Thanks, yes. > > > > I would also do the upload for Buster, would that work? I remember > > > that > > > the packages, that broken, were already uploaded a few cycles ago. > > > > Also as 1.1.1n? > > Yes. > > > I assume there haven't been any regressions reported with l/m/n in the > > meantime. I'm not aware of any regressions the past year. Kurt
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > There are a whole bunch of other issues and pull requests related to > this. I hope this is the end of the regressions in the X509 code. So there is something else now: https://github.com/openssl/openssl/issues/13931 https://github.com/openssl/openssl/pull/13982 Kurt
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote: > On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote: > > > Do you have pointers to upstream issues? > > > > There are a whole bunch of other issues and pull requests related to > > this. I hope this is the end of the regressions in the X509 code. > > Okay. Please ping once this gets sorted out and I will prepease > unstalbe/stable uploads. The m2crypto issue got resolved in unstable > \o/. So I went over the open issues and pull requests, and currently don't see a reason not to upload it to unstable with those 2 patches. I don't know about any other regressions in 1.1.1. Kurt
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote: > Hi, > > On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote: > > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior > > wrote: > [...] > > > The i release in unstable managed to migrate to testing. It was > > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue > > > got fixed in unstable (the testuite was updated) and is not an > > > issue in stable (the package builds, the testsuite gets ignored). > > > The m2crypto issue is a different story and is still open in BTS > > > (#977655). I *think* someone added an override or the ci-system was > > > kind to Kurt/me and looked the other way :) > > > The m2crypto package in stable and bpo will FTBFS with the updated > > > openssl package. > > > > > > I'm not aware of other issues. > > > > I think there are at least 2 upstream issues since the 1.1.1i > > release we want to fix first. As far as I know, they haven't been > > fixed upstream yet. > > Just to confirm, these are issues that you'd want to have fixed before > adding 1.1.1i to stable, presumably requiring further uploads to > unstable first? Yes. > Do you have pointers to upstream issues? They both got merged today: commit 76ed0c0ad119569f6e6f6c96b27b76d3b110413b (origin/OpenSSL_1_1_1-stable) Author: Dr. David von Oheimb Date: Mon Dec 28 11:25:59 2020 +0100 x509_vfy.c: Fix a regression in find_isser() ...in case the candidate issuer cert is identical to the target cert. Fixes #13739 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13749) commit fb1e2411042f0367c2560e4ec5e4b1189ca9cd45 Author: Dr. David von Oheimb Date: Wed Dec 30 09:57:49 2020 +0100 X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due to invalid cert This is the backport of #13755 to v1.1.1. Fixes #13698 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13756) There are a whole bunch of other issues and pull requests related to this. I hope this is the end of the regressions in the X509 code. Kurt
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote: > On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote: > > > At some point, could we please have a combined / single diff between > > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I > > assume)? > > Please find attached the diff between 1.1.1d-0+deb10u4 and the proposed > 1.1.1i-0+deb10u1. > > The i release in unstable managed to migrate to testing. It was blocked > due to ci by m2crypto and swi-prolog. The swi-prolog issue got fixed in > unstable (the testuite was updated) and is not an issue in stable (the > package builds, the testsuite gets ignored). > The m2crypto issue is a different story and is still open in BTS > (#977655). I *think* someone added an override or the ci-system was kind > to Kurt/me and looked the other way :) > The m2crypto package in stable and bpo will FTBFS with the updated > openssl package. > > I'm not aware of other issues. I think there are at least 2 upstream issues since the 1.1.1i release we want to fix first. As far as I know, they haven't been fixed upstream yet. Kurt
Bug#927437: unblock: openssl/1.1.1b-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
Can you please unblock openssl. It fixes 2 important bugs.
debdiff attached.
Kurt
diff -Nru openssl-1.1.1b/debian/changelog openssl-1.1.1b/debian/changelog
--- openssl-1.1.1b/debian/changelog 2019-02-26 19:52:12.0 +0100
+++ openssl-1.1.1b/debian/changelog 2019-04-16 21:31:11.0 +0200
@@ -1,3 +1,11 @@
+openssl (1.1.1b-2) unstable; urgency=medium
+
+ * Fix BUF_MEM regression (Closes: #923516)
+ * Fix error when config can't be opened (Closes: #926315)
+ * Ship an openssl.cnf in libssl1.1-udeb.dirs
+
+ -- Kurt Roeckx Tue, 16 Apr 2019 21:31:11 +0200
+
openssl (1.1.1b-1) unstable; urgency=medium
[ Sebastian Andrzej Siewior ]
diff -Nru openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs
openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs
--- openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs2019-02-26
19:25:16.0 +0100
+++ openssl-1.1.1b/debian/libcrypto1.1-udeb.dirs2019-04-16
21:31:11.0 +0200
@@ -1 +1,2 @@
usr/lib
+usr/lib/ssl
diff -Nru
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
---
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
1970-01-01 01:00:00.0 +0100
+++
openssl-1.1.1b/debian/patches/0001-Fix-for-BIO_get_mem_ptr-and-related-regressions.patch
2019-04-16 21:23:57.0 +0200
@@ -0,0 +1,118 @@
+From 43bb4dec99f4bed1ec20836c79967ea790594fce Mon Sep 17 00:00:00 2001
+From: Tomas Mraz
+Date: Wed, 3 Apr 2019 12:31:32 +0200
+Subject: [PATCH 1/5] Fix for BIO_get_mem_ptr and related regressions
+
+Reviewed-by: Bernd Edlinger
+Reviewed-by: Matt Caswell
+(Merged from https://github.com/openssl/openssl/pull/8649)
+
+(cherry picked from commit b238fb79709a180ba9b4d837101c9f75e2978dc0)
+---
+ crypto/bio/bss_mem.c | 40
+ 1 file changed, 28 insertions(+), 12 deletions(-)
+
+diff --git a/crypto/bio/bss_mem.c b/crypto/bio/bss_mem.c
+index 10fcbf7a7c..abf0f04111 100644
+--- a/crypto/bio/bss_mem.c
b/crypto/bio/bss_mem.c
+@@ -57,7 +57,12 @@ static const BIO_METHOD secmem_method = {
+ NULL, /* mem_callback_ctrl */
+ };
+
+-/* BIO memory stores buffer and read pointer */
++/*
++ * BIO memory stores buffer and read pointer
++ * however the roles are different for read only BIOs.
++ * In that case the readp just stores the original state
++ * to be used for reset.
++ */
+ typedef struct bio_buf_mem_st {
+ struct buf_mem_st *buf; /* allocated buffer */
+ struct buf_mem_st *readp; /* read pointer */
+@@ -192,6 +197,8 @@ static int mem_read(BIO *b, char *out, int outl)
+ BIO_BUF_MEM *bbm = (BIO_BUF_MEM *)b->ptr;
+ BUF_MEM *bm = bbm->readp;
+
++if (b->flags & BIO_FLAGS_MEM_RDONLY)
++bm = bbm->buf;
+ BIO_clear_retry_flags(b);
+ ret = (outl >= 0 && (size_t)outl > bm->length) ? (int)bm->length : outl;
+ if ((out != NULL) && (ret > 0)) {
+@@ -241,29 +248,36 @@ static long mem_ctrl(BIO *b, int cmd, long num, void
*ptr)
+ BIO_BUF_MEM *bbm = (BIO_BUF_MEM *)b->ptr;
+ BUF_MEM *bm;
+
++if (b->flags & BIO_FLAGS_MEM_RDONLY)
++bm = bbm->buf;
++else
++bm = bbm->readp;
++
+ switch (cmd) {
+ case BIO_CTRL_RESET:
+ bm = bbm->buf;
+ if (bm->data != NULL) {
+-/* For read only case reset to the start again */
+-if ((b->flags & BIO_FLAGS_MEM_RDONLY) || (b->flags &
BIO_FLAGS_NONCLEAR_RST)) {
+-bm->length = bm->max;
++if (!(b->flags & BIO_FLAGS_MEM_RDONLY)) {
++if (b->flags & BIO_FLAGS_NONCLEAR_RST) {
++bm->length = bm->max;
++} else {
++memset(bm->data, 0, bm->max);
++bm->length = 0;
++}
++*bbm->readp = *bbm->buf;
+ } else {
+-memset(bm->data, 0, bm->max);
+-bm->length = 0;
++/* For read only case just reset to the start again */
++*bbm->buf = *bbm->readp;
+ }
+-*bbm->readp = *bbm->buf;
+ }
+ break;
+ case BIO_CTRL_EOF:
+-bm = bbm->readp;
+ ret = (long)(bm->length == 0);
+ break;
+ case BIO_C_SET_BUF_MEM_EOF_RETURN:
+ b->num = (int)num;
+ break;
+ case BIO_CTRL_INFO:
+-bm = bbm->readp;
+ ret = (long)bm->length;
+ if (ptr != NULL) {
+ pptr = (char **)ptr;
+@@ -278,8 +292,9 @@ static long mem_ctrl(BIO *b, int cmd, long num, void *ptr)
+ break;
+ case BIO_C_GET_BUF_MEM_PTR:
+ if (ptr
Re: [Pkg-openssl-devel] Bug#926315: Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i
On Thu, Apr 04, 2019 at 12:48:22AM +0200, Cyril Brulebois wrote: > Hi, > > And thanks for digging… > > Kurt Roeckx (2019-04-04): > > On Thu, Apr 04, 2019 at 12:07:37AM +0200, Kurt Roeckx wrote: > > > On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote: > > > > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote: > > > > > 1726 write(2, "Disabling SSL due to encountered errors.\n", 41) > > > > > = 41 > > > > > > > > wget in buster actually seems to be linked to gnutls, and trying > > > > other applications just seem to work without config file. > > > > > > So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in > > > the current OpenSSL_1_1_1-stable branch ... > > > > So the commit that fixes it is: > > commit 9933d4a06bd0a0b5b757f072944e8cd54d4bddd3 > > Author: Richard Levitte > > Date: Wed Mar 20 10:18:13 2019 +0100 > > > > OPENSSL_config(): restore error agnosticism > > > > Great effort has been made to make initialization more configurable. > > However, the behavior of OPENSSL_config() was lost in the process, > > having it suddenly generate errors it didn't previously, which is not > > how it's documented to behave. > > > > A simple setting of default flags fixes this problem. > > > > Fixes #8528 > > > > Reviewed-by: Matt Caswell > > (Merged from https://github.com/openssl/openssl/pull/8533) > > > > (cherry picked from commit 905c9a72a708701597891527b422c7f374125c52) > > > > The one that broke it was the one I pointed out earlier. > > Would it be helpful if I were to rebuild openssl with that patch and double > check what happens with its updated udebs? I don't think that will be needed. I hope to get an other important bugfix soon, and we can do an upload then. Kurt
Re: [Pkg-openssl-devel] Bug#926315: Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i
On Thu, Apr 04, 2019 at 12:07:37AM +0200, Kurt Roeckx wrote: > On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote: > > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote: > > > 1726 write(2, "Disabling SSL due to encountered errors.\n", 41) = 41 > > > > wget in buster actually seems to be linked to gnutls, and trying > > other applications just seem to work without config file. > > So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in > the current OpenSSL_1_1_1-stable branch ... So the commit that fixes it is: commit 9933d4a06bd0a0b5b757f072944e8cd54d4bddd3 Author: Richard Levitte Date: Wed Mar 20 10:18:13 2019 +0100 OPENSSL_config(): restore error agnosticism Great effort has been made to make initialization more configurable. However, the behavior of OPENSSL_config() was lost in the process, having it suddenly generate errors it didn't previously, which is not how it's documented to behave. A simple setting of default flags fixes this problem. Fixes #8528 Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/8533) (cherry picked from commit 905c9a72a708701597891527b422c7f374125c52) The one that broke it was the one I pointed out earlier. Kurt
Re: [Pkg-openssl-devel] Bug#926315: Bug#926315: openssl: wget https://google.com fails in d-i
On Wed, Apr 03, 2019 at 11:57:12PM +0200, Kurt Roeckx wrote: > On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote: > > 1726 write(2, "Disabling SSL due to encountered errors.\n", 41) = 41 > > wget in buster actually seems to be linked to gnutls, and trying > other applications just seem to work without config file. So I can reproduce this with the tag OpenSSL_1_1_1b, it's fixed in the current OpenSSL_1_1_1-stable branch ... Kurt
Re: [Pkg-openssl-devel] Bug#926315: openssl: wget https://google.com fails in d-i
On Wed, Apr 03, 2019 at 11:23:19PM +0200, Cyril Brulebois wrote: > 1726 write(2, "Disabling SSL due to encountered errors.\n", 41) = 41 Looking at the source, about the only reason I can see to get that is that SSL_CTX_new() failed. If I understand correctly, it's actually a change in libcrypto between 1.1.1a and 1.1.1b? The most likely commit to change behaviour seems to be: commit 25eb9299cec4404a4cdf3167056bd147af2582f3 Author: Viktor Dukhovni Date: Tue Jan 1 02:53:24 2019 -0500 More configurable crypto and ssl library initialization 1. In addition to overriding the default application name, one can now also override the configuration file name and flags passed to CONF_modules_load_file(). 2. By default we still keep going when configuration file processing fails. But, applications that want to be strict about initialization errors can now make explicit flag choices via non-null OPENSSL_INIT_SETTINGS that omit the CONF_MFLAGS_IGNORE_RETURN_CODES flag (which had so far been both undocumented and unused). 3. In OPENSSL_init_ssl() do not request OPENSSL_INIT_LOAD_CONFIG if the options already include OPENSSL_INIT_NO_LOAD_CONFIG. 4. Don't set up atexit() handlers when called with opts equal to OPENSSL_INIT_BASE_ONLY (this flag should only be used alone). Reviewed-by: Bernd Edlinger Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/7969) But the commit message at least indicates that it should just continue. wget in buster actually seems to be linked to gnutls, and trying other applications just seem to work without config file. Kurt
Re: HTTPS metadata in Mirrors.masterlist?
On Thu, Apr 06, 2017 at 11:20:36PM +0200, Axel Beckert wrote: > * https://mirror.as35701.net/debian/ (not yet accessible as > https://ftp.be.debian.org/debian/ due to certificate only being > valid for mirror.as35701.net) It's easy enough to also add ftp.be.debian.org to the certificate, but I didn't do it because I don't feel like I have permission to do so. Kurt
Re: Bug#855432: unblock: openssl/1.1.0e-1
On Sun, Feb 19, 2017 at 07:33:20AM +0100, Cyril Brulebois wrote: > Kurt Roeckx <k...@roeckx.be> (2017-02-18): > > On Sat, Feb 18, 2017 at 06:16:28PM +0100, Cyril Brulebois wrote: > > > How soon do you want to see this package in testing? Given I've just > > > fixed a few things related to https support in d-i, it would be nice if > > > I were able to perform a full test with https here, making sure we don't > > > hit a regression there. If a reply this sunday is sufficient, I can do > > > that. > > We have this right now: > > wget-udeb | 1.18-4| testing → built against 1.0.2 > wget-udeb | 1.19.1-1 | unstable → built against 1.1 > > If we're not getting a newer wget for stretch (at least I didn't find > anything wget-related relevant for stretch in my debian-release folder), > I can't think of another libssl user for d-i, which seems confirmed by > looking at libssl*-udeb rdepends in sid. > > Unless I'm missing something obvious: no objections. Can someone please also change the age to 2 days? Kurt
Bug#855432: unblock: openssl/1.1.0e-1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Hi,
There was a new upstream release fixing a high severity security
issue.
The changelog entry is:
openssl (1.1.0e-1) unstable; urgency=high
* New upstream version
- Fixes CVE-2017-3733
- Remove patches that are applied upstream.
-- Kurt Roeckx <k...@roeckx.be> Thu, 16 Feb 2017 18:57:58 +0100
I've attached the full debdiff between the version in testing and
unstable.
Kurt
diff -Nru openssl-1.1.0d/apps/openssl.c openssl-1.1.0e/apps/openssl.c
--- openssl-1.1.0d/apps/openssl.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/openssl.c 2017-02-16 12:58:20.0 +0100
@@ -58,7 +58,6 @@
static void list_disabled(void);
char *default_config_file = NULL;
-static CONF *config = NULL;
BIO *bio_in = NULL;
BIO *bio_out = NULL;
BIO *bio_err = NULL;
@@ -248,8 +247,6 @@
end:
OPENSSL_free(copied_argv);
OPENSSL_free(default_config_file);
-NCONF_free(config);
-config = NULL;
lh_FUNCTION_free(prog);
OPENSSL_free(arg.argv);
diff -Nru openssl-1.1.0d/apps/req.c openssl-1.1.0e/apps/req.c
--- openssl-1.1.0d/apps/req.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/req.c 2017-02-16 12:58:20.0 +0100
@@ -121,7 +121,7 @@
{"multivalue-rdn", OPT_MULTIVALUE_RDN, '-',
"Enable support for multivalued RDNs"},
{"days", OPT_DAYS, 'p', "Number of days cert is valid for"},
-{"set_serial", OPT_SET_SERIAL, 'p', "Serial number to use"},
+{"set_serial", OPT_SET_SERIAL, 's', "Serial number to use"},
{"extensions", OPT_EXTENSIONS, 's',
"Cert extension section (override value in config file)"},
{"reqexts", OPT_REQEXTS, 's',
diff -Nru openssl-1.1.0d/apps/s_cb.c openssl-1.1.0e/apps/s_cb.c
--- openssl-1.1.0d/apps/s_cb.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/s_cb.c 2017-02-16 12:58:20.0 +0100
@@ -922,6 +922,7 @@
BIO_printf(bio_err, "%s: Error adding xcert\n", opt_getprog());
goto err;
}
+*pexc = exc;
exc->certfile = opt_arg();
break;
case OPT_X_KEY:
diff -Nru openssl-1.1.0d/apps/ts.c openssl-1.1.0e/apps/ts.c
--- openssl-1.1.0d/apps/ts.c 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/apps/ts.c 2017-02-16 12:58:20.0 +0100
@@ -890,9 +890,15 @@
goto err;
f = TS_VFY_VERSION | TS_VFY_SIGNER;
if (data != NULL) {
+BIO *out = NULL;
+
f |= TS_VFY_DATA;
-if (TS_VERIFY_CTX_set_data(ctx, BIO_new_file(data, "rb")) == NULL)
+if ((out = BIO_new_file(data, "rb")) == NULL)
goto err;
+if (TS_VERIFY_CTX_set_data(ctx, out) == NULL) {
+BIO_free_all(out);
+goto err;
+}
} else if (digest != NULL) {
long imprint_len;
unsigned char *hexstr = OPENSSL_hexstr2buf(digest, _len);
diff -Nru openssl-1.1.0d/CHANGES openssl-1.1.0e/CHANGES
--- openssl-1.1.0d/CHANGES 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/CHANGES 2017-02-16 12:58:20.0 +0100
@@ -2,6 +2,19 @@
OpenSSL CHANGES
___
+ Changes between 1.1.0d and 1.1.0e [16 Feb 2017]
+
+ *) Encrypt-Then-Mac renegotiation crash
+
+ During a renegotiation handshake if the Encrypt-Then-Mac extension is
+ negotiated where it was not in the original handshake (or vice-versa) then
+ this can cause OpenSSL to crash (dependant on ciphersuite). Both clients
+ and servers are affected.
+
+ This issue was reported to OpenSSL by Joe Orton (Red Hat).
+ (CVE-2017-3733)
+ [Matt Caswell]
+
Changes between 1.1.0c and 1.1.0d [26 Jan 2017]
*) Truncated packet could crash via OOB read
diff -Nru openssl-1.1.0d/Configurations/unix-Makefile.tmpl openssl-1.1.0e/Configurations/unix-Makefile.tmpl
--- openssl-1.1.0d/Configurations/unix-Makefile.tmpl 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/Configurations/unix-Makefile.tmpl 2017-02-16 12:58:20.0 +0100
@@ -285,6 +285,7 @@
-$(RM) `find . -name '*{- $objext -}' -a \! -path "./.git/*"`
$(RM) core
$(RM) tags TAGS
+ $(RM) test/.rnd
$(RM) openssl.pc libcrypto.pc libssl.pc
-$(RM) `find . -type l -a \! -path "./.git/*"`
$(RM) $(TARFILE)
diff -Nru openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl
--- openssl-1.1.0d/crypto/aes/asm/aesv8-armx.pl 2017-01-26 14:10:21.0 +0100
+++ openssl-1.1.0e/crypto/aes/asm/aesv8-armx.pl 2017-02-16 12:58:20.0 +0100
@@ -59,9 +59,12 @@
.text
___
$code.=".arch armv8-a+crypto\n" if ($flavour =~ /64/);
-$code.=".arch armv7-a\n.fpu neon\n.code 32\n" if ($flavour !~ /64/);
- #^^ this is done to simplify adoption by n
Re: Location of the /usr/lib/ssl/certs symlink in the installer environment
On Wed, Nov 23, 2016 at 05:20:15PM +0100, Philipp Kern wrote: > Hi Kurt, > > when trying to add HTTPS support to the installer I noticed that openssl > seems to read /usr/lib/ssl/certs by default, rather than /etc/ssl/certs. > In Debian proper openssl (the binary package of the CLI) ships this as a > symlink to /etc/ssl/certs. Do you have a preference of where this > symlink should live in the installer environment? Should it be > libssl1.1-udeb or ca-certificates-udeb (which does not exist yet, I just > filed a bug with a patch to create it)? That makes me wonder what happens when the openssl binary isn't installed on other systems. Does it fail to find it's certificate store? But I guess adding that to the libssl / libcrypto package makes it more complicated to upgrade after an soname change. I wonder if I should change the default instead. ca-certificates could also always ship it ... Kurt
Re: [Pkg-openssl-devel] Bug#827951: libssl udeb inclusion in Jessie
On Thu, Jun 23, 2016 at 10:58:54AM +0200, Yann Soubeyrand wrote: > Package: openssl > Severity: normal > Version: 1.0.1t-1+deb8u2 > X-Debbugs-CC: debian-rele...@lists.debian.org > X-Debbugs-CC: debian-boot@lists.debian.org > > Hi, > > Marga Manterola provided a patch to build a libssl udeb as well as the > libcrypto udeb that was included in Sid (#802591). Could this patch be a > candidate for Jessie inclusion? If so, you can find a patch attached to > this mail. Is there a reason why you would like it in jessie? Will the installer start to make use of it? Kurt
Bug#760993: console-setup: CHARMAP no longer set properly
On Thu, Feb 18, 2016 at 06:16:26PM +0200, Anton Zinoviev wrote: > On Tue, Sep 09, 2014 at 08:18:01PM +0200, Kurt Roeckx wrote: > > Package: console-setup > > Version: 1.111 > > Severity: important > > > > In /etc/default/console-setup I have: > > CHARMAP="ISO-8859-1" > > > > However, my console acts like it's in UTF-8 mode. > > > > If I restart the console-setup service it does get properly set, > > so I'm guessing something else is overriding it. > > Hello! > > Do you remember if this system used systemd? > > Did you use the standard the QWERTY layout? I mean is it possible that > the console was leaved unconfigured (not only the charmap, but also the > keyboard) and the only reason you didn't notice this was that you used > QWERTY layout? I have no idea on which system this was. At least on this one I don't have console-setup installed, and I think it's currently the only one without systemd. I'm going to guess it was on this one anyway. All my systems are using qwerty. I might also have configured it to not touch the font. Kurt
Re: [Pkg-openssl-devel] Bug#802591: Please provide libssl udeb as well as the libcrypto udeb
On Wed, Oct 21, 2015 at 01:10:07PM +, Marga Manterola wrote: > I've noticed that experimental has a soversion bump for openssl, so I > created this patch against the version in unstable. If you want me to > create the patch against the version in experimental, please let me know. Since this will also need to go thru NEW, it think it makes most sense to have this as part of the other packages that changes names, but I'm waiting for the release team on when that goes to unstable. So I'm wondering how urgent this is. If I upload it to unstable now it might make it to testing faster. I have no idea how long the transition is going to take once it's uploaded to unstable. I guess I can figure out how to do this in experimental myself. Kurt
Bug#780902: unblock: openssl/1.0.1k-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, 1.0.1k-2 contains security fixes. Could you please unblock it? Kurt -- 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/20150321094038.ga19...@roeckx.be
Re: bastardizing packages or stepping down
On Thu, Mar 05, 2015 at 01:38:29PM +0300, Michael Tokarev wrote: But once I uploaded a next release of busybox to the archive, it was rebuilt using older, unfixed glibc, and the original problem reappeared. I didn't see any request to make sure the chroots are updated. Not having read the whole thing, would this solve your problem? Kurt -- 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/20150306094626.ga32...@roeckx.be
Re: Bug#775025: unblock: openssl/1.0.1k-1
Hi, Can you ACK that, or is there someone else in the d-i team that can do that? Kurt On Wed, Jan 14, 2015 at 05:52:58PM +0100, Niels Thykier wrote: Control: tags -1 d-i On 2015-01-10 12:01, Kurt Roeckx wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, I've uploaded a new upstream version of openssl to unstable. This contains fixes for 7 security issues affecting jessie. It also contains a lot of other bug fixes. Can you please unblock it? Kurt No problems from my PoV. CC'ing KiBi for d-i ACK. ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b69eea.7020...@thykier.net -- 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/20150120121730.ga20...@roeckx.be
Bug#760993: console-setup: CHARMAP no longer set properly
On Thu, Sep 11, 2014 at 07:03:13PM +0300, Anton Zinoviev wrote: On Tue, Sep 09, 2014 at 08:18:01PM +0200, Kurt Roeckx wrote: In /etc/default/console-setup I have: CHARMAP=ISO-8859-1 However, my console acts like it's in UTF-8 mode. If I restart the console-setup service it does get properly set, so I'm guessing something else is overriding it. In order to be sure that that the culprit is not console-setup but other program, do this: Open /bin/setupcon in a text editor and find the following block: elif [ $do_verbose ]; then case $verbose in NONE) report executing $cmd $@. $cmd $@ ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ $verbose ;; esac else case $verbose in NONE) report executing $cmd $@. $cmd $@ /dev/null 21 ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ ;; esac Then remove the symbol '' from both lines $cmd $@ Does the problem disappear if you do this? So I changed both FORK cases to be: $cmd $@ That doesn't change anything, and I don't see why that should change anything. Kurt -- 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/20140911164437.ga21...@roeckx.be
Bug#760993: console-setup: CHARMAP no longer set properly
Package: console-setup Version: 1.111 Severity: important Hi, In /etc/default/console-setup I have: CHARMAP=ISO-8859-1 However, my console acts like it's in UTF-8 mode. If I restart the console-setup service it does get properly set, so I'm guessing something else is overriding it. Kurt -- 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/20140909181801.ga6...@roeckx.be
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Thu, Feb 13, 2014 at 04:38:36PM +0300, Cyril Brulebois wrote: [ TL;DR: d-i FTBFS on sparc, what do we do now? ] Thomas Schmitt scdbac...@gmx.net (2013-12-10): Cyril Brulebois wrote: genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''. [...] Probably some FS-dependent fun? Anyone would have a clue about it? Looks like an internal error of genisoimage. '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01. See ECMA-119, 6.8.2.2 Identification of directories. These names are reserved for that purpose. Any other colliding ECMA-119 names should be handled by mangling. Thanks, Thomas. @Kurt: did anything change on the buildd setup side? Both lebrun and spontini got that FTBFS, while that wasn't the case before: https://buildd.debian.org/status/logs.php?pkg=debian-installerarch=sparc Nothing changed recently. They've been using tar based chroots for at least 6 months I think. Kurt -- 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/20140225175431.ga1...@roeckx.be
Re: HTTPS metadata in Mirrors.masterlist?
On Tue, Feb 11, 2014 at 01:45:53PM +, Colin Watson wrote: (And yes, I know that this is only of any actual use if we do certificate checks. Right now the way I have things hooked up is that you can add certificates to the d-i initramfs, either by rebuilding with SSL_CERTS set in build/config/local or by concatenating another initramfs-format archive of c_rehash-ed certificates unpacking to /usr/lib/ssl/certs; or else debian-installer/allow_unauthenticated=false will imply no certificate checking. You have to supply GNU wget anyway, since busybox wget doesn't speak HTTPS. If more people than I suspect want to use this then we might want to consider something with ca-certificates, but I felt that was overkill for now and it certainly involved more thinking about policy than I wanted to do.) So the first question I have about this if we can get ftp.TLD.debian.org certificates for this, and what happens when that host is down and DNS gets pointed to a different host? I have to guess that we should only do that on the hostname that is not ftp.TLD.debian.org, while I think it now only shows that name? Kurt -- 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/20140211174022.gb7...@roeckx.be
Re: [pkg-ntp-maintainers] Processed: Re: Bug#731594: debian-installer: time synchronisation should be installed by default
On Sat, Dec 07, 2013 at 01:27:16PM +, Debian Bug Tracking System wrote: retitle 731594 Please make ntpdate package priority standard Bug #731594 [ntpdate] debian-installer: time synchronisation should be installed by default Changed Bug title to 'Please make ntpdate package priority standard' from 'debian-installer: time synchronisation should be installed by default' ntpdate has always been indented to go away. It does not make sense to make it priority standard. If you want to make something priority standard of the ntp package it should be ntp itself. But in that case I would wait for the next major version (4.2.8) to be released which fixes a whole lot of issues people would run in to. The 4.2.8 version also contains a proper sntp client, which might be something you want instead of the full ntp daemon. Kurt -- 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/20131207165600.ga19...@roeckx.be
Bug#708771: debootstrap: pkgdetails.c is missing
Package: debootstrap Version: 1.0.49 Hi, Trying to run debootstrap on a system without perl, I get the following error: E: No pkgdetails available; either install perl, or build pkgdetails.c from source But I can't find pkgdetails.c Kurt -- 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/20130518140636.ga10...@roeckx.be
Re: Still failures for i386 and mipsel D-I daily builds
On Tue, Jun 07, 2011 at 07:01:49AM +0200, Christian PERRIER wrote: We still have no D-I daily builds for i386 and mipsel. For i386, Kurt mentioned that some fixes have to be done and th ecronjob is disabled until they've been made. It's not completely clear to me about *who* can do such fixes, apart from Phil Kern (who did setup the autobuild). I don't really want to point fingers..but I would like to see the probleme fixed..:-) phil re-wrote the script and it's currently building on biber (i386). cron is reactivated. Kurt -- 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/20110611160125.ga20...@roeckx.be
Re: i386, mips and mipsel D-I daily builds stopped since May 30th or 31st
On Fri, Jun 03, 2011 at 07:45:55AM +0200, Christian PERRIER wrote: buildd admins for i386, mips, mipsel, could you have a look? On Tue, May 31, 2011 at 12:16:23AM +0200, Kurt Roeckx wrote: After looking at the code, it's clear that it needs to be fixed. So I've disabled the cron on biber until it's fixed. This didn't happen yet afaik. Kurt -- 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/20110603135425.ga15...@roeckx.be
Unidentified subject!
wb-t...@buildd.debian.org Cc: Bcc: Subject: Re: i386 D-I daily builds seem stuck Reply-To: In-Reply-To: 20110530173805.ga13...@gnu.kitenet.net On Mon, May 30, 2011 at 01:38:06PM -0400, Joey Hess wrote: Kurt Roeckx wrote on May 28th: The log shows: INFO: Startup 20110528- /home/buildd/di/di-autobuild/buildscript: line 42: cd: di/lvroot/installer: No such file or directory So the git repository wasn't there, and neither was the svn. I just cloned it and it should be building now. Oddly, the i386 daily build is building from a old git tree version from May 23rd. Not sure how this is happening if you cloned it on the 28th. mipsel is also building from an outdated tree; all other builds that are currently running are using the latest tree. I've just pushed a change to the git build tree that will affect all arches. So the problem is that the lvroot directory didn't get mounted on boot, so the schroot just kept using the old version. The new clone I did in it was only being used to pull in new changes, but nothing got build against it. After looking at the code, it's clear that it needs to be fixed. So I've disabled the cron on biber until it's fixed. Kurt -- 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/20110530221500.ga29...@roeckx.be
Re: i386 D-I daily builds seem stuck
On Mon, May 30, 2011 at 01:38:06PM -0400, Joey Hess wrote: Kurt Roeckx wrote on May 28th: The log shows: INFO: Startup 20110528- /home/buildd/di/di-autobuild/buildscript: line 42: cd: di/lvroot/installer: No such file or directory So the git repository wasn't there, and neither was the svn. I just cloned it and it should be building now. Oddly, the i386 daily build is building from a old git tree version from May 23rd. Not sure how this is happening if you cloned it on the 28th. mipsel is also building from an outdated tree; all other builds that are currently running are using the latest tree. I've just pushed a change to the git build tree that will affect all arches. So the problem is that the lvroot directory didn't get mounted on boot, so the schroot just kept using the old version. The new clone I did in it was only being used to pull in new changes, but nothing got build against it. After looking at the code, it's clear that it needs to be fixed. So I've disabled the cron on biber until it's fixed. Kurt -- 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/20110530221623.gb29...@roeckx.be
Re: i386 D-I daily builds seem stuck
On Sat, May 28, 2011 at 08:03:26AM +0200, Christian PERRIER wrote: This is the second day where D-I daily builds for i386 didn't reach the D-I web site. May on of the i386 autobuilders admins look at this? The log shows: INFO: Startup 20110528- /home/buildd/di/di-autobuild/buildscript: line 42: cd: di/lvroot/installer: No such file or directory So the git repository wasn't there, and neither was the svn. I just cloned it and it should be building now. Kurt -- 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/20110528093747.ga25...@roeckx.be
Re: Squeeze, firmware and installation
On Mon, May 24, 2010 at 02:13:30PM +0100, Steve McIntyre wrote: Yup, definitely. We already have an unofficial non-free area on cdimage.debian.org which is where we've been pushing the firmware zip/tar.gz files already. I'll set up the extra images to be dropped in there. It would be nice if this could all be moved somewhere else so that it gets mirrored. Kurt -- 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/20100524144323.ga17...@roeckx.be
Re: lilo removal in squeeze (or, please test grub2)
On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: William Pitcock neno...@dereferenced.org (22/05/2010): This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. There should also be some folks fixing the discovered issues. grub2 currently seems to be having 18 RC bugs, plus a whole bunch of merged bugs, while lilo only has 1 RC bug. I think the difference is that lilo will probably not work for a lot of people while grub2 does work for a lot of people. And I understand that Debian's lilo maintainer basicly doesn't want to become upstream and rewrite everything when there is an alternative. But I agree that a call for extensive testing would be better if number of RC bugs would be a lot lower. Kurt -- 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/20100523114251.ga3...@roeckx.be
Bug#558448: keyboard-configuration: Does not set right alt correctly.
reopen 558448 thanks On Sun, Nov 29, 2009 at 12:13:47PM +0200, Anton Zinoviev wrote: On Sun, Nov 29, 2009 at 12:50:37AM +0100, Kurt Roeckx wrote: It seems that the AltGr key replacement currently has no effect. I've installed keyboard-configuration a few days ago and at that time selected The default for the keyboard layout, and things kept working like they were, it still acted like a right alt key. Console-setup does exactly what you requrested in the configuration file. If you want the righ alt key to behave as AltGr and not as Alt, when when console-setup asks the question AltGr key replacement, please answer Right Alt. Then check that in Please read the complete bug report before closing it. /etc/console-setup/keyboard you have XKBOPTIONS=lv3:ralt_switch There is no such file. I am closing this bug because you have already reported a duplicate of it. Please, look at http://bugs.debian.org/524235 I do know about that bug report, but that's a different issue. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558448: keyboard-configuration: Does not set right alt correctly.
On Sun, Nov 29, 2009 at 02:56:00PM +0200, Anton Zinoviev wrote: On Sun, Nov 29, 2009 at 12:25:32PM +0100, Kurt Roeckx wrote: reopen 558448 thanks It is pointless to reopen a bug if the maintainer doesn't understand the reason for this. Like I said it the bug report. I've set it to Right Alt but it still acts like a Left Alt. In fact, the setting never had any effect. When I originally set it to default, it kept working like a right alt while it really should have been working like a left alt. On Sun, Nov 29, 2009 at 12:13:47PM +0200, Anton Zinoviev wrote: On Sun, Nov 29, 2009 at 12:50:37AM +0100, Kurt Roeckx wrote: It seems that the AltGr key replacement currently has no effect. I've installed keyboard-configuration a few days ago and at that time selected The default for the keyboard layout, and things kept working like they were, it still acted like a right alt key. Console-setup does exactly what you requrested in the configuration file. If you want the righ alt key to behave as AltGr and not as Alt, when when console-setup asks the question AltGr key replacement, please answer Right Alt. Then check that in Please read the complete bug report before closing it. I've read it. Console-setup did exactly what you requested in the configuration file. No it didn't. Please look at what is in my config file in the bug report. /etc/console-setup/keyboard you have XKBOPTIONS=lv3:ralt_switch There is no such file. /etc/default/keyboard And I said what is in that file, and it has ralt_switch in it. Please carefully read my bug report. If you don't understand it, please don't close it but ask questions instead. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558448: keyboard-configuration: Does not set right alt correctly.
On Sun, Nov 29, 2009 at 03:51:21PM +0200, Anton Zinoviev wrote: reopen 558448 forcemerge 558475 558448 thanks On Sun, Nov 29, 2009 at 02:14:05PM +0100, Kurt Roeckx wrote: In fact, the setting never had any effect. When I originally set it to default, it kept working like a right alt while it really should have been working like a left alt. Ok, this maybe explains what happened. Remove /etc/console-setup/cached.kmap.gz. Yes, that fixes it. However, notice that it is pointless to use lv3:ralt_switch together with the standard US keymap. What do you mean? Things do not work anymore like they did without. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558448: keyboard-configuration: Does not set right alt correctly.
Package: keyboard-configuration Version: 1.49 Severity: important Hi, It seems that the AltGr key replacement currently has no effect. I've installed keyboard-configuration a few days ago and at that time selected The default for the keyboard layout, and things kept working like they were, it still acted like a right alt key. Now I've booted in a new kernel and it acted like a left alt key. So I've reconfigured it to set it to Right Alt. But that doesn't seem to have any effect, it still acts like a left alt key. The config file /etc/default/keyboard says: XKBMODEL=pc102 XKBLAYOUT=us XKBVARIANT= XKBOPTIONS=lv3:ralt_switch,terminate:ctrl_alt_bksp Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541112: kde cd does not install kde, nor a working graphical environment.
Package: installation-reports Severity: serious Hi, I've used the 5.0.2 KDE i386 install image (debian-cd/5.0.2/i386/iso-cd/debian-502-i386-kde-CD-1.iso) Everything installed without a problem. As far as I know, everything was done using the default options, except for things like the keyboard layout, location, login name, and maybe something else like that. It asked if I wanted to use a remote apt repository and I configured one of the mirrors. After a reboot, kdm started and asked for a login/pass. I could log in, but the only thing I got was a background. Nothing else was running. Back at the login screen I saw that only 3 sessions types were known, twm, failsafe and something else I can't remember. But kde clearly wasn't part of it. So I switch to a console and started tasksel, which had the options for a graphical desktop enviroment, print server and mail server selected. It didn't install anything new. So I manually installed kde with apt-get install kde. kde-core wasn't installed either. I think this installed like about 200 new packages. I think at some point the keyboard selection for X changed from the belgian layout (azerty) to the US layout (qwerty). Atleast in the console it still works like it should. I think the first time trying to login in kdm it was correct, but it might also have been a habbit of typing it with the other layout at that point. In any case, it's not set up correctly. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Openssl
Hi, Can openssl 0.9.8k-3 be pushed to testing? It fixed a number of security issues. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
On Fri, May 15, 2009 at 01:23:47AM +0200, Frans Pop wrote: Now I see -- most traditional keyboard layouts are defining the right Alt as AltGr (including the default one). In the past console-setup did the same but there were some complaints from American users who did not like this behaviour. I see no good reason for that. Note that the US keyboard layout is fairly common in a lot of other countries than the US itself. It is for example THE most common keyboard layout in the Netherlands and Dutch users very much _do_ expect to have an alt-gr key by default as it is essential to type accented letters. It is common in Belgium too, but not as common as the be azerty layout. But (on the console) the right alt key is not used to type accented letters, you use the compose key for that, which defaults to ctrl+. I have no idea what the effect of that is under X. One option might be to define a US international variant that does have the alt-gr. When converting from console-data that might mean _always_ asking whether the user wants one or the other if the current setting is US. The US international on windows uses dead keys, which is something I wouldn't want. But such option is probably useful for some people. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
On Fri, May 15, 2009 at 07:39:49PM +0200, Kurt Roeckx wrote: I asked my question incorrectly. I meant all these were working if in the configuration of console-setup you selected the right Alt to function as AltGr. This means the question 'Which key must be AltGr' means 'Which key must function as AltGr' and you need to answer 'Right Alt' to this question. I think any way you turn this, this is a very unclear question, if you don't know all the background about it. It asks for an AltGr replacement, and you can select: No AltGr key Right Alt Right Control Right Logo key Menu key Left Alt Left Logo key Keypad Enter key Both Logo keys Both Alt keys And I think No AltGr key and Left Alt are actually the same option. With Left Alt the configuration file /etc/default/console-setup will contain lv3:lalt_switch in the XKBOPTIONS line. If this is not so or if this option does nothing, then this is a bug that needs a fix (I can not test this right now). When I tested it, selecting No AltGr key, my right alt key reacts the same as the left alt key. So what do you think the No AltGr key should do? The right alt key shouldn't do anything? And I still got the question wrong. So selecting Left Alt would mean that the left alt would react as AltGr (while the right alt would act as Alt). Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
On Fri, May 15, 2009 at 01:03:53PM +0300, Anton Zinoviev wrote: On Fri, May 15, 2009 at 12:32:13AM +0200, Kurt Roeckx wrote: Now I see -- most traditional keyboard layouts are defining the right Alt as AltGr (including the default one). In the past console-setup did the same but there were some complaints from American users who did not like this behaviour. I see no good reason for that. AltGr is almost useless with the basic 'us' layout does nothing. Few people are switching to vc 13-24 and they certainly have the option to define an AltGr key in console-setup. I agree that it does very little. The only other thing it seems to do is allowing you to type chars in hex. I suppose all these are working if in the configuration of console-setup you select the right Alt to be AltGr? If not, this is a bug that needs a fix. You can not select AltGr. I asked my question incorrectly. I meant all these were working if in the configuration of console-setup you selected the right Alt to function as AltGr. This means the question 'Which key must be AltGr' means 'Which key must function as AltGr' and you need to answer 'Right Alt' to this question. I think any way you turn this, this is a very unclear question, if you don't know all the background about it. It asks for an AltGr replacement, and you can select: No AltGr key Right Alt Right Control Right Logo key Menu key Left Alt Left Logo key Keypad Enter key Both Logo keys Both Alt keys And I think No AltGr key and Left Alt are actually the same option. With Left Alt the configuration file /etc/default/console-setup will contain lv3:lalt_switch in the XKBOPTIONS line. If this is not so or if this option does nothing, then this is a bug that needs a fix (I can not test this right now). When I tested it, selecting No AltGr key, my right alt key reacts the same as the left alt key. So what do you think the No AltGr key should do? The right alt key shouldn't do anything? Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
On Mon, May 04, 2009 at 10:26:14PM +0300, Anton Zinoviev wrote: On Mon, May 04, 2009 at 08:12:08PM +0200, Kurt Roeckx wrote: And it shouldn't make both keys work the same. They never have worked the same for me. One is a Left Alt, the other a Right Alt. It seems I need to select the Right Alt option to make my keyboard work like it used to again. I didn't have any kind of configuration before. Now I see -- most traditional keyboard layouts are defining the right Alt as AltGr (including the default one). In the past console-setup did the same but there were some complaints from American users who did not like this behaviour. I see no good reason for that. So now by default for 'us' layout both Alts are equal. You are right -- you have to point the right Alt as AltGr key if you want the old behaviour. Alternatively you can use the Alt+Shift combination instead of AltGr. [...] Yet, some key combinations work differently depeding on wether you use the left or the right alt key. Some of those are: left alt + numeric keys: Type char in decimal notation right alt + numeric keys: Type char in hex notation left alt + F1-12: Switch to vc 1-12 right alt + F1-12: Switch to vc 13-24 left alt acts like the meta key, the right alt does't. I suppose all these are working if in the configuration of console-setup you select the right Alt to be AltGr? If not, this is a bug that needs a fix. You can not select AltGr. It asks for an AltGr replacement, and you can select: No AltGr key Right Alt Right Control Right Logo key Menu key Left Alt Left Logo key Keypad Enter key Both Logo keys Both Alt keys And I think No AltGr key and Left Alt are actually the same option. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
On Mon, May 04, 2009 at 08:12:51PM +0300, Anton Zinoviev wrote: On Wed, Apr 15, 2009 at 07:30:01PM +0200, Kurt Roeckx wrote: When installing console-setup, it asks for various keyboard settings. I've selected pc104 - usa - usa. Then it asks for an AltGr key replacement. A standard US keyboard does not have an AltGr key, and I guess this is why it's asking this question? This question is always asked (but sometimes it is hidden because of Debconf priority). It simply asks the user which one of the keys should act as Compose key. The default option is No AltGr key which seems to make it a Left Alt key. Are you sure about this? I tested the pc104-usa-usa configuration and it seems the option No AltGr key makes both Alt keys to work as Alt (not as AltGr). And it shouldn't make both keys work the same. They never have worked the same for me. One is a Left Alt, the other a Right Alt. It seems I need to select the Right Alt option to make my keyboard work like it used to again. I didn't have any kind of configuration before. I don't understand why you need AltGr - the standard us layout doesn't have any symbol for AltGr. Maybe you are using some other layout? It doesn't have any AltGr. Yet, some key combinations work differently depeding on wether you use the left or the right alt key. Some of those are: left alt + numeric keys: Type char in decimal notation right alt + numeric keys: Type char in hex notation left alt + F1-12: Switch to vc 1-12 right alt + F1-12: Switch to vc 13-24 left alt acts like the meta key, the right alt does't. There might be some others that change depending on L/R too, but I probably don't use them. I can not use the right alt to type other chars like what a AltGr is used for. Note that before console-setup was pulled in by X, I did not have any configuration for my keyboard at all. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524239: Bug#524233: console-setup should conflict with console-data
On Thu, Apr 16, 2009 at 07:13:36AM +0200, Christian Perrier wrote: Quoting Anton Zinoviev (an...@lml.bas.bg): merge 524233 524239 thanks On Wed, Apr 15, 2009 at 07:14:34PM +0200, Kurt Roeckx wrote: console-setup and console-data both allow you to setup the keyboard layout but they do not take each other settings into account. Why this should be considered a bug? Normaly the users don't have to install both packages but perhaps there are many reasons why they might want to install them both. Console-data and console-cyrillic have happily coexisted for a decade and now this can continue with console-setup (exept that it seems console-data and console-cyrillic are going to become obsolete). As the de facto maintainer of console-data, I agree with this. I have to add that I unfortunately am entirely unable to implement in c-d something to have it grab keymap definitions from console-setup. Moreover, as both use different origins for the keymaps (c-s uses X.org keymaps while c-d provides the old-style Linux console keymaps, crafted by generation of Linux users over yearsturning into a giant mess), it is very likely that many keymaps do not necessarily correspond. I would be delighted to obsolete console-data, as many people know. There are however several steps to achieve before that happens (one of those being d-i uing console-setup). Well, X now Depends on console-setup, so you're atleast going to get more people install this. An I indeed have no idea about how to turn console-data into a completely obsolete package and then offer users a decent transition to console-setup I think there are a few things that console-setup doesn't do that atleast console-tools does: - calling setterm to set powersaving mode. - Set keyboard rate - Being able to set numlock on boot I got a little confused about console-data being the package that ask the debconf questions, but it seems that console-common is actually the package that set up keyboard. So you can argue where the second bug belongs to. I have no idea if console-setup does anything more than console-common / console-data. Anyway, my problem with the current situation is that there are 2 config files where I can set the same thing, and it's not obvious which of the 2 is going to win. In general, it would be better that there was only 1 source of keyboard layouts. And I have no problem going with those of X, but I have no idea if the quality of both are the same or not. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524233: console-setup should conflict with console-data
Package: console-setup, console-data Severity: serious Hi, console-setup and console-data both allow you to setup the keyboard layout but they do not take each other settings into account. I think there is yet an other package that does the same thing, but I'm not sure about it's name. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
Package: console-setup Version: 1.32 Hi, When installing console-setup, it asks for various keyboard settings. I've selected pc104 - usa - usa. Then it asks for an AltGr key replacement. A standard US keyboard does not have an AltGr key, and I guess this is why it's asking this question? The default option is No AltGr key which seems to make it a Left Alt key. It seems I need to select the Right Alt option to make my keyboard work like it used to again. I didn't have any kind of configuration before. The question isn't also very clear. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524236: console-setup: Default compose key is ctrl+period
Package: console-setup Version: 1.32 Hi, It has a debconf question about setting up a second compose key, and says alt+period is the compose key. It's ctrl+period that is the compose key. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524239: console-setup should conflict with console-tools
Package: console-setup, console-tools Severity: serious Hi, Both packages allow you to set up the encoding and font to load, and they do not take each other settings into account. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Unblock openssl
Hi, Can openssl 0.9.8g-16 be hinted to testing? It fixes a security issue. It has a udeb. Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512348: efi-reader: support for i386 and amd64.
Package: efi-reader Severity: wishlist EFI is supported i386 and amd64 too. Can this package be made available on them if it's useful? Kurt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
openssl 0.9.8g-14
Hi, Could you please hint openssl in testing? The changelog: * Don't give the warning about security updates when upgrading from etch since it doesn't have any known security problems. * Automaticly use engines that succesfully initialised. Patch from the 0.9.8h upstream version. (Closes: #502177) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Bug#492758: openssl: OpenSSL generates errors with Firefox 3
On Sat, Aug 02, 2008 at 10:41:13PM +0200, Luk Claes wrote: Kurt Roeckx wrote: Hi, I would like to fix this for lenny. Would such a patch be acceptable? Yes. Can that change be hinted to testing? Kurt Cheers Luk On Mon, Jul 28, 2008 at 11:21:49AM -0600, Soren Stoutner wrote: Package: openssl Version: 0.9.8g-12 Severity: important There is a bug in the currently packaged version of OpenSSL that generates errors with Firefox 3. The bug has already been fixed upstream with version 0.9.8h. See http://cvs.openssl.org/chngview?cn=17088 and http://davidsmalley.com/2008/6/22/firefox-3-triggers-an-openssl-bug Packaging 0.9.8h, even if it is placed in experimental, would allow me to update my production web servers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Bug#492758: openssl: OpenSSL generates errors with Firefox 3
On Mon, Aug 11, 2008 at 11:01:14PM -0300, Otavio Salvador wrote: Kurt Roeckx [EMAIL PROTECTED] writes: On Sat, Aug 02, 2008 at 10:41:13PM +0200, Luk Claes wrote: Kurt Roeckx wrote: Hi, I would like to fix this for lenny. Would such a patch be acceptable? Yes. Can that change be hinted to testing? Could you paste the changelog? openssl (0.9.8g-13) unstable; urgency=low . * Fix a problem with tlsext preventing firefox 3 from connection. Patch from upstream CVS and part of 0.9.8h. (Closes: #492758) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openssl 0.9.8g-9
Hi, I've just uploaded openssl 0.9.8g-9 which contains an important security fix. Please let it migrate to testing. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hint openssl 0.9.8g-8 in testing
Hi, Could you please hint openssl 0.9.8g-8 in testing? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hint openssl in testing.
Hi, Could the openssl version from unstable be hinted testing? I think the ABI changes have lived long enough in unstable. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hint openssl into testing.
Hi, Could you hint openssl 0.9.8g-3 in testing? Note that it has a udeb. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hint openssl into testing.
On Sun, Dec 09, 2007 at 02:51:18PM +0100, Frans Pop wrote: On Sunday 09 December 2007, Kurt Roeckx wrote: Could you hint openssl 0.9.8g-3 in testing? Note that it has a udeb. You should probably first do something with #445090, which is still RC despite being marked unreproducible... This also affects the version in stable/testing. It's also only reported against the version in stable. I did some changes to the script in 0.9.8g-2 (which isn't in testing), but I have no idea if that fixed it or not. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449142: autopartkit: FTBFS: make: *** [clean] Error 1
Package: autopartkit Version: 1.27 Severity: serious Hi, Your package is failing to build with the following error: /usr/bin/fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp rm -f debian/autopartkit.postinst [ -f Makefile ] /usr/bin/make distclean make: *** [clean] Error 1 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules clean gave error exit status 2 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please hint openssl 0.9.8e-9 into testing.
Hi, I'd like to get openssl 0.9.8e-9 into testing because of the security fix. Note that it's frozen because it contains an udeb. #440538 might also affect the it's migration to testing, but I believe I've just set it's state right. I have no reason to believe testing doesn't have that problem. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439660: partman-efi: Support for amd64
Package: partman-efi Hi, gnu-efi recently got support for amd64. I think it makes sense to also use this package on amd64, so can support for amd64 be added? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414190: closed by Attilio Fiandrotti [EMAIL PROTECTED] (Closing this bug because not reproducible)
On Mon, Jul 09, 2007 at 08:08:32PM +0200, Frans Pop wrote: tags 414190 + unreproducible On Monday 09 July 2007 19:52, Kurt Roeckx wrote: Please don't close this bug unless you're really sure this can't be reproduced. I'll try a recent daily image shortly. If I don't mail back, please ask me. I don't completely agree with you. We have not seen _anything_ like this, either in our own tests or in any other reports. But if you want to retest, feel free to do so. Just make sure you do close this BR yourself if you cannot reproduce. I can't reproduce it with the etch netinst/kde images or with a current daily netinst. So it seems to be fixed. Anyway, I didn't reopen it, forgot to mail control@ Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414190: closed by Attilio Fiandrotti [EMAIL PROTECTED] (Closing this bug because not reproducible)
reopen 414190 thanks From: Attilio Fiandrotti [EMAIL PROTECTED] Date: Mon, 25 Jun 2007 14:01:56 +0200 To: [EMAIL PROTECTED] Subject: Closing this bug because not reproducible I wasn't able to reproduce this bug with Etch nor with trunk installer and i strongly suspect the problem was due to the use of an old installer image. Please don't close this bug unless you're really sure this can't be reproduced. I'll try a recent daily image shortly. If I don't mail back, please ask me. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366715: installation-report: Installer gets stuck if it can't access security.debian.org
On Thu, May 11, 2006 at 06:57:30AM +0200, Christian Perrier wrote: I wonder whether we could have a kind of compromise here: -keep the current behaviour when a regular mirror has been chosen -at least ask for a proxy for security.d.o when the mirror settings have been entered manually The current situation when using a CD installation: - It asks: Use a network mirror?, and I answer no - It hangs for some time (90 sec?) with (I think): Scanning the security updates repository... - You get a message that it failed and that it's commented out. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414190: cdebconf-gtk-udeb: Selected text for checkboxes dissapears.
Package: cdebconf-gtk-udeb Version: 0.113 Hi, I was using the debian-testing-i386-kde-CD-1.iso from http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/ from 05-Mar-2007. I assume it has either version 0.113 or 0.114 of cdebconf-gtk-udeb in it, not sure. When I came to the point where xserver-xorg gets configured, it asks which resolutions you want to have. This is a list of checkboxes. When clicking on one of the lines the text seems to be dissapearing. I think it's changing the background so you know you clicked on it, but it doesn't put any text in it. You only get to see a little square. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402825: rootskel: FTBFS: undefined reference to `__FD_ZERO'
Package: rootskel Version: 1.47 Severity: serious Hi, Your package is failing to build on a few arches with the following error: make[3]: Entering directory `/build/buildd/rootskel-1.47/src-bootfloppy/bin' klcc-c -o cpio.o cpio.c klcc-c -o timeout_read.o timeout_read.c klcc -shared -s -o cpio cpio.o klcc -shared -s -o timeout_read timeout_read.o timeout_read.o: In function `main': timeout_read.c:(.text+0x7e): undefined reference to `__FD_ZERO' timeout_read.c:(.text+0x8a): undefined reference to `__FD_SET' make[3]: *** [timeout_read] Error 1 It seems that on amd64 those are defined as inline functions in /usr/lib/klibc/include/asm-x86_64/posix_types.h but only when __KERNEL__ is set. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402825: rootskel: FTBFS: undefined reference to `__FD_ZERO'
reassign 402825 libklibc-dev severity 402746 serious merge 402746 402825 thanks So it seems those are the same bug, merging them. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397649: install-report: NTP sync missing by default
On Sun, Nov 12, 2006 at 03:57:25PM -0500, Rick Thomas wrote: Installing ntp by default (making it have priority standard) would be good for the many Debian users who have always-on network access. But it would be a problem for the minority who have no or only intermittent (e.g. dial-up) network access. For ntpd to really work properly you need a static IP address. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393987: save-logs: Add acpidump to report-hw?
Package: save-logs Hi, We now have an acpidump in Debian. It might be useful if report-hw could also dump that information, in case of problems with acpi. The package is rather small. On amd64 we have: Package: acpidump Installed-Size: 72 Size: 11322 -rwxr-xr-x 1 root root 11184 Aug 22 19:38 /usr/bin/acpidump It's available on i386 ia64 and amd64. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391474: partman: Detecting raid devices when starting the partitioner.
Package: partman-md Hi, This bug probably doesn't belong to this package, but it's the most relevant I could find. Please reassign as needed. I've done an netinst installation on an amd64 with the etch beta 3 (20060806) version. After a failed installation, I'm trying to do the same thing again, to see what was wrong. In the previous installation, I've set up software raid. My partitions are still showing up as having software raid, but I don't see the software raid device. So, I start the software raid configuration, and want to add a new md device, but it fails because there are no unused raid partitions left. Just starting the software raid configuration and pressing then directly selecting finish results in it rescanning the disks, and showing my raid devices as it should. It would be nice if I didn't have to do that, and that it could auto load the md devices when it sees that there are raid partitions. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391489: grub-installer: Raid 1 /boot installations.
Package: grub-installer Hi, I've done an netinst installation on an amd64 with the etch beta 3 (20060806) version. I've setup my /boot as a raid 1 device, so that in case of failure, I could still boot from my other disks. Looking for a solution, on how I could set up grub so it could boot from any disk. I found bug #310798, and was wondering if the installer could set grub so that that worked. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391483: partman-md: Deleting md devices doesn't work.
Package: partman-md Hi, I've done an netinst installation on an amd64 with the etch beta 3 (20060806) version. It seems that deleting md devices doesn't work. If I select delete md device, it's still showing up as md device. You can't configure it or anything, doesn't have a size and things like that. I think at that point it also gives a warning about an unknown size. After a failed installation where I created 2 md devices and it failed to boot, I tried removing the first md devices that had /boot on it, to create a normal partition to see if I could boot from that. Since it now was acting strange when I deleted the md device, I've also removed the second devices, at which point it showed those 2 raid devices in a weird state. I then created a new md device with the same partitions as my original second md device had. I've only changed the raid partition of the first disk to to a normal partition with an ext2 filesystem. I believe that at that point when it was rescanning the disks, I saw some strange error messages that I didn't write down and can't remember exactly. But it seems that sdb1 and sdb2 had the same uid or something, and that it selected sdb2 instead of sdb1 because sdb1's size didn't match. Or atleast that's what I think the message tried to say. I might have seen that error message after another reboot or something, I'm not really sure at what point in my installation attempt I saw that message. I assume that the error message is because md0 still had the same uid, and that I've used an other disks for it now. It would be nice if I deleted an md device, the uids on the partitions in it would be cleared too. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388320: debian-installer: rescue mode: show software raid devices.
Package: debian-installer Version: 20060806 Severity: wishlist Hi, I've just tried to the etch beta3 image as rescue CD. Everything seems to be working properly. I'm using a software raid, and it's properly detecting that. At a certain point, it asks what I want to mount as my root partition. It's showing me a list of all partitions on all the dists. It would be useful if it also showed my raid device. Mounting /dev/md/0 manually worked without problems. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp-maintainers] Bug#352610: Please create a udeb for ntpdate
On Sun, Jul 16, 2006 at 11:19:17AM +0200, Marco d'Itri wrote: On Jul 15, Martin Michlmayr [EMAIL PROTECTED] wrote: Is this libcrypto dependency strictly needed (what for) or could the udeb be built in a way that it's needed? libcrypto0.9.8-udeb appears to be about a meg in size while ntpdate has less than 50K. It's still very big. For d-i we should use a simpler SNTP-only client, which would not be bigger than a few KB. sntp was never part of the debian ntp package, and has license problems so is removed in the current svn version. As it is in the source, it doesn't have any license. Anyway, compiling what is in the upstream tarball gives: -rwxr-xr-x 1 kurt kurt 102198 Jul 16 10:04 sntp Which is half the size of ntpdate. But it should be possible to find software that is still alot smaller than that. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp-maintainers] Bug#352610: Please create a udeb for ntpdate
On Sun, Jul 16, 2006 at 12:23:07PM +0200, Marco d'Itri wrote: On Jul 16, Kurt Roeckx [EMAIL PROTECTED] wrote: It's still very big. For d-i we should use a simpler SNTP-only client, which would not be bigger than a few KB. sntp was never part of the debian ntp package, and has license problems so is removed in the current svn version. As it is in the source, it doesn't have any license. I did not refer to any specific implementation. E.g. I have a SNTP client written in about 200 lines of perl. Yes, I also find this one: http://www.kloth.net/software/sntp.php And one in ruby ... Like I said, it should be easy to find something. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp-maintainers] Bug#352610: Please create a udeb for ntpdate
On Sat, Jul 15, 2006 at 08:51:05PM +0200, Martin Michlmayr wrote: * Kurt Roeckx [EMAIL PROTECTED] [2006-07-15 00:53]: Because of recent changed I did (that haven't been commited yet), ntpdate now depends on libcrypto, so the ntpdate-udeb would end up with a dependency on libcrypto0.9.8-udeb. I hope that's not a problem? Is this libcrypto dependency strictly needed (what for) or could the udeb be built in a way that it's needed? libcrypto0.9.8-udeb appears to be about a meg in size while ntpdate has less than 50K. There was an internal version of md5 that has a license problem so was removed. Since we already link to libcrypto, I replaced the md5 code by calling the functions from libcrypto which are compatible. Maybe we can link ntpdate-udeb staticly to libcrypto? That should reduce the size. Initial test shows that for current version of the normal ntpdate: -rwxr-xr-x 1 kurt kurt 226297 Jul 15 19:41 ntpdate Installed-Size: 184 And linked staticly to libcrypto: -rwxr-xr-x 1 kurt kurt 230536 Jul 15 19:40 ntpdate Installed-Size: 188 And the dependency on libssl is removed. So this looks like something that could work. Some other change you should probably be aware of is that we have a dependency on netbase now because we need /etc/services. Is there something else we need to depend on for the udeb, or can we depend on netbase? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp-maintainers] Bug#352610: Please create a udeb for ntpdate
On Sat, Jul 15, 2006 at 12:19:52AM +0200, Martin Michlmayr wrote: * Peter Eisentraut [EMAIL PROTECTED] [2006-07-14 23:27]: ntpdate doesn't set the hardware clock, so the only thing this would achieve is having a good clock while the installer runs. Is that useful? Yes, otherwise we e.g. end up with a filesystem that was modified in 1970 and e2fsck will complain on the next boot. Since I filed this bug, someone suggested that a tool other than ntp might be better since it's smaller. Unfortunately, I cannot remember the name right now. I'm CCing -boot so other people can comment, but unless there are great ideas, I'm still interesting in having an ntp udeb. Because of recent changed I did (that haven't been commited yet), ntpdate now depends on libcrypto, so the ntpdate-udeb would end up with a dependency on libcrypto0.9.8-udeb. I hope that's not a problem? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status on amd64.
On Mon, Jun 12, 2006 at 11:03:19AM +0200, Frans Pop wrote: No need to CC me on such requests. I will see them on d-release. I'll answer when I get to that list (just got home and looks like the HD of one of my servers is dead). It's not needed anymore, we've uploaded the old versions to tpu, and they got moved into testing. I've uploaded debian-installer_20060304 and it's in byhand now. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359336: gtk+2.0-directfb: GMemChunk deprecated and disabled.
Hi, I've done an NMU for it. I removed the disable for 2 demos and then it build. The upcoming upstream release will probably fix this properly using the new slice method. Patch attached. Kurt diff -u gtk+2.0-directfb-2.0.9.2/debian/changelog gtk+2.0-directfb-2.0.9.2/debian/changelog --- gtk+2.0-directfb-2.0.9.2/debian/changelog +++ gtk+2.0-directfb-2.0.9.2/debian/changelog @@ -1,3 +1,12 @@ +gtk+2.0-directfb (2.0.9.2-14.1) unstable; urgency=low + + * Non-maintainer upload. + * Don't use -DG_DISABLE_DEPRECATED for the demos. It used the old +GMemChunk interface, which is still present in glib, but is +deprecated. (Closes: #359336) + + -- Kurt Roeckx [EMAIL PROTECTED] Mon, 3 Apr 2006 21:24:41 +0200 + gtk+2.0-directfb (2.0.9.2-14) unstable; urgency=low * Change to Arch: any. (in particular, to support ppc64 and armeb) only in patch2: unchanged: --- gtk+2.0-directfb-2.0.9.2.orig/debian/patches/40_g_disable_deprecated.patch +++ gtk+2.0-directfb-2.0.9.2/debian/patches/40_g_disable_deprecated.patch @@ -0,0 +1,20 @@ +--- gtk+-directfb-2.0.9-2/demos/gtk-demo/Makefile.am.old 2006-04-03 20:45:01.0 +0200 gtk+-directfb-2.0.9-2/demos/gtk-demo/Makefile.am 2006-04-03 20:45:10.0 +0200 +@@ -27,7 +27,6 @@ + -DDEMOCODEDIR=\$(democodedir)\ \ + -I$(top_srcdir) \ + -I$(top_builddir)/gdk \ +- -DG_DISABLE_DEPRECATED \ + -DGDK_DISABLE_DEPRECATED\ + -DGDK_PIXBUF_DISABLE_DEPRECATED \ + -DGTK_DISABLE_DEPRECATED\ +--- gtk+-directfb-2.0.9-2/demos/Makefile.am.old2006-04-03 20:48:47.0 +0200 gtk+-directfb-2.0.9-2/demos/Makefile.am2006-04-03 20:48:54.0 +0200 +@@ -5,7 +5,6 @@ + INCLUDES = @STRIP_BEGIN@ \ + -I$(top_srcdir) \ + -I$(top_builddir)/gdk \ +- -DG_DISABLE_DEPRECATED \ + -DGDK_DISABLE_DEPRECATED\ + -DGDK_PIXBUF_DISABLE_DEPRECATED \ + -DGTK_DISABLE_DEPRECATED\
Fixed in NMU of gtk+2.0-directfb 2.0.9.2-14.1
tag 359336 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 3 Apr 2006 21:24:41 +0200 Source: gtk+2.0-directfb Binary: libgtk+2.0-directfb0-udeb libgtk+2.0-directfb-dev libgtk+2.0-directfb0 Architecture: source i386 Version: 2.0.9.2-14.1 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Kurt Roeckx [EMAIL PROTECTED] Description: libgtk+2.0-directfb-dev - gtk+2.0 implementation for the frame buffer, development files libgtk+2.0-directfb0 - gtk+2.0 implementation for the frame buffer libgtk+2.0-directfb0-udeb - gtk+2.0 implementation for the frame buffer (udeb) Closes: 359336 Changes: gtk+2.0-directfb (2.0.9.2-14.1) unstable; urgency=low . * Non-maintainer upload. * Don't use -DG_DISABLE_DEPRECATED for the demos. It used the old GMemChunk interface, which is still present in glib, but is deprecated. (Closes: #359336) Files: d6dbf9e000e49953ee9ed2421f31a089 826 libs optional gtk+2.0-directfb_2.0.9.2-14.1.dsc 0a1768b38acea8d624b27eb23c2daf04 6191 libs optional gtk+2.0-directfb_2.0.9.2-14.1.diff.gz a3843284f5ef22addd8f689cb0731bf7 975204 debian-installer extra libgtk+2.0-directfb0-udeb_2.0.9.2-14.1_i386.udeb e20db6a59d54548609e7f5993c450c77 3228932 libdevel optional libgtk+2.0-directfb-dev_2.0.9.2-14.1_i386.deb fcf8936da6fbaab2d3e116d298a50804 1016056 libs optional libgtk+2.0-directfb0_2.0.9.2-14.1_i386.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMXk5QdwckHJElwsRAniSAJ97i1+9IFuMLln7Px26F0DRzKtU0QCg0aHi CqpWbQIlQg/K7NsaURIWTSU= =YULL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359336: gtk+2.0-directfb: GMemChunk deprecated and disabled.
Package: gtk+2.0-directfb Version: 2.0.9.2-14 Severity: serious Hi, Your package is failing to build with the following error: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DDEMOCODEDIR=\/usr/share/gtk-2.0/demo\ -I../.. -I../../gdk -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DG_DISABLE_CAST_CHECKS -pthread -D_REENTRANT -D_GNU_SOURCE -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/directfb -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/include/freetype2-DNDEBUG=1 -fomit-frame-pointer -Os -Wall -c appwindow.c In file included from ../../gtk/gtk.h:131, from appwindow.c:6: ../../gtk/gtkstatusbar.h:71: error: syntax error before 'GMemChunk' ../../gtk/gtkstatusbar.h:71: warning: no semicolon at end of struct or union ../../gtk/gtkstatusbar.h:85: error: syntax error before '}' token make[4]: *** [appwindow.o] Error 1 The problem is that GMemChunk got deprecated, and it's being compiled with G_DISABLE_DEPRECATED, so it's disabled. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286848: localechooser: FTBFS: missing build dependencies
Package: localechooser Version: 0.02 Severity: serious Hi, The package is failing to build in a clean chroot because of missing build dependencies. It's missing atleast locales and iso-codes. With those 2 extra installed it seem to build without problems. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279508: Debian AMD64 installer error
On Sat, Nov 13, 2004 at 09:26:59PM +0800, gulfstream wrote: Who could tell me how to solve the problem? When the bug will be fixed? Could you atleast say which installation method you've used and which version you've used? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270516: busybox-cvs-floppy-udeb: Support for amd64.
Package: busybox-cvs-floppy-udeb Version: 20040623-1 Could you please add amd64 to the arch list for busybox-cvs-floppy-udeb? I've requested this before (#249688, got closed an archived) and now someone requested to have boot floppies. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to build netinst images.
Can someone please explain me in short how to make those netinst images for sid? I've tried using the debian-cd package but it's failing for me. I've changed the debian-cd package to add amd64 to the various lists with arches in them. I get: make list COMPLETE=0 TASK=tasks/debian-installer Apt-get is updating his files ... Ign file: sid/main Release Ign file: sid/contrib Release Ign file: sid/main/debian-installer Release Reading Package Lists... Building Dependency Tree... :272: warning: garbage at end of `#ifdef' argument Generating the complete list of packages to be included ... Dispatching the packages on all the CDs ... == Here are the settings you've chosen for making the list: List of prefered packages: /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tmp/sid-amd64/list Exclude file: /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tmp/sid-amd64/list.exclude Complete selected packages with all the rest: no Include non-free packages: no Include non-US packages: no == Use of uninitialized value in pattern match (m//) at /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tools/list2cds line 101. Use of uninitialized value in pattern match (m//) at /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tools/list2cds line 101. [...] Use of uninitialized value in pattern match (m//) at /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tools/list2cds line 108. Statistics: Number of packages: 14182 Number of excluded: 2 of 14182 == -- Generating dependencies tree with apt-cache depends... -- Adding standard, required, important and base packages on the first CD ... Standard system already takes 303628916 bytes on the first CD. -- Starting to add packages to the CDs ... CD 1 will only be filled with 311158944 bytes ... CD 1 will have 560 packages. Dispatching the sources on all the CDs ... Using package file /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tmp/sid-amd64/1.packages CD 1 will only be filled with 591302213 bytes ... CD 1 will have 1041 files from source packages. This doesn't really look right to me. It seems to be trying to build the whole CD? I'm trying to go on seeing what happens I get: make packages Apt-get is updating his files ... Ign file: sid/main Release Ign file: sid/contrib Release Ign file: sid/main/debian-installer Release Reading Package Lists... Building Dependency Tree... Adding the required directories to the binary CDs ... Generating the binary CD labels and their volume ids ... Current disk usage on the binary CDs (before the debs are added) : 1 CD1 Adding the selected packages to each CD : Missing debootstrap-required gcc-3.2-base CD1 missing some packages needed by debootstrap 1 ... cp: cannot stat `/org/alioth.debian.org/chroot/ftproot/pub/debian-amd64/pure64/indices/*': No such file or directory gunzip: /var/lib/gforge/chroot/home/users/kroeckx-guest/debian-cd/tmp/sid-amd64/indices/*.gz: No such file or directory done. dists/sid/main/binary-amd64/: New 20B 0 files 0B 0s dists/sid/contrib/binary-amd64/: New 20B 0 files 0B 0s Done Packages, Starting contents. Done. 0B in 0 archives. Took 0s dists/sid/main/debian-installer/binary-amd64/: New 20B 0 files 0B 0s Done Packages, Starting contents. Done. 0B in 0 archives. Took 0s It's trying to use gcc-3.2-base? I guess this is caused by an old version of debootstrap? I'm currently trying to do this on alioth. Is this a problem that I'm trying to build it on an other arch than what the patckage is for? I currently don't have access to a machine with a mirror on it and that has all the required packages installed. But I can ask to install it and that shouldn't be a problem. Can someone say what I need to do to get all this fixed? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256738: rootskel: amd64 support.
Package: rootskel Version: 0.78 Tags: patch Could you please apply the attached patch? This is required for amd64 to find it's linker. Kurt --- debian/rules.orig 2004-06-28 22:05:13.996244951 +0200 +++ debian/rules2004-06-28 22:04:08.413811353 +0200 @@ -26,6 +26,9 @@ dh_testroot $(MAKE) install +ifeq ($(shell dpkg-architecture -qDEB_BUILD_ARCH),amd64) + ln -s lib debian/rootskel/lib64 +endif binary-indep: build install
Bug#255264: SiI sata controller.
Package: discover1-data Version: 1.2004.02.08-7 I had someone report that d-i didn't autodetect his sata controller but he was able to manually modprobe sata_sil and then it worked for him. Output of lspci -n: :03:0b.0 Class 0180: 1095:3114 (rev 02) I'm not really sure which version of discover he got but his initial report was from the 13th of june. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New amd64 Debian-installer cdrom iso image
On Tue, Jun 15, 2004 at 07:43:36AM +0200, Harald Dunkel wrote: The image is available from: (ETA 45m) http://debian-amd64.alioth.debian.org/install-images/sid-amd64-cdrom.iso 286a2279babf50bd09bf6427248e2efa 102871040 sid-amd64-cdrom.iso This host seems to be unresponsive. Maybe its overloaded? http://www.be.kernel.org/amd64/alioth/install-images/ doesn't work anymore. And on the usual Please note that www.be.kernel.org points to more than 1 server and only one of them has it. The url you should be using if you want to use that mirror is: bytekeeper.as28747.net/amd64/alioth/install-images/ There is also an other mirror on: bach.hpc2n.umu.se/install-images/ Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#254059: elilo is also available on i386.
Package: elilo-installer Version: 0.0.4 Severity: important The elilo packages is available for i386 and ia64, the elilo-installer is only available for ia64. elilo-installer should also be available for i386. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#254059: elilo is also available on i386.
On Sat, Jun 12, 2004 at 09:04:13PM +0200, Bastian Blank wrote: On Sat, Jun 12, 2004 at 08:25:43PM +0200, Kurt Roeckx wrote: The elilo packages is available for i386 and ia64, the elilo-installer is only available for ia64. elilo-installer should also be available for i386. Is it usable? Do we need it? You should probably talk to the elilo maintainer (CC'd him) about that. He probably knows more about it. I only only saw the difference. Anyway, I've been told that efi bios's will likely be more used in the feature. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New amd64 Debian-installer cdrom iso image
On Thu, Jun 10, 2004 at 09:34:59PM +0200, Kurt Roeckx wrote: On Thu, Jun 10, 2004 at 02:15:33PM -0400, Joey Hess wrote: If you would build those using the installer/build/daily-build script, then I could add them to the build tracking page (http://people.debian.org/~joeyh/d-i/build-logs.html). It's now available from: http://debian-amd64.alioth.debian.org/debian-installer/daily On the status page it says: businesscard CD: Unavailable netinst CD: working netboot: Building hd-media: Building How do you make a businesscard CD? Why are those two in state building? They're available on the site. Is it a problem that they're in the 2.6 dir? How do we mark something as working? And how did netinst get into that state? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New amd64 Debian-installer cdrom iso image
On Thu, Jun 10, 2004 at 12:47:42PM -0400, Joey Hess wrote: The image is available from: (ETA 45m) http://debian-amd64.alioth.debian.org/install-images/sid-amd64-cdrom.iso I don't see a businesscard CD st that link, just a netinst. Do you plan to make other images bseides CDs available? Maybe hd-media or something? The ports status page has been updated. The d-i images I build are available at: http://debian-amd64.alioth.debian.org/debian-installer/current/images/ Those are the real d-i images as build by the debian-installer package. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New amd64 Debian-installer cdrom iso image
On Thu, Jun 10, 2004 at 02:15:33PM -0400, Joey Hess wrote: If you would build those using the installer/build/daily-build script, then I could add them to the build tracking page (http://people.debian.org/~joeyh/d-i/build-logs.html). It's now available from: http://debian-amd64.alioth.debian.org/debian-installer/daily Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253049: kbd-chooser: keyboard for amd64.
Package: kbd-chooser Version: 0.54 Tags: patch Could you please apply the attached patch, so that we actually have keyboard we can select on amd64? (Is there anything else that needs to be done?) Kurt --- Makefile.orig 2004-06-06 23:27:48.855928482 +0200 +++ Makefile2004-06-06 23:24:49.232027242 +0200 @@ -28,6 +28,10 @@ CFLAGS += -DAT_KBD -DUSB_KBD KEYBOARDS := at usb endif +ifeq ($(ARCH),amd64) +CFLAGS += -DAT_KBD -DUSB_KBD +KEYBOARDS := at usb +endif ifeq ($(ARCH),ia64) CFLAGS += -DAT_KBD -DUSB_KBD KEYBOARDS := at usb
Bug#249688: busybox-cvs-floppy-udeb missing on amd64.
Package: busybox-cvs
Version: 20040507-3
Tags: patch
Could you please add amd64 to the architecture list in the
control file for busybox-cvs-floppy-udeb?
Kurt
--- debian/control.orig 2004-05-18 20:47:33.298519653 +
+++ debian/control 2004-05-18 20:47:42.703852331 +
@@ -67,7 +67,7 @@
on your Debian system is a very, very bad idea. You have been warned.
Package: busybox-cvs-floppy-udeb
-Architecture: i386
+Architecture: i386 amd64
Depends: ${shlibs:Depends}
Section: debian-installer
Priority: extra
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249360: grub-installer: missing amd64 support.
Package: grub-installer Version: 0.46 Tags: patch Could you please add amd64 to the arch list in the control for? --- debian/control.orig 2004-05-16 21:39:19.849049893 + +++ debian/control 2004-05-16 21:34:40.594713056 + @@ -7,7 +7,7 @@ Standards-Version: 3.6.1 Package: grub-installer -Architecture: i386 hurd-i386 +Architecture: i386 hurd-i386 amd64 Provides: bootable-system Depends: cdebconf-udeb, kernel-installer, created-fstab, di-utils-mapdevfs, os-prober XB-Installer-Menu-Item: 73 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249363: netcfg: missing amd64 support.
Package: netcfg
Version: 0.63
Tags: patch
Could you please add amd64 to the arch list in the control file?
Kurt
--- debian/control.orig 2004-05-16 21:47:44.371480377 +
+++ debian/control 2004-05-16 21:48:02.951181690 +
@@ -8,7 +8,7 @@
Package: netcfg
XC-Package-Type: udeb
-Architecture: i386 sparc alpha m68k arm powerpc mips mipsel hppa ia64
+Architecture: i386 sparc alpha m68k arm powerpc mips mipsel hppa ia64 amd64
Depends: ${shlibs:Depends}, cdebconf-udeb, dhcp-client-udeb | pump-udeb |
busybox-cvs-udeb | busybox-cvs-net-udeb, ethernet-card-detection, libiw27-udeb
Provides: configured-network
XB-Installer-Menu-Item: 18
@@ -21,7 +21,7 @@
Package: netcfg-dhcp
XC-Package-Type: udeb
-Architecture: i386 sparc alpha m68k arm powerpc mips mipsel hppa ia64
+Architecture: i386 sparc alpha m68k arm powerpc mips mipsel hppa ia64 amd64
Depends: ${shlibs:Depends}, cdebconf-udeb, dhcp-client-udeb | pump-udeb |
busybox-cvs-udeb | busybox-cvs-net-udeb, ethernet-card-detection, libiw27-udeb
Provides: configured-network
XB-Installer-Menu-Item: 18
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249364: kbd-chooser: missing amd64 support.
Package: kbd-chooser
Version: 0.52
Tags: patch
Could you please add amd64 to the arch list in the control file?
Kurt
--- debian/control (revision 15517)
+++ debian/control (working copy)
@@ -6,7 +6,7 @@
Build-Depends: debhelper (= 4.1.16), libdebian-installer4-dev,
po-debconf (= 0.5.0), flex | flex-old , bison,
libdebconfclient0-dev (= 0.49)
Package: kbd-chooser
-Architecture: i386 ia64 hppa alpha sparc mips mipsel arm m68k powerpc
+Architecture: i386 ia64 hppa alpha sparc mips mipsel arm m68k powerpc amd64
XB-Installer-Menu-Item: 12
Depends: ${shlibs:Depends}, console-keymaps, archdetect
Description: Detect a keyboard and select layout
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-installer beta3 may detect SATA ide controllers automatically?
On Tue, Apr 20, 2004 at 12:11:54PM +0200, Pere Castañer wrote: Hi, I'm testing the beta3 of debian installer. I'm using a MSI KT6 Delta basesd on VIAKT600 chipset with VIA VT8237 chipset for raid and SATA. The debian installer don't detect any hdd, and the bios do it. I need to put the module manually? How? There exists a patch that should hopefully fix your problem. Pleae check that patch adds support for your controller. It seems to be added as vendor='1106' model='3149'. Output of lspci and lspci -n would be nice. See debian.org/cgi-bin/bugreport.cgi?bug=244470 Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
