Re: [debian-installer] Korean installation-guide PDF
Hi, Samuel Thibault wrote: > Hello, > > Changwoo, do you think you can come up with some simple change to let it > build on Stretch? We can probably make it conditional, so that it's only > the immediate builds which will be using the fonts from Stretch, and > further builds will use the fonts you picked up from Buster. It's just a matter of reverting the latest "Improve Korean pdf" changings and thus using WenQuanYi Micro Hei font again until Buster is out. Then, we can switch to the use of Noto * CJK KR font. Any objections against this solution path? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, Samuel Thibault wrote: > Hello, > > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > > >> "لاحقاً" > > > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > > > That avoids the issue here indeed. I however see it used in various > > > > > > Hmm. > > > There has been no changing in the ar.po of partman-auto > > > for 3 years now (JFTR), thus the real problem seems to be > > > sitting somewhere else ... > > > > How should we proceed here? > > Since we are late in the freeze, and it's most probably not that > > easy to find out what happened and what the real issue is: > > should we go with the "work-around" proposed by > > Butterflyoffire and confirmed to fix the issue by Samuel? > > Personally, I don't think I'll have the time to debug what is actually > happening inside gtk until the release, so even if it's ugly, I guess > the browntape fix is the least worst I can come up with. That looks fair. I have committed the proposed fix now. @butterflyoffire: could you please take a look at https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7 to double-check if the fix is fine by you? Thanks! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#925545: busybox: please provide runscript file
control: user ru...@packages.debian.org control: usertags -1 freeze [2019-06-16 00:20] Bastian Blank > Hi Dmitry Hi, Bastian > On Sat, Jun 15, 2019 at 06:37:03PM +, Dmitry Bogatov wrote: > > But, after all, we all volonteers here. So hereby I inform you, > > following advice in Developer reference, section 5.11, that I plan to > > do non-maintainer upload in two weeks or so. > > As we are before a release, NACK. Yes, we are. Upload to experimental would be nice, though. But if you prefer to wait for thaw, no problem -- I will come back after release. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930684: pbuilder: creation of build env fails when run inside Docker container
Tobias Junghans dixit:
>I tried to upgrade my Docker-based pbuilder containers from stretch to
Erm… why do you use chroots inside of chroots? That’s… tricky.
>mount: failed to read mtab: No such file or directory
This might be a container issue.
>mount: /proc: mount(2) system call failed: Too many levels of symbolic links.
Check if /proc outside of pbuilder but inside the container is right.
There also might be a /dev/shm vs. /run/shm issue. I recently had a
failure with these (one’s a mountpoint, the other a symbolic link to
it, either way works but it’s got to be consistent inside and out‐
side of the chroot) with schroot.
>the stretch-based pbuilder container and use it to build packages for buster.
Don’t.
But with {cow|p}builder --login --save-after-login you can
upgrade the base to buster inside pbuilder.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Processed: Re: Bug#930684: pbuilder: creation of build env fails when run inside Docker container
Processing control commands: > reassign -1 debootstrap 1.0.114 Bug #930684 [pbuilder] pbuilder: creation of build env fails when run inside Docker container Bug reassigned from package 'pbuilder' to 'debootstrap'. No longer marked as found in versions pbuilder/0.230.4. Ignoring request to alter fixed versions of bug #930684 to the same values previously set Bug #930684 [debootstrap] pbuilder: creation of build env fails when run inside Docker container Marked as found in versions debootstrap/1.0.114. > tag -1 - upstream Bug #930684 [debootstrap] pbuilder: creation of build env fails when run inside Docker container Removed tag(s) upstream. -- 930684: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930684 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#930684: pbuilder: creation of build env fails when run inside Docker container
Control: reassign -1 debootstrap 1.0.114 Control: tag -1 - upstream On Tue, Jun 18, 2019 at 01:49:27PM +, Tobias Junghans wrote: > I tried to upgrade my Docker-based pbuilder containers from stretch to > buster. However it appears that pbuilder and/or debootstrap do not work > properly inside Docker containers any longer due to issues with mounting > special filesystems such as proc and devpts. From your log it seems like it's debootstrap that is actually failing. I don't use docker and I don't really want to figure out how to try it, so I'll just bounce the ball to the debootstrap maintainers :) > The issue can be reproduced easily in a Debian Buster based container: > > # docker run --privileged -it debian:buster /bin/bash > > root@d81f634fe4a0:/# cat /proc/mounts > overlay / overlay > rw,relatime,lowerdir=/var/lib/docker/overlay2/l/TPOD4JNRBNCTMXNHYCY5XVRBQ3:/var/lib/docker/overlay2/l/TSD62UVCIJQ2LJ4XTUHKTVEK77,upperdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/diff,workdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/work > 0 0 > proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 > tmpfs /dev tmpfs rw,nosuid,size=65536k,mode=755 0 0 > devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 > 0 0 > sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 > tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0 > cgroup /sys/fs/cgroup/systemd cgroup > rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd > 0 0 > cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices > 0 0 > cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer > 0 0 > cgroup /sys/fs/cgroup/net_cls,net_prio cgroup > rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 > cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 > cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 > cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 > cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 > cgroup /sys/fs/cgroup/cpu,cpuacct cgroup > rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 > cgroup /sys/fs/cgroup/perf_event cgroup > rw,nosuid,nodev,noexec,relatime,perf_event 0 0 > mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0 > /dev/sdb /etc/resolv.conf ext4 rw,noatime,nodiratime,commit=300,data=ordered > 0 0 > /dev/sdb /etc/hostname ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 > /dev/sdb /etc/hosts ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 > shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0 > devpts /dev/console devpts > rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 > > root@d81f634fe4a0:/# apt-get update && apt-get -y --no-install-recommends > install pbuilder > > [...] > > root@d81f634fe4a0:/# pbuilder create --distribution buster > W: /root/.pbuilderrc does not exist > W: cgroups are not available on the host, not using them. > I: Distribution is buster. > I: Current time: Tue Jun 18 13:27:34 UTC 2019 > I: pbuilder-time-stamp: 1560864454 > I: Building the build environment > I: running debootstrap > /usr/sbin/debootstrap > I: Retrieving InRelease > I: Checking Release signature > I: Valid Release signature (key id 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC) > I: Retrieving Packages > I: Validating Packages > I: Resolving dependencies of required packages... > I: Resolving dependencies of base packages... > I: Checking component main on http://deb.debian.org/debian... > I: Retrieving libacl1 2.2.53-4 > I: Validating libacl1 2.2.53-4 > > [...] > > W: Failure trying to run: chroot "/var/cache/pbuilder/build/489" mount -t > proc proc /proc > W: See /var/cache/pbuilder/build/489/debootstrap/debootstrap.log for details > > [...] > > Setting up aptitude (0.8.11-7) ... > update-alternatives: using /usr/bin/aptitude-curses to provide > /usr/bin/aptitude (aptitude) in auto mode > Processing triggers for libc-bin (2.28-10) ... > I: Copying back the cached apt archive contents > I: new cache content 'aptitude-common_0.8.11-7_all.deb' added > I: new cache content 'libboost-iostreams1.67.0_1.67.0-13_amd64.deb' added > I: new cache content 'aptitude_0.8.11-7_amd64.deb' added > I: new cache content 'libsqlite3-0_3.27.2-3_amd64.deb' added > I: new cache content 'libxapian30_1.4.11-1_amd64.deb' added > I: new cache content 'libcwidget3v5_0.5.17-11_amd64.deb' added > I: new cache content 'libboost-system1.67.0_1.67.0-13_amd64.deb' added > I: new cache content 'libsigc++-2.0-0v5_2.10.1-2_amd64.deb' added > mount: failed to read mtab: No such file or directory > mount: failed to read mtab: No such file or directory > I: unmounting dev/pts filesystem > I: unmounting dev/shm filesystem > I: unmounting proc filesystem > I: unmounting sys filesystem > I: creating
Re: Specifying hostname as kernel boot parameter preseed file
On Tue, Jun 18, 2019 at 03:48:36PM +0200, john doe wrote:
> Hi,
>
> I'm trying to comprehend in which conditions the hostname and domain can
> be specified as kernel boot parameter:
> As far as I understand it there are three ways to specify a hostname/domain:
> - Kernel boot parameter (boot: hostname=)
> - By DHCP
> - Static hostname in a preseed file ('d-i netcfg/hostname string
>
> I use a common preseed file for the debian installer with the exception
> of the hostname that needs to be changed for eatch hosts.
> So for example I would do something like:
>
> boot: auto interface=auto url= hostname=try
>
> On the installed system the hostname is always sed to 'bad'.
>
> I would expect that 'hostname' in the above command would take
> precedence over other hostnames that are specified by other means (DHCP
> ...).
>
> What am I missing?
Yeah, good question.
> In other words: what is the best way to specify a hostname as kernel
> boot parameter.
I don't know.
Thing I want to tell is that I use sane configured DNS.
Somewhere in the installation process does d-i a reverse lookup
for hostname. For my setup does it get the hostname that I want
on the (to be) installed system.
Not a kernel boot parameter, d-i preseed is what does the trick for me.
Sorry for not being able to tell clearly and reproduceable how it works.
Groeten
Geert Stappers
--
Leven en laten leven
Specifying hostname as kernel boot parameter preseed file
Hi,
I'm trying to comprehend in which conditions the hostname and domain can
be specified as kernel boot parameter:
As far as I understand it there are three ways to specify a hostname/domain:
- Kernel boot parameter (boot: hostname=)
- By DHCP
- Static hostname in a preseed file ('d-i netcfg/hostname string hostname=try
On the installed system the hostname is always sed to 'bad'.
I would expect that 'hostname' in the above command would take
precedence over other hostnames that are specified by other means (DHCP
...).
What am I missing?
In other words: what is the best way to specify a hostname as kernel
boot parameter.
--
John Doe
Bug#930569: debian-installer: Dark theme installer selects MATE by default
On Tue, Jun 18, 2019 at 02:49:10PM +0200, Samuel Thibault wrote: >Steve McIntyre, le lun. 17 juin 2019 12:41:40 +0100, a ecrit: >> That's all OK, but it would be lovely to have some warning that "dark >> theme" is *meant* for the visually-impaired. I'd just seen this as an >> apparently arbitrary choice of different colours without that >> information... > >Ok, I have relabelled the choice. Cool, thanks. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Processed: tagging 930569
Processing commands for cont...@bugs.debian.org: > tags 930569 + pending Bug #930569 [rootskel] debian-installer: Dark theme installer selects MATE by default Ignoring request to alter tags of bug #930569 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 930569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930569 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930569: debian-installer: Dark theme installer selects MATE by default
Steve McIntyre, le lun. 17 juin 2019 12:41:40 +0100, a ecrit: > That's all OK, but it would be lovely to have some warning that "dark > theme" is *meant* for the visually-impaired. I'd just seen this as an > apparently arbitrary choice of different colours without that > information... Ok, I have relabelled the choice. Samuel
Processed: Bug#930569 marked as pending in debian-installer
Processing control commands: > tag -1 pending Bug #930569 [rootskel] debian-installer: Dark theme installer selects MATE by default Added tag(s) pending. -- 930569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930569 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#782287: PR updated
Hi, On Wed, 05 Sep 2018, Christian Ehrhardt wrote: > FYI - updated the salsa PR with a further simplification according to the > feedback of Scott Moser. I'm wondering if there's a way to tell d-i to also install openvm-tools-desktop if the user opts to install a graphical desktop afterwards... Otherwise I believe that this MR should be merged (and we should do the same for other virtualization technologies). I might take a stab at this... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#781783: marked as done (Add open-vm-tools when installing in a VMware VM)
Your message dated Tue, 18 Jun 2019 10:51:27 +0200
with message-id <20190618085127.ga6...@home.ouaza.com>
and subject line Re: Bug#781783: Add open-vm-tools when installing in a VMware
VM
has caused the Debian Bug report #781783,
regarding Add open-vm-tools when installing in a VMware VM
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
781783: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781783
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hw-detect
Version: 1.107
Attached are changes to add a utility that detects if we are running in a
VMware VM, and add open-vm-tools to the list of packages to be installed.
Please consider adding it to hw-detect.
Thanks,
Oliver
diff --git a/.gitignore b/.gitignore
index e2df58f..b53d8af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@ build-stamp
configure-stamp
archdetect
archdetect-deb
+checkvm
*.o
devnames-static.gz
diff --git a/Makefile b/Makefile
index 88a7582..ca5c70d 100644
--- a/Makefile
+++ b/Makefile
@@ -37,7 +37,7 @@ man1dir=$(DESTDIR)/usr/share/man/man1
INSTALL=install
INSTALL_DATA = ${INSTALL} -m 644
-all: archdetect devnames-static.gz
+all: checkvm archdetect devnames-static.gz
test:
set -e; for sh in *.sh; do sh -n $$sh; done
@@ -46,9 +46,10 @@ clean:
rm -f *~
rm -f *.o
rm -f archdetect
+ rm -f checkvm
rm -f devnames-static.gz
-install: install-hw-detect install-ethdetect install-disk-detect install-driver-injection-disk-detect install-archdetect install-archdetect-deb
+install: install-hw-detect install-ethdetect install-disk-detect install-driver-injection-disk-detect install-archdetect install-archdetect-deb install-checkvm
install-hw-detect: hw-detect.sh
$(INSTALL) -d $(bindir)
@@ -79,6 +80,12 @@ endif
else
$(INSTALL) detect-stub.sh $(bindir)/hw-detect
endif
+ifeq ($(DEB_HOST_ARCH),i386)
+ $(INSTALL) checkvm $(bindir)
+endif
+ifeq ($(DEB_HOST_ARCH),amd64)
+ $(INSTALL) checkvm $(bindir)
+endif
install-ethdetect: ethdetect.sh
$(INSTALL) -d $(bindir) $(netdir)
@@ -97,6 +104,7 @@ install-archdetect: archdetect
$(INSTALL) -d $(bindir)
$(INSTALL) archdetect $(bindir)
+
install-archdetect-deb: archdetect
$(INSTALL) -d $(bindir)
$(INSTALL) archdetect $(bindir)
@@ -109,5 +117,11 @@ archdetect: archdetect.o
archdetect.o: %.o:%.c
$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_ARCH) -c $<
+checkvm: checkvm.o
+ ${CC} ${LDFLAGS} -o $@ $^
+
+checkvm.o: %.o:%.c
+ $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_ARCH) -c $<
+
devnames-static.gz: devnames-static.txt
grep -v '^#' $< | gzip -9c > $@
diff --git a/checkvm.c b/checkvm.c
new file mode 100644
index 000..5e017b0
--- /dev/null
+++ b/checkvm.c
@@ -0,0 +1,146 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define OC_CPU_X86_MMX (1<<0)
+#define OC_CPU_X86_3DNOW(1<<1)
+#define OC_CPU_X86_3DNOWEXT (1<<2)
+#define OC_CPU_X86_MMXEXT (1<<3)
+#define OC_CPU_X86_SSE (1<<4)
+#define OC_CPU_X86_SSE2 (1<<5)
+#define OC_CPU_X86_PNI (1<<6)
+#define OC_CPU_X86_SSSE3(1<<7)
+#define OC_CPU_X86_SSE4_1 (1<<8)
+#define OC_CPU_X86_SSE4_2 (1<<9)
+#define OC_CPU_X86_SSE4A(1<<10)
+#define OC_CPU_X86_SSE5 (1<<11)
+#define OC_CPU_PPC_ALTIVEC (1<<12)
+
+
+typedef unsigned int ogg_uint32_t;
+
+#if defined(i386) || defined(__x86_64__) || defined(_M_IX86) || defined(_M_AMD64)
+# if !defined(_MSC_VER)
+# if defined(__amd64__)||defined(__x86_64__)
+/*On x86-64, gcc seems to be able to figure out how to save %rbx for us when
+ compiling with -fPIC.*/
+# define cpuid(_op,_eax,_ebx,_ecx,_edx) \
+ __asm__ __volatile__( \
+ "cpuid\n\t" \
+ :[eax]"=a"(_eax),[ebx]"=b"(_ebx),[ecx]"=c"(_ecx),[edx]"=d"(_edx) \
+ :"a"(_op) \
+ :"cc" \
+ )
+# else
+/*On x86-32, not so much.*/
+# define cpuid(_op,_eax,_ebx,_ecx,_edx) \
+ __asm__ __volatile__( \
+ "xchgl %%ebx,%[ebx]\n\t" \
+ "cpuid\n\t" \
+ "xchgl %%ebx,%[ebx]\n\t" \
+ :[eax]"=a"(_eax),[ebx]"=r"(_ebx),[ecx]"=c"(_ecx),[edx]"=d"(_edx) \
+ :"a"(_op) \
+ :"cc" \
+ )
+# endif
+# endif
+# endif
+
+int cpuid_check()
+{
+ ogg_uint32_t eax;
+ ogg_uint32_t ebx;
+ ogg_uint32_t ecx;
+ ogg_uint32_t edx;
+char hyper_vendor_id[13];
+
+cpuid(0x1, eax, ebx, ecx, edx);
+//if (bit 31 of ecx is set) {
+ if (ecx & (1 << 30)) {
+cpuid(0x4000, eax, ebx, ecx, edx);
+memcpy(hyper_vendor_id + 0, , 4);
+memcpy(hyper_vendor_id + 4, , 4);
+memcpy(hyper_vendor_id + 8, , 4);
+hyper_vendor_id[12] = '\0';
+if
