Bug#858159: [installation-guide] Memory requirements for installing Stretch have increased since Jessie
On 8/24/18 11:28 PM, Holger Wansing wrote: > Noone commented on this, so I assume we have a consense here, to leave > everything > as is. > So closing this bug. Well, I don't mind that much. All I wanted to say is that a headless barebone installation works fine with as little as 128 MiB of RAM. However, the mileage may vary depending on the applications being used, of course. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#858159: marked as done (Memory requirements for installing Stretch have increased since Jessie)
Your message dated Fri, 24 Aug 2018 23:28:51 +0200 with message-id <20180824232851.10b52aef2997b66270ce1...@wansing-online.de> and subject line Re: Bug#858159: [installation-guide] Memory requirements for installing Stretch have increased since Jessie has caused the Debian Bug report #858159, regarding Memory requirements for installing Stretch have increased since Jessie 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.) -- 858159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858159 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: www.debian.org Severity: normal Chapter 3.4 of the Installation Guide for Stretch is out of date with regard to RAM requirements. Through trial and error, I determined the following: Install Type| RAM (minimum) | RAM (recommended) | Hard Drive No desktop | 256 megabytes | 1 gigabyte| 2 gigabytes With desktop| 768 megabytes | 1 gigabyte| 10 gigabytes --- End Message --- --- Begin Message --- Hi, Holger Wansing wrote: > Hi, > > John Paul Adrian Glaubitz wrote: > > > > > > > On Aug 3, 2018, at 9:26 PM, Holger Wansing > > > wrote: > > > > > > Since desktop environments like Gnome and KDE still move forward and add > > > new features, it seems likely to me, that memory requirements could change > > > over 4 years. > > > > That doesn’t necessarily mean they need more RAM. KDE5 has been seriously > > improved over KDE4 when it comes to performance. So even here you probably > > need less memory now. Don’t know about GNOME though. > > > > > In Jessie and Stretch, we have > > >With desktop| 256 megabytes | 1 gigabyte| 10 gigabytes > > > > > > What do people think about doubling the minimum value from > > > 256 to 512 megabytes at least? > > > (Since Gnome is the default desktop, we should choose values here, that > > > will > > > work almost for Gnome. Orienting on LXDE or Xfce is probably not the right > > > thing ...) > > > > Did you do some testing inside a VM with different memory configurations to > > get some data points? > > That's what the OP of this bug did, right? > I just tried to push things forward ... > > > Just bumping the numbers because we haven’t done so for a while makes them > > less meaningful, in my opinion. > > That sounds also reasonable, yes. > > > Holger Noone commented on this, so I assume we have a consense here, to leave everything as is. So closing this bug. Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/ --- End Message ---
Re: RfC: New LVM volume size restriction prompt
Hi, Holger Wansing wrote: > > Another glitch is, that one string > > ---snip- > > #. Type: string > > #. Description > > #. :sl3: > > #: ../partman-auto-lvm.templates:11001 > > #, no-c-format > > msgid "" > > "Hint: \"max\" can be used as a shortcut to specify the maximum size, or " > > "enter a percentage (e.g. \"20%\") to use that percentage of the maximum > > size." > > msgstr "" > > snap-- > > is not synced to translators material at all. > > Don't know why ATM. > > We will see this evenning, what l10n-sync does now ... This is still a problem. The string mentioned above is still not synced correctly to translators material. (I have ran l10n-sync without --commit option, otherwise it would have removed that string from translators material, where I have added it by hand this morning.) Something weird is going on ... Will have to investigate. Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)
On Tue, 21 Aug 2018 12:37:00 +0200 Raphael Hertzog wrote: > While cleaning up the list of scripts to keep, you decided to drop the > scripts for all derivatives making it impossible to use the udeb built > for Debian on any derivative (Kali bug report here: > https://bugs.kali.org/view.php?id=4921) It was not correct assumptions that derivatives use it own udeb packages, my apologies. > So you saved a few kilobytes and made the life harder for others. > IMO it was the wrong decision. It was my mistake, of course, but I DON'T WANT TO MAKE SOMEONE'S LIFE ANY HARDER, IT IS NOT INTENDED. People who made wrong decision should be blamed as fool? If so, please revert debootstrap before I started to commit to it. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#902567: tasksel: Please remove occurrences of "kdesudo" and coordinate with d-i
Hi,
Boyuan Yang <073p...@gmail.com> wrote:
> Control: tags -1 + patch
> Control: forwarded -1
> https://salsa.debian.org/installer-team/tasksel/merge_requests/3
> X-Debbugs-CC: hwans...@mailbox.org
>
> Dear tasksel maintainers,
>
> I have prepared a patch (Merge Request) on Debian Salsa to solve this bug.
> Please review it and merge it if you find it acceptable.
>
> The d-i package (user-setup) is no longer using kdesudo thus this dependency
> can
> be removed safely.
Anyone objections against this ?
Holger
>
> --
> Thanks,
> Boyuan Yang
>
> On Thu, 28 Jun 2018 10:35:42 +0800 Boyuan Yang <073p...@gmail.com> wrote:
> > Source: tasksel
> > Version: 3.44
> > Severity: important
> > X-Debbugs-CC: debian-boot@lists.debian.org
> >
> > Dear d-i developers and tasksel maintainers,
> >
> > Package "kdesudo" has been removed in Debian since September 2017.
> >
> > Tasksel still recommends non-existent "kdesudo" in task-kde-desktop. Please
> > consider removing this entry from "Recommends: " field.
> >
> > However, I noticed the following lines in debian/control:
> >
> >
> > Package: task-kde-desktop
> > Architecture: all
> > Description: KDE
> > This task package is used to install the Debian desktop, featuring
> > the KDE desktop environment, and with other packages
> > that Debian users
> > expect to have available on the desktop.
> > Depends: ${misc:Depends},
> > task-desktop,
> > kde-standard,
> > sddm,
> > Recommends:
> > [...]
> >
--
Created with Sylpheed 3.5.1 under
D E B I A N L I N U X 9 " S T R E T C H " .
Registered Linux User #311290 - https://linuxcounter.net/
Bug#907189: busybox-syslogd: Please provide systemd .service files (attached)
Package: busybox-syslogd Version: 1:1.22.0-19 Tags: patch Please add systemd .service files to busybox-syslogd. The attached files are taken from OpenEmbedded and seem to work on my embedded device on Debian 9. Thanks in advance! References: https://raw.githubusercontent.com/dirtybit/gumstix-yocto/master/meta-openembedded/meta-oe/recipes-core/busybox/busybox/busybox-syslog.service.in https://git.congatec.com/yocto/meta-openembedded/raw/c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1/meta-oe/recipes-core/busybox/busybox/busybox-syslog.service.in https://raw.githubusercontent.com/dirtybit/gumstix-yocto/master/meta-openembedded/meta-oe/recipes-core/busybox/busybox/busybox-klogd.service.in https://git.congatec.com/yocto/meta-openembedded/raw/c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1/meta-oe/recipes-core/busybox/busybox/busybox-klogd.service.in [Unit] Description=System Logging Service Wants=busybox-klogd.service [Service] EnvironmentFile=-/etc/default/busybox-syslogd ExecStart=/sbin/syslogd -n $OPTIONS Sockets=syslog.socket [Install] WantedBy=multi-user.target Also=busybox-klogd.service [Unit] Description=Kernel Logging Service [Service] ExecStart=/sbin/klogd -n [Install] WantedBy=multi-user.target
Re: RfC: New LVM volume size restriction prompt
On 2018-08-24 14:29, Holger Wansing wrote: Holger Wansing wrote: Philipp Kern wrote: > I have uploaded it now. I suppose we can still fix it after the fact if > it's wrong. I have triggered a l10n-sync run on dillon, to sync the new strings to the translators material. And sadly it did not work as expected: the l10n-sync script apparently does not assume, that translations are inserted into the po files in the partman-auto-lvm tree. Its assumptions are: 1. the english phrases are inserted by the package maintainer into the package tree (in this case partman-auto-lvm tree), and are synced by the l10n-sync script to the po/sublevelx structure in https://salsa.debian.org/installer-team/d-i/commits/master which is the material, translators are working on. 2. Then the translated phrases are added (from the translators) to the po/sublevelx structure and are later synced back to the partman-auto-lvm tree. Means we have no translated strings at the moment in GIT :-( I fixed that now manually (hopefully everything is correct). [...] We will see this evenning, what l10n-sync does now ... Thanks! (And sorry for the hassle.) Kind regards Philipp Kern
Bug#906696: flash-kernel: Please add an entry for the Rock64
Hello, Missatge de Josua Mayer del dia dg., 19 d’ag. 2018 a les 22:00: > There is a vendor u-boot available based on 2017.09. It fully supports distro > boot and > loading EFI applications. Do you happen to know what's missing in the Debian u-boot package to be usable in that board? > Therefore the rock64 can be booted with grub-arm-efi. Great! > Only one important thing has to be dealt with: Getting the DTB loaded by > U-Boot! > U-Boot searches for rockchip/rk3328-rock64.dtb in /, /dtb/, /dtb/current on > the EFI partition. > > The attached db entry takes care ot this particular path by storing it at > /boot/efi/dtb/rockchip/rk3328-rock64.dtb. This is with vendor u-boot instead Debian u-boot, right? > Other rockchip boards supported by mainline u-boot omit the rockchip > subdirectory and just search for the dtb name. > However there is no support for the rock64 in mainline u-boot so I think > carrying this weird prefix is acceptable. Not sure I agree on that. Is someone working on mainline u-boot to support rock64? > Currently most used and best documented source for rock64 U-Boot: > https://github.com/ayufan-rock64/linux-u-boot/releases > > u-boot-erase-spi-rock64.img.xz can be used to flash u-boot to SPI flash once; > from then on everything is standard: > - debootstrap > - linux-image-arm64 > - grub-arm-efi > - grub-install --target=arm-efi --removable > > Yours sincerely > Josua Mayer > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: arm64 (aarch64) > > Kernel: Linux 4.17.0-1-arm64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages flash-kernel depends on: > ii debconf [debconf-2.0] 1.5.69 > ii devio 1.2-1.2+b1 > ii initramfs-tools0.132 > ii linux-base 4.5 > ii mtd-utils 1:2.0.1-1 > ii ucf3.0038 > > Versions of packages flash-kernel recommends: > ii u-boot-tools 2018.05+dfsg-1 > > flash-kernel suggests no packages. > > -- Configuration Files: > /etc/flash-kernel/db changed: > Machine: Pine64 Rock64 > Boot-DTB-Path: /boot/efi/rockchip/rk3328-rock64.dtb > DTB-Id: rockchip/rk3328-rock64.dtb > > > -- debconf information excluded -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: RfC: New LVM volume size restriction prompt
Hi, Holger Wansing wrote: > Philipp Kern wrote: > > I have uploaded it now. I suppose we can still fix it after the fact if > > it's wrong. > > I have triggered a l10n-sync run on dillon, to sync the new strings to > the translators material. > And sadly it did not work as expected: the l10n-sync script apparently does > not assume, that translations are inserted into the po files in the > partman-auto-lvm tree. > > Its assumptions are: > 1. > the english phrases are inserted by the package maintainer into the package > tree (in this case partman-auto-lvm tree), and are synced by the l10n-sync > script to the po/sublevelx structure in > https://salsa.debian.org/installer-team/d-i/commits/master > which is the material, translators are working on. > 2. > Then the translated phrases are added (from the translators) to the > po/sublevelx structure and are later synced back to the partman-auto-lvm > tree. > > Means we have no translated strings at the moment in GIT :-( I fixed that now manually (hopefully everything is correct). > Another glitch is, that one string > ---snip- > #. Type: string > #. Description > #. :sl3: > #: ../partman-auto-lvm.templates:11001 > #, no-c-format > msgid "" > "Hint: \"max\" can be used as a shortcut to specify the maximum size, or " > "enter a percentage (e.g. \"20%\") to use that percentage of the maximum > size." > msgstr "" > snap-- > is not synced to translators material at all. > Don't know why ATM. We will see this evenning, what l10n-sync does now ... Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
