Bug#852471: Dependency sddm, sddm-theme-maui | sddm-theme is to weak
Since the time of writing sddm get a new release in debian and some
dependencies are improved - second there are now some native debian sddm
theme packages.
So task-lxqt-desktop should be changed that way:
> diff --git a/debian/control b/debian/control
> index ef6a0a48..0d1faab2 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -187,14 +187,13 @@ Description: LXQt
> expect to have available on the desktop.
> Depends: ${misc:Depends},
> task-desktop,
> - sddm,
> - sddm-theme-maui | sddm-theme,
> + sddm-theme-debian-maui | sddm-theme,
> lxqt,
> Recommends: xsane,
> # orca works with qt, adding accessibility
> gnome-orca,
> # libreoffice widgets using just gtk
> - libreoffice-gtk2,
> + libreoffice-gtk3,
> # Package management.
> synaptic,
> # firefox (ne iceweasel) is the most popular web browser at the moment,
Bug#879686: fails to install on hercules
For the benefit of the s390 porters (whom I should have Cc'd on this from the very start): Unless I'm doing something terribly wrong, it appears that stretch (and later) don't install on the hercules s390 emulator anymore. Anyone have any clue what's wrong? On Tue, Oct 24, 2017 at 03:49:48PM +0200, Wouter Verhelst wrote: > Package: installation-reports > Severity: important > Tags: d-i > > > > -- Package-specific info: > > Boot method: hercules virtual card reader > Image version: daily build from 2017-10-23 > Date: > > Machine: Hercules > Partitions: > > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [O] > Detect network card:[O] > Configure network: [E] > Detect CD: [ ] > Load installer modules: [ ] > Clock/timezone setup: [ ] > User/password setup:[ ] > Detect hard drives: [ ] > Partition hard drives: [ ] > Install base system:[ ] > Install tasks: [ ] > Install boot loader:[ ] > Overall install:[ ] > > Comments/Problems: > > Based on the inwstructions at > http://josefsipek.net/docs/s390-linux/hercules-s390.html (which really > should find a home on the Debian wiki, but that as an aside) I created a > file "debian.cnf" with the following contents: > > -- > CPUSERIAL 69# CPU serial number > CPUMODEL 9672 # CPU model number > MAINSIZE 1024 # Main storage size in megabytes > XPNDSIZE 0 # Expanded storage size in megabytes > CNSLPORT 3270 # TCP port number to which consoles connect > NUMCPU4 # Number of CPUs > LOADPARM 0120 # IPL parameter > OSTAILOR LINUX # OS tailoring > PANRATE SLOW # Panel refresh rate (SLOW, FAST) > ARCHMODE ESAME # Architecture mode ESA/390 or ESAME > # console > 001F3270 > # terminal > 00093215 > # reader > 000C3505./rdr/kernel.debian ./rdr/parmfile.debian ./rdr/initrd.debian > autopad eof > # printer > 000E1403./prt/print00e.txt crlf > # dasd > 01203390./dasd/3390.LINUX.0120 > # tape > 05813420 > # network s390 realbox > 0A00,0A01 CTCI -n /dev/net/tun -t 1500 10.1.1.2 10.1.1.1 > > -- > > Next, I created a file "dasd/3390.LINUX.0120" with the following command: > > dasdinit -lfs -linux dasd/3390.LINUX.0120 3390-3 LIN120 8000 > > Next, I downloaded the "initrd.debian", "kernel.debian", and > "parmfile.debian" from the most recent successful d-i daily build. > > Finally, I started hercules like so: > > sudo hercules -f debian.cnf > > and entered the (hercules) command "ipl c". > > When the initrd, kernel, and parmfile are from a jessie install, this > works. When they are from stretch or later(!) however, it does not. The > kernel boots, and it seems to be doing a bit of initialization, but then > it stops at: > > [...] > 34.263205! Key type asymmetric registered > > > 35.059693! ctcm: CTCM driver initialized > > > Starting system log daemon: syslogd, klogd. > > > 1;24r 4l(B)0 m 1;24r H J 24;1H m > > > 1;24r 4l(B)0 m 1;24r H J 24;1H m > > > Configure the network device > > > > After this "Configure the network device", d-i *should* show the > template for me to select the network device type. It does not, however; > it just sits at the "Configure the network device" line. > > For comparison, on jessie that looks like this: > > [...] > 5.108239! ctcm: CTCM driver initialized > > > 5.115620! lcs: Loading LCS driver > > > Starting system log daemon: syslogd, klogd. > > > 1;24r 4l(B)0 m 1;24r H J 24;1H m > > >
Bug#869529: Missed file tasks/lxqt-desktop
Tests with the provided images: * debian-9.0+HACK-amd64-NETINST-1-with-provides.iso does the trick * tasksel show both LXDE and LXQt so this point is fixed * installation of both LXDE and LXQt went well, LXQt perfect, LXDE picked up lxqt-policykit somehow, possible not related to tasksel. Should be a different issue, will file a bug if analyzed it * with the unpatched tasksel LXDE picked up more or less LXQt packages, esp common and session - this behaviour is gone. I would give it a go, thank you KiBi
Re: some notes on util-linux takeover of eject
Michael Biebl (2017-10-26): > The debconf templates are of course translated. What I meant is that I > don't ship /usr/share/locale in the eject udeb. I think I misread gettext as debconf when I received your mail, and I really should have read it more thoroughly before replying. > Or is it important to be able to run the eject binary under a different > locale and have the output of the tool translated? Probably not, sorry for the noise on that topic. KiBi. signature.asc Description: PGP signature
Re: some notes on util-linux takeover of eject
Am 26.10.2017 um 16:59 schrieb Cyril Brulebois: > Hi, > > Michael Biebl (2017-10-24): >> It's actually smaller then the old eject-udeb as I didn't include the >> gettext translations. > > Why? OK this was late and maybe I wasn't clear on IRC, but keeping the > i18n + l10n part working is important. The debconf templates are of course translated. What I meant is that I don't ship /usr/share/locale in the eject udeb. Or is it important to be able to run the eject binary under a different locale and have the output of the tool translated? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#879814: apt: debian-installer FTBFS: missing syscalls for seccomp [mips,mipsel,ppc64el]
Cyril Brulebois (2017-10-26): > Following the bump from alpha1 to alpha2, the situation improved quite a > bit for the d-i daily builds (see #879662 for context). I've triggered a > manual build for all archs, and if my copying/pasting is correct, the > results are as follows: > > armel:alpha2, OK > armhf:alpha1, KO ← the apt alpha2 build came in late, wasn't > available yet. > arm64:alpha2, OK armhf is also confirmed OK with alpha2. KiBi. signature.asc Description: PGP signature
Re: Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]
Hi KiBi! Cyril Brulebois: > intrigeri (2017-10-25): >> I'm working on the last blockers towards starting the experiment I've >> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by >> default for a while in testing/sid. > Does it make sense to have it installed everywhere, including in > chroots, containers, etc., or should it be mainly installed in d-i > installed systems? It makes sense in any kind of system that runs its own Linux kernel: not in chroots & containers (there's WIP upstream for allowing containers to stack their own AppArmor policy on top of the host's one but we're not there yet), but definitely in systems installed by d-i (be it during initial installation or dist-upgrades, see the email I've just sent to -devel@ about the latter). >> Enabling AppArmor by default on new installations requires two >> changes: >> >> 1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with >>doing this in src:linux >> 2. install the apparmor package by default. > It seems it's built on non-Linux ports as well, does it make sense to > have it installed there? Please poke debian-bsd@ and debian-hurd@ if in > doubt. No, it doesn't make sense to install it there; it shouldn't harm either. So far I've kept src:apparmor building on non-Linux ports in the hope some portability issues turn out to be real bugs that affect Linux too, but this never happened. So if it simplifies the problem let's build the package only on Linux ports. >> My understanding is that making the apparmor package "Priority: >> standard" i the way to go. Correct? > Depends on the first question above. Replied. Anything else you need from me to answer this question? > Thanks for checking with us in any cases. :) No problem, I don't want to cause issues that could easily be prevented :) Cheers, -- intrigeri
Re: some notes on util-linux takeover of eject
Hi, Michael Biebl (2017-10-24): > It's actually smaller then the old eject-udeb as I didn't include the > gettext translations. Why? OK this was late and maybe I wasn't clear on IRC, but keeping the i18n + l10n part working is important. > But there is one complication: I noticed that eject in util-linux > currently linux only. > > If we made the udeb linux-any, how would this affect the installer? It might mean a regression on kfreebsd-* (I don't see an eject-udeb binary on hurd). I'm adding debian-bsd@ and debian-hurd@ in copy. > KiBi, is this a blocker in your opinion? While non-Linux issues aren't usually a blocker, I wouldn't welcome a gratuitous breakage there. I'll let porters comment first. The i18n/l10n part going away would be a blocker though. KiBi. signature.asc Description: PGP signature
Re: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]
Hi'ntrigeri, intrigeri (2017-10-25): > I'm working on the last blockers towards starting the experiment I've > proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by > default for a while in testing/sid. Does it make sense to have it installed everywhere, including in chroots, containers, etc., or should it be mainly installed in d-i installed systems? > Enabling AppArmor by default on new installations requires two > changes: > > 1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with >doing this in src:linux > 2. install the apparmor package by default. It seems it's built on non-Linux ports as well, does it make sense to have it installed there? Please poke debian-bsd@ and debian-hurd@ if in doubt. > This email is about (2). > > Priority: standard? > === > > My understanding is that making the apparmor package "Priority: > standard" i the way to go. Correct? Depends on the first question above. > The package itself has "Installed-Size: 1803 kB". > > I've trimmed the dependencies of this package a bit (just uploaded > 2.11.1-2 as a result) so it seems to be an OK thing to do to me. > The dependencies are now: > > libc6 (>= 2.17), > debconf (>= 0.5) | debconf-2.0, > python3:any, > lsb-base (>= 3.0-6), > debconf > > … i.e. only stuff that's installed by default already anyway. > > Would you folks have any problem with this change? > > Once this is done I'll coordinate with Ben wrt. pushing the other big > red button i.e. (1) once the other blockers have been resolved. Thanks for checking with us in any cases. :) KiBi. signature.asc Description: PGP signature
Bug#879755: debootstrap fails with current sid without apt-transport-https and https URLs
Hi Petr, Petr Cech (2017-10-25): > apt 1.6~alpha removed binary package apt-transport-https and therefor > debootstrap with a https URL fails with dependency error: > > I: Checking component main on https://deb.debian.org/debian... > E: Couldn't find these debs: apt-transport-https > > Following patch fixes it for current sid distribution. > > --- sid.orig2017-10-25 12:31:16.729013116 +0200 > +++ sid 2017-10-25 12:31:29.789138601 +0200 > @@ -35,7 +35,7 @@ > > case $MIRRORS in > https://*) > - base="$base apt-transport-https ca-certificates" > + base="$base ca-certificates" > ;; > esac > } I haven't implemented many changes to the sid script, but since there are a lot of symlinks pointing to it, I think this should be guarded with a check against the target suite. Not sure whether we should include apt-transport-https for an hardcoded list of suites, or exclude it for another list. Comments welcome. KiBi. signature.asc Description: PGP signature
Re: Missing uploads for d-i daily builds since 2017-10-13
FYI, a quick follow-up: Cyril Brulebois (2017-10-26): > On further investigation, it seems IPv6 addresses changed for both > machines. I've just modified dillon's configuration accordingly to > account for the native IPv6 addresses, and next builds should show > up again. It seems IPv6 assignments aren't final at the hoster, so I've forced IPv4 through ~/.ssh/config (following advice from Julien Cristau from the DSA team) on both falla and fischer. KiBi. signature.asc Description: PGP signature
Missing uploads for d-i daily builds since 2017-10-13
Hi, We've been missing d-i daily build uploads for kfreebsd-* since 2017-10-13: kibi@falla:/home/d-i/di/logs$ grep Permission\ denied.'*'publickey *201710* di-autobuild_daily-kfreebsd-amd64-20171013-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171014-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171015-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171018-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171023-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171024-:Permission denied (publickey). di-autobuild_daily-kfreebsd-amd64-20171026-0857:Permission denied (publickey). kibi@fischer:/home/d-i/di/logs$ grep Permission\ denied.'*'publickey *201710* di-autobuild_daily-kfreebsd-i386-20171013-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171014-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171015-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171016-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171018-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171021-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171022-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171024-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171026-:Permission denied (publickey). di-autobuild_daily-kfreebsd-i386-20171026-0857:Permission denied (publickey). At first I wasn't sure what caused this because I didn't change anything on dillon regarding authorized_keys (just checked: /etc/ssh/userkeys/d-i was last modified 2017-10-01), and dillon wasn't upgraded to stretch until a few days ago (2017-10-23). On further investigation, it seems IPv6 addresses changed for both machines. I've just modified dillon's configuration accordingly to account for the native IPv6 addresses, and next builds should show up again. KiBi.
Bug#879814: apt: debian-installer FTBFS: missing syscalls for seccomp [mips,mipsel,ppc64el]
Package: apt Version: 1.6~alpha2 Severity: serious Tags: d-i Justification: FTBFS [ X-D-Cc: debian-boot@, debian-mips@, debian-powerpc@ ] Hi, Following the bump from alpha1 to alpha2, the situation improved quite a bit for the d-i daily builds (see #879662 for context). I've triggered a manual build for all archs, and if my copying/pasting is correct, the results are as follows: armel:alpha2, OK armhf:alpha1, KO ← the apt alpha2 build came in late, wasn't available yet. arm64:alpha2, OK amd64:alpha2, OK i386: alpha2, OK mips: alpha2, Seccomp prevented execution of syscall 004117 on architecture mips mipsel: alpha2, Seccomp prevented execution of syscall 004117 on architecture mipsel mips64el: alpha2, OK powerpc: alpha2, OK ppc64el: alpha2, Seccomp prevented execution of syscall 000117 on architecture ppc64el s390x:alpha2, OK Porters: Julian mentioned it would be best if one could look at allowing extra syscalls through a config file[1], so as to detect other syscalls that might be needed as well (as it stands, the first offender triggers a failure, so we don't get a full list). 1. https://bugs.debian.org/879662#39 KiBi.
