Re: What's the deal with discover*? (was: Processed: pending since 2013?)
[Cyril Brulebois] > Hi, Hi. > It seems a "VCS" word was missing in my earlier mail. Knowing where > the code lives for both discover and discover-data (so we can update > them, see ongoing changes) and whether debian-boot@ is really meant to > be the maintainer were my initial questions. Aha. They live in the same svn repository. I just commited these links to discover/debian/control: Vcs-Svn: svn://svn.debian.org/pkg-discover/discover/trunk Vcs-Browser: http://svn.debian.org/wsvn/pkg-discover/discover/trunk/ > It's probably a good idea to consider such a move, but I'd rather > concentrate on updating discover* for the non-free/firmware thing > first. What does the "non-free/firmware thing" mean? Perhaps I can help to fix it? Is the problem better solved by isenkram? > I'm making a note locally (but my to do list is ever-growing), but > feel free to file a bug report against src:debian-installer or > d-i.debian.org (where I keep infrastructure-related and cross-packages > bug reports) to make sure it's easily found by others. I am planning to commit the fixes myself, so you do not need to keep it on your long todo list. :) -- Happy hacking Petter Reinholdtsen
Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding
Hi Raphael, BTW would you happen to know if the example for checksums on CDs is relevant any more? - if you're booting a remastered CD: preseed/file=/cdrom/preseed.cfg preseed/file/checksum=5da499872becccfeda2c4872f9171c3d which is supposedly an example where one might specify the checksum for the CD's preseed.cfg -- it strikes me that a) this is a bit pointless (although it would catch corruption of the media), and b) it presumably doesn't work any more, because that file will already have been used by the time we get to the kernel parameters. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#810301: technical reason for "merged /usr support" in debootstrap
Le Sun, Jan 10, 2016 at 06:43:27AM +0100, Christian PERRIER a écrit : > Quoting Geert Stappers (stapp...@stappers.nl): > > > * No pointers to the discussion in the opening of this B.R. > > There's a lengthy discussion in -devel and this issue about merged > /usr is something I see floting around for years. > > Random picks in the said discussion seem to show a quite good agreement. Hello everybody, I read aproximately three quarters of the thread, plus some of the reference documentation, and I agree that there is altogether a good agreement and that objections are adequately answered. Moreover, the patch set discussed here introduces the option "--no-merged-usr" to keep the old behaviour of debootstrap. So I think that Geert's objections are either answered or not valid. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: [PATCH 0/3] Add sparc64 support to base-installer
Hello Michael! On 01/10/2016 04:26 AM, Martin Michlmayr wrote: > Thanks, I committed both patches. In the future, please modify > debian/changelog in each commit (if there's something to add to the > changelog) rather than as one standalone commit. Thank you very much for your help! I will keep your suggestion regarding the changelog in mind. Thanks, 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#810301: technical reason for "merged /usr support" in debootstrap
On Sun, Jan 10, 2016 at 09:25:43PM +0900, Charles Plessy wrote: > > So I think that Geert's objections are either answered or not valid. > My objections were based on not knowing _why_ the change is needed. I assumed a repair, meanwhile I understand it is about creating a possiblity, a doorway to something new. I'll see what it will bring me. Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Re: What's the deal with discover*? (was: Processed: pending since 2013?)
Hi, Petter Reinholdtsen (2016-01-10): > Aha. They live in the same svn repository. I just commited these links > to discover/debian/control: > > Vcs-Svn: svn://svn.debian.org/pkg-discover/discover/trunk > Vcs-Browser: http://svn.debian.org/wsvn/pkg-discover/discover/trunk/ I don't understand why the maintainer is said to be debian-boot@ if the code is in svn, rather than git; and under the pkg-discover group, rather than the d-i one… > > It's probably a good idea to consider such a move, but I'd rather > > concentrate on updating discover* for the non-free/firmware thing > > first. > > What does the "non-free/firmware thing" mean? Perhaps I can help to fix > it? Is the problem better solved by isenkram? See https://lists.debian.org/debian-devel/2016/01/msg00352.html Given your previous mail, I doubt isenkram is going to help. > > I'm making a note locally (but my to do list is ever-growing), but > > feel free to file a bug report against src:debian-installer or > > d-i.debian.org (where I keep infrastructure-related and > > cross-packages bug reports) to make sure it's easily found by > > others. > > I am planning to commit the fixes myself, so you do not need to keep it > on your long todo list. :) This paragraph was meant for the “consider such a move” discussion (to make sure it happens at some point), not for discover fixes, which should be tracked in bug reports against src:discover(-data). Mraw, KiBi. signature.asc Description: Digital signature
Re: What's the deal with discover*?
[Cyril Brulebois] > I don't understand why the maintainer is said to be debian-boot@ if > the code is in svn, rather than git; and under the pkg-discover group, > rather than the d-i one… In short, historical reasons from before your time. :) The packages discover and discover-data were taken under the wings of debian-boot@ when Proginy stopped maintaining it, as it was the best option to ensure a good installation experience in Debian due to its excellent ability to map hardware to kernel modules and packages. But no-one took the time to migrate the svn repo from its existing one to the d-i one, and I guess it was forgotten when d-i migrated from subversion to git. Note, building discover is a bit painful, and could use some work to make it easier to maintain. > See https://lists.debian.org/debian-devel/2016/01/msg00352.html > > Given your previous mail, I doubt isenkram is going to help. Well, isenkram have the /usr/sbin/isenkram-autoinstall-firmware script to handle firmware packages, and it could be a good replacement. It is using the equivalent of a 'apt-file search /lib/firmware/' to locate packages with firmware in them. As far as I know, discover isn't used to find firmware packages any more, so updates for discover seem irrelevant regarding the introduction of a non-free-firmware section. The firmware handling is done by hw-detect. I can probably help to get it updated to use the new section, which seem like a very good idea to get computers working without having to enable the entire non-free APT source. One thing that would help a lot is to get the firmware packages to announce their firmware using appstream metadata. This would make it a lot easier to locate the correct firmware package, and would help both isenkram and all others interested in operating on firmware data. >>> I'm making a note locally (but my to do list is ever-growing), but >>> feel free to file a bug report against src:debian-installer or >>> d-i.debian.org (where I keep infrastructure-related and >>> cross-packages bug reports) to make sure it's easily found by >>> others. >> >> I am planning to commit the fixes myself, so you do not need to keep it >> on your long todo list. :) > > This paragraph was meant for the “consider such a move” discussion (to > make sure it happens at some point), not for discover fixes, which > should be tracked in bug reports against src:discover(-data). The fixes I had in mind was in hw-detect, which has the d-i code using discover today. But you are right, we should weed out the details first. :) I guess I should start following debian-boot@ if we are going to do that, as I am not following it today. Too many emails and too little time to read them. :) -- Happy hacking Petter Reinholdtsen
Re: What's the deal with discover*?
Hi, Petter Reinholdtsen (2016-01-10): > In short, historical reasons from before your time. :) > > The packages discover and discover-data were taken under the wings of > debian-boot@ when Proginy stopped maintaining it, as it was the best > option to ensure a good installation experience in Debian due to its > excellent ability to map hardware to kernel modules and packages. But > no-one took the time to migrate the svn repo from its existing one to > the d-i one, and I guess it was forgotten when d-i migrated from > subversion to git. > > Note, building discover is a bit painful, and could use some work to > make it easier to maintain. So the question becomes: should they be moved to git? Keeping the manual as a special snowflake leaving under d-i's svn is OK (mostly to avoid translators' having to learn about a new tool), but keeping debian-boot maintained packages under a different scm under a different group seems a bad idea. > Well, isenkram have the /usr/sbin/isenkram-autoinstall-firmware script > to handle firmware packages, and it could be a good replacement. It is > using the equivalent of a 'apt-file search /lib/firmware/' to locate > packages with firmware in them. > > As far as I know, discover isn't used to find firmware packages any > more, so updates for discover seem irrelevant regarding the introduction > of a non-free-firmware section. The firmware handling is done by > hw-detect. I can probably help to get it updated to use the new > section, which seem like a very good idea to get computers working > without having to enable the entire non-free APT source. Right, for some reason I got hw-detect and discover confused. Maybe because you recently were involved with patching hw-detect. :D > One thing that would help a lot is to get the firmware packages to > announce their firmware using appstream metadata. This would make it a > lot easier to locate the correct firmware package, and would help both > isenkram and all others interested in operating on firmware data. I don't know a lot about appstream metadata, but I mentioned during the BoF we could just embed a fw file→fw package mapping at build time to ease lookup (basically what you're doing with apt-file, except we would have a static list in the d-i image; for one thing, there's no guarantee network is available at early stages to query Contents from mirrors). Mraw, KiBi. signature.asc Description: Digital signature
Bug#810301: technical reason for "merged /usr support" in debootstrap
Geert Stappers writes: > On Sun, Jan 10, 2016 at 09:25:43PM +0900, Charles Plessy wrote: >> >> So I think that Geert's objections are either answered or not valid. >> > > My objections were based on not knowing _why_ the change is needed. > I assumed a repair, meanwhile I understand it is about creating a possiblity, > a doorway to something new. I'll see what it will bring me. Well done for being reasonable. Thank you, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What's the deal with discover*?
[Cyril Brulebois] > So the question becomes: should they be moved to git? Keeping the manual > as a special snowflake leaving under d-i's svn is OK (mostly to avoid > translators' having to learn about a new tool), but keeping debian-boot > maintained packages under a different scm under a different group seems > a bad idea. If someone got the time to do so, I believe that would be a good thing to do. But my recommondation would be to switch to isenkram-cli with appstream as the data souce and ask for the removal of discover. > I don't know a lot about appstream metadata, but I mentioned during > the BoF we could just embed a fw file→fw package mapping at build time > to ease lookup (basically what you're doing with apt-file, except we > would have a static list in the d-i image; for one thing, there's no > guarantee network is available at early stages to query Contents from > mirrors). I've already implemented this idea in isenkram. The isenkram-cli package contain an embedded copy of the list of packages with files in /lib/firmware/, fetched from the apt-file data set. This is part of the background for my recommondation to move to isenkram-cli for mapping hardware to firmware and user space packages. When the same information is available from appstream, I suspect we want to include appstream data on the installation media, instead of embedding it in isenkram-cli. -- Happy hacking Petter Reinholdtsen
Re: What's the deal with discover*?
Petter Reinholdtsen (2016-01-10): > [Cyril Brulebois] > > So the question becomes: should they be moved to git? Keeping the manual > > as a special snowflake leaving under d-i's svn is OK (mostly to avoid > > translators' having to learn about a new tool), but keeping debian-boot > > maintained packages under a different scm under a different group seems > > a bad idea. > > If someone got the time to do so, I believe that would be a good thing > to do. But my recommondation would be to switch to isenkram-cli with > appstream as the data souce and ask for the removal of discover. > > > I don't know a lot about appstream metadata, but I mentioned during > > the BoF we could just embed a fw file→fw package mapping at build time > > to ease lookup (basically what you're doing with apt-file, except we > > would have a static list in the d-i image; for one thing, there's no > > guarantee network is available at early stages to query Contents from > > mirrors). > > I've already implemented this idea in isenkram. The isenkram-cli > package contain an embedded copy of the list of packages with files in > /lib/firmware/, fetched from the apt-file data set. This is part of the > background for my recommondation to move to isenkram-cli for mapping > hardware to firmware and user space packages. Currently, there's no python in d-i, so isenkram is a no-go (as already mentioned a few months ago). > When the same information is available from appstream, I suspect we want > to include appstream data on the installation media, instead of > embedding it in isenkram-cli. Mraw, KiBi. signature.asc Description: Digital signature
Bug#788062: tagging 788062
Hi Thomas, On Mon, Sep 28, 2015 at 02:10:11PM +0200, Thomas Lange wrote: > tags 788062 + pending Is there any link to a discussion how this is going to be fixed, anything I can help with? I discussed with Nigel (cc:) if this needs to be fixed by using ro,noload when mounting the partition via grub-mount? The bug seems to be there since at least /usr/lib/os-probes/50mounted-tests invokes grub-mount which should use "noload"[1] for the fuse mount (IIRC). Cheers, -- Guido [1] http://www.kernel.org/doc/Documentation/filesystems/ext4.txt
Re: What's the deal with discover*?
On Sun, 2016-01-10 at 16:44 +0100, Petter Reinholdtsen wrote:
[...]
> One thing that would help a lot is to get the firmware packages to
> announce their firmware using appstream metadata. This would make it a
> lot easier to locate the correct firmware package, and would help both
> isenkram and all others interested in operating on firmware data.
[...]
Like this (patch attached)?
Ben.
--
Ben Hutchings
Power corrupts. Absolute power is kind of neat.
- John Lehman, Secretary of the US Navy 1981-1987From 163f82127633623028cfe408777aaac6dfdd2c87 Mon Sep 17 00:00:00 2001
From: Ben Hutchings
Date: Sun, 10 Jan 2016 18:02:33 +
Subject: [PATCH firmware-nonfree] Add AppStream metadata to all packages
containing firmware blobs
To: debian-ker...@lists.debian.org
---
debian/bin/gencontrol.py | 9 +
debian/changelog | 6 ++
debian/rules | 1 +
debian/rules.real | 4
debian/templates/metainfo.xml.firmware.in | 1 +
debian/templates/metainfo.xml.in | 12
6 files changed, 33 insertions(+)
create mode 100644 debian/templates/metainfo.xml.firmware.in
create mode 100644 debian/templates/metainfo.xml.in
diff --git a/debian/bin/gencontrol.py b/debian/bin/gencontrol.py
index 9fce9b8..4664585 100755
--- a/debian/bin/gencontrol.py
+++ b/debian/bin/gencontrol.py
@@ -273,11 +273,15 @@ class GenControl(debian_linux.gencontrol.Gencontrol):
for link, target in links.items()])
files_desc = ["Contents:"]
+firmware_meta_temp = self.templates["metainfo.xml.firmware"]
+firmware_meta_list = []
wrap = TextWrapper(width = 71, fix_sentence_endings = True,
initial_indent = ' * ',
subsequent_indent = ' ').wrap
for f in config_entry['files']:
+firmware_meta_list.append(self.substitute(firmware_meta_temp,
+ {'filename': f}))
if f in links:
continue
f, f_real, version = files_real[f]
@@ -328,6 +332,11 @@ You must agree to the terms of this license before it is installed."""
makefile.add('binary-indep', cmds = ["$(MAKE) -f debian/rules.real binary-indep %s" % makeflags])
+vars['firmware-list'] = ''.join(firmware_meta_list)
+package_meta_temp = self.templates["metainfo.xml"]
+# XXX Might need to escape some characters
+codecs.open("debian/firmware-%s.metainfo.xml" % package, 'w', 'utf-8').write(self.substitute(package_meta_temp, vars))
+
def process_template(self, in_entry, vars):
e = Template()
for key, value in in_entry.items():
diff --git a/debian/changelog b/debian/changelog
index 7d64e5c..844bdd0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+firmware-nonfree (20151207-2) UNRELEASED; urgency=medium
+
+ * Add AppStream metadata to all packages containing firmware blobs
+
+ -- Ben Hutchings Sun, 10 Jan 2016 17:58:39 +
+
firmware-nonfree (20151207-1) unstable; urgency=medium
* New upstream version
diff --git a/debian/rules b/debian/rules
index a836df1..d6d3e89 100755
--- a/debian/rules
+++ b/debian/rules
@@ -70,6 +70,7 @@ maintainerclean:
rm -f debian/*.bug-presubj
-rm debian/*.copyright
-rm debian/*.hook.*
+ rm -f debian/*.metainfo.xml
-rm debian/*.preinst
-rm debian/*.postinst
-rm debian/*.templates
diff --git a/debian/rules.real b/debian/rules.real
index da5e040..1def0e3 100644
--- a/debian/rules.real
+++ b/debian/rules.real
@@ -25,6 +25,10 @@ install:
echo ln -s "$$target" "$$link"; \
ln -s "$$target" "$$link"; \
done
+ifneq ($(FILES),)
+ dh_installdirs /usr/share/appdata
+ dh_install debian/$(PACKAGE_NAME).metainfo.xml /usr/share/appdata
+endif
dh_bugfiles
dh_installchangelogs
dh_installdocs -XTODO
diff --git a/debian/templates/metainfo.xml.firmware.in b/debian/templates/metainfo.xml.firmware.in
new file mode 100644
index 000..a555b93
--- /dev/null
+++ b/debian/templates/metainfo.xml.firmware.in
@@ -0,0 +1 @@
+@filename@
diff --git a/debian/templates/metainfo.xml.in b/debian/templates/metainfo.xml.in
new file mode 100644
index 000..697ce1d
--- /dev/null
+++ b/debian/templates/metainfo.xml.in
@@ -0,0 +1,12 @@
+
+
+ org.debian.packages.firmware-@package@
+ Binary firmware for @desc@
+
+Binary firmware for @longdesc@.
+
+ CC0-1.0
+
+@firmware-list@
+
+
signature.asc
Description: This is a digitally signed message part
Bug#770032: marked as done (home recipe allocates too little for root on small disks)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#725642: fixed in partman-auto 133 has caused the Debian Bug report #725642, regarding home recipe allocates too little for root on small disks 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.) -- 725642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installer Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? Installation of a new system on an 8.6GB virtual harddrive using either of the listed NETINST cds "Jessie" Official Snapshot i386 NETINST Binary-1 20141117-04:37 "Jessie" Official Snapshot amd64 NETINST Binary-1 20141117-06:40 Select any install method and then use Guided Partitioning with separate /home (with or without encryption). Default setting is ~2gb / and remainder for /home. This is insufficient space for install with any of the graphical environments so during the Install Software step, a red error box comes up that gives a generic Step Failed message. * What exactly did you do (or not do) that was effective (or ineffective)? First step was to try to resize the LVM w/Encryption which failed. Logs showed out of space errors, so reinstalled without separate /home. * What was the outcome of this action? Fully functional without separate /home partition, default install with Cinnamon (not Gnome) appears to be just over 4gb. * What outcome did you expect instead? Information about the size of the packages selected, so a possible install could be completed with the partitioning chosen. or A note in the Guided Partitioning regarding space requirements (since non-GUI should fit in the space allocated). Possibly with a separate Guided for GUI option? Best is one or both and a clear error message when the install fails at the install software step. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-586 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 725...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4
Bug#725642: marked as done (maximum for root is too small in home and multi recipes)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#725642: fixed in partman-auto 133 has caused the Debian Bug report #725642, regarding maximum for root is too small in home and multi recipes 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.) -- 725642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: important Tags: d-i Dear Maintainer, When installing Debian Wheezy I chose to separate my home partition from the rest of the system, installing it all on an encrypted LVM volume. However, I chose to let the debian installer automatically choose the sizes for these two partitions. Out of a hard drive of 300 GB, the installer assigned 9 - 10 GB to the root partion, leaving the rest (minus 5 gb swap) to the home partition. I didn't expect it to allocate the root partition so little space. I have ended up having a mostly full root partition, occasionally causing problems, and recently when I installed more programs, this became full and parts of my system ceased to function. With a hard drive this size I could easily have spared 5 GB more to avoid these problems, so it might be good to increase the amount allocated to the root partition by default in future - perhaps it should be allocated a minimum of 5 % of the volume? Cheers, Nick -- Package-specific info: Boot method: Image version: Date: Machine: Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 9611492 7558416 1564836 83% / udevdevtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 385740 876384864 1% /run /dev/mapper/fog--on--the--tyne-root ext4 9611492 7558416 1564836 83% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 77146092771368 1% /run/shm /dev/sda1 ext2233191 87712133038 40% /boot /dev/mapper/fog--on--the--tyne-home ext4 289953024 147817992 127406228 54% /home tmpfs tmpfs 2366440 120 2366320 1% /tmp Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ O] Detect network card:[O] Configure network: [O] Detect CD: [O ] Load installer modules: [O ] Clock/timezone setup: [ O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7.0 (wheezy) - installer build 20130430" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux fog-on-the-tyne 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:fd10] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 5 Ser
Bug#783514: marked as done (auto partitioning with separate /home does not allow enough space for root partition when virtualbox default disk space is chosen)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#725642: fixed in partman-auto 133 has caused the Debian Bug report #725642, regarding auto partitioning with separate /home does not allow enough space for root partition when virtualbox default disk space is chosen 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.) -- 725642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- package: partman-auto version: 126 When default disk space of 8gb is chosen in virtual box and auto-partition with encryption is selected, root partition is given just 2.3 gb and installation fails without enough space (using lxde live prebuilt image). I think it would be better to give enough space for root partition if disk space is small. Since 8gb is the default size of virtual box hard disk, this situation can be common. I think the same issue will happen without encryption as well. Since we already know the size requirement of a live image, I think it makes sense to allocate the required space for / partition. signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 725...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most space should be allocated to it. - Increase priority of /tmp partition so more than the minimum is allocated to it. - Adjust priority of / partition in relation to other partitions. Checksums-Sha1: cd98dfea7dd5f0f79d67f91b8bb2a347e5824544 1614 partman-auto_133.dsc c25f3c1f6b19fffbba7d343732a09d98376032ba 107940 partman-auto_133.tar.xz e1d86bfef1ee49b9333e4d06e1dba354edd6fcd5 86812 partman-auto_133_i386.udeb Checksums-Sha256: d71279e38e1c7310a3f52f7248fc536849cace96b596def11221643ba208aabb 1614 partman-auto_133.dsc 1539ca5288812328d6bab07f3a7891bdb59f4990354240ee8d68ddc7b55ea391 107940 partman-auto_133.tar.xz 6586c6533874f03fac9b58ce4febe109e8ddec2bff47f12cf872146e4a03d092 86812 partman-auto_133_i386.udeb Files: 9a1a1e0ec0a2af927d279e529fdce66c 1614 debian-installer standard partman-auto_133.dsc e9c51e5d8a2174656157422948766f4a 107940 debian-installer standard partman-auto_133.tar.xz 3b251c8befc2628c5ac3ae61793d
Bug#809932: marked as done (installation-reports: Successful install of Debian Stretch on Sheevaplug)
Your message dated Sun, 10 Jan 2016 18:19:54 +
with message-id
and subject line Bug#725642: fixed in partman-auto 133
has caused the Debian Bug report #725642,
regarding installation-reports: Successful install of Debian Stretch on
Sheevaplug
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.)
--
725642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725642
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports
Severity: normal
Dear Maintainer,
First, I upgraded U-boot on the machine to version "2014.10+dfsg1-5"
Second, I downloaded uImage and uInitrd from
https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/marvell/sheevaplug/
and put them on a USB stick (8GB) prepared with an ext2 filesystem.
Then I connected to the serial port (using "screen -L /dev/ttyUSB0 115200")
and followed the instructions on Martin's website
http://www.cyrius.com/debian/kirkwood/sheevaplug/install/
to boot the installer.
At the first installer screen, I hit "back" a couple of times till I got to the
main menu
where I could get a screen that allowed me to change the installer priority
to "low" (i.e. to make it an "expert" install)
Then I followed the normal installation procedure til it got to the screen
asking which
non-standard udebs I wanted to install. I chose the network-console so I could
log in
via ssh with a larger screen than 24x80.
After that, it was just answering questions as usual, taking defaults whenever
I could.
When it got to tasksel, I chose a basic installation with only the ssh server
enabled,
but nothing else.
After the reboot (and some more u-boot magic from Martin's web page) I used
tasksel
to install the print-server task. No problems were encountered.
I also moved /tmp to tmpfs
-- Package-specific info:
Boot method: I followed the instructions from Martin Michlmayer's web page,
Image version: I got the uI* files from
https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/
Date: 2015/01/03 about 23:30 UTC
Machine: Stock Sheevaplug without SATA
Partitions:
Disk /dev/sda: 7.2 GiB, 7748222976 bytes, 15133248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x74cb16e8
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 499711 497664 243M 83 Linux
/dev/sda2499712 4829183 4329472 2.1G 83 Linux
/dev/sda3 4831230 15132671 10301442 4.9G 5 Extended
/dev/sda5 4831232 5294079 462848 226M 82 Linux swap / Solaris
/dev/sda6 5296128 15132671 9836544 4.7G 83 Linux
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev devtmpfs 10240 0 10240 0% /dev
tmpfs tmpfs 102788 348102440 1% /run
/dev/sda2 ext4 2065152 1878636 61896 97% /
tmpfs tmpfs 256964 0256964 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
tmpfs tmpfs 256964 0256964 0% /sys/fs/cgroup
tmpfs tmpfs 102400 20102380 1% /tmp
/dev/sda6 ext4 47099209736 4437888 1% /home
/dev/sda1 ext2240972 44594183937 20% /boot
tmpfs tmpfs51396 0 51396 0% /run/user/1000
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [o]
Detect network card:[o]
Configure network: [o]
Detect CD: [ ]
Load installer modules: [o]
Clock/timezone setup: [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives: [o] see note 1
Install base system:[o]
Install tasks: [o]
Install boot loader:[ ]
Overall install:[o]
Comments/Problems:
note 1: As you can see from the partition table shown above, It took
almost 5GB of the 8GB USB stick I gave it for /home. This leaves root
and swap perilously little space for anything but a very basic install.
If I ran the world, I'd make sure that the root ("everything but /home and swap)
partition got at least 4GB; and swap got at least 4 times the size of system
RAM.
--
Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.
Once you have filled out this report, mail it to sub...@bugs.debian.org.
=
Bug#265290: marked as done (1.8GB are not enough for / with desktop (autopartition with home))
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#725642: fixed in partman-auto 133 has caused the Debian Bug report #725642, regarding 1.8GB are not enough for / with desktop (autopartition with home) 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.) -- 725642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Debian-installer-version: sarge-i386-netinst.iso 26-07-2004 http://cdimage.debian.org/pub/cdimage-testing/daily/i386/current/ uname -a: Linux note 2.4.26-1-386 #2 Sat May 1 16:31:24 EST 2004 i686 GNU/Linux Date: 26-07-2004 20:48 Method: cd-image -> lan (-> cable) -> ftp.nluug.nl not prixied Machine:Acer TravelMate 730TX Processor: i586 Memory: 128Mb Root Device:ide 6.2G IBM-DBCA206480 (??from hda/model) Root Size/partition table: Output of lspci: (sorry, I'm typing this on an other system...) Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Create file systems:[O] Mount partitions: [O] Install base system:[E] Install boot loader:[O] Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: The autopartition was a problem! The autopartition (with home) made the root partition 1.8G. This is not enough for the install (with only desktop selected, no custom changes) => I had to reinstall. (Reinstalling at this moment => succes story with pci dump will follow..) When you want something different then ext3, you have to change all partitions manually. A global choice would be handy When you change a partitions size, the partition will be resized immediately. This is annoying, because it unnecessary takes time. (I choose to erase all partitions previously) --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 725...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most
Bug#770032: marked as done (home recipe allocates too little for root on small disks)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#770032: fixed in partman-auto 133 has caused the Debian Bug report #770032, regarding home recipe allocates too little for root on small disks 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.) -- 770032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770032 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installer Severity: important Tags: d-i Dear Maintainer, * What led up to the situation? Installation of a new system on an 8.6GB virtual harddrive using either of the listed NETINST cds "Jessie" Official Snapshot i386 NETINST Binary-1 20141117-04:37 "Jessie" Official Snapshot amd64 NETINST Binary-1 20141117-06:40 Select any install method and then use Guided Partitioning with separate /home (with or without encryption). Default setting is ~2gb / and remainder for /home. This is insufficient space for install with any of the graphical environments so during the Install Software step, a red error box comes up that gives a generic Step Failed message. * What exactly did you do (or not do) that was effective (or ineffective)? First step was to try to resize the LVM w/Encryption which failed. Logs showed out of space errors, so reinstalled without separate /home. * What was the outcome of this action? Fully functional without separate /home partition, default install with Cinnamon (not Gnome) appears to be just over 4gb. * What outcome did you expect instead? Information about the size of the packages selected, so a possible install could be completed with the partitioning chosen. or A note in the Guided Partitioning regarding space requirements (since non-GUI should fit in the space allocated). Possibly with a separate Guided for GUI option? Best is one or both and a clear error message when the install fails at the install software step. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-586 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 770...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4
Bug#783514: marked as done (auto partitioning with separate /home does not allow enough space for root partition when virtualbox default disk space is chosen)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#770032: fixed in partman-auto 133 has caused the Debian Bug report #770032, regarding auto partitioning with separate /home does not allow enough space for root partition when virtualbox default disk space is chosen 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.) -- 770032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770032 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- package: partman-auto version: 126 When default disk space of 8gb is chosen in virtual box and auto-partition with encryption is selected, root partition is given just 2.3 gb and installation fails without enough space (using lxde live prebuilt image). I think it would be better to give enough space for root partition if disk space is small. Since 8gb is the default size of virtual box hard disk, this situation can be common. I think the same issue will happen without encryption as well. Since we already know the size requirement of a live image, I think it makes sense to allocate the required space for / partition. signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 770...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most space should be allocated to it. - Increase priority of /tmp partition so more than the minimum is allocated to it. - Adjust priority of / partition in relation to other partitions. Checksums-Sha1: cd98dfea7dd5f0f79d67f91b8bb2a347e5824544 1614 partman-auto_133.dsc c25f3c1f6b19fffbba7d343732a09d98376032ba 107940 partman-auto_133.tar.xz e1d86bfef1ee49b9333e4d06e1dba354edd6fcd5 86812 partman-auto_133_i386.udeb Checksums-Sha256: d71279e38e1c7310a3f52f7248fc536849cace96b596def11221643ba208aabb 1614 partman-auto_133.dsc 1539ca5288812328d6bab07f3a7891bdb59f4990354240ee8d68ddc7b55ea391 107940 partman-auto_133.tar.xz 6586c6533874f03fac9b58ce4febe109e8ddec2bff47f12cf872146e4a03d092 86812 partman-auto_133_i386.udeb Files: 9a1a1e0ec0a2af927d279e529fdce66c 1614 debian-installer standard partman-auto_133.dsc e9c51e5d8a2174656157422948766f4a 107940 debian-installer standard partman-auto_133.tar.xz 3b251c8befc2628c5ac3ae61793d
Bug#265290: marked as done (1.8GB are not enough for / with desktop (autopartition with home))
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#770032: fixed in partman-auto 133 has caused the Debian Bug report #770032, regarding 1.8GB are not enough for / with desktop (autopartition with home) 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.) -- 770032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770032 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Debian-installer-version: sarge-i386-netinst.iso 26-07-2004 http://cdimage.debian.org/pub/cdimage-testing/daily/i386/current/ uname -a: Linux note 2.4.26-1-386 #2 Sat May 1 16:31:24 EST 2004 i686 GNU/Linux Date: 26-07-2004 20:48 Method: cd-image -> lan (-> cable) -> ftp.nluug.nl not prixied Machine:Acer TravelMate 730TX Processor: i586 Memory: 128Mb Root Device:ide 6.2G IBM-DBCA206480 (??from hda/model) Root Size/partition table: Output of lspci: (sorry, I'm typing this on an other system...) Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Create file systems:[O] Mount partitions: [O] Install base system:[E] Install boot loader:[O] Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: The autopartition was a problem! The autopartition (with home) made the root partition 1.8G. This is not enough for the install (with only desktop selected, no custom changes) => I had to reinstall. (Reinstalling at this moment => succes story with pci dump will follow..) When you want something different then ext3, you have to change all partitions manually. A global choice would be handy When you change a partitions size, the partition will be resized immediately. This is annoying, because it unnecessary takes time. (I choose to erase all partitions previously) --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 770...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most
Bug#803604: marked as done (/var and /tmp too small with multi recipe)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#803604: fixed in partman-auto 133 has caused the Debian Bug report #803604, regarding /var and /tmp too small with multi recipe 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.) -- 803604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803604 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: base Severity: important Tags: d-i Dear Maintainer, Within the first week of installing Debian "jessie" 8.2 20150908, I continually got warnings about low disk space in /var/cache/apt/archives/. Now 2x weeks after install I did an "apt-get update/upgrade & I got: "You don't have enough free space in /var/cache/apt/archives/." Also the /tmp partition is too small as I often need lots of /tmp space when using the GIMP graphics program? I believe that the default partition spaces need to be revised in keeping with modern requirements & disk sizes? When I installed the system, I chose "LVM" as I understand that this will enable me to enlarge/change partition sizes without a complete reinstall? I have not yet found easily understandable information on doing this yet? Please advise a suitable website to follow the (simple!) instructions.Thank you. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 133 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 803...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christian Perrier (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most space should be allocated to it. - Increase priority of /tmp partition so more than the minimum is allocated to it. - Adjust priority of / partition in relation to other partitions. Checksums-Sha1: cd98dfea7dd5f0f79d67f91b8bb2a347e5824544 1614 partman-auto_133.dsc c25f3c1f6b19fffbba7d343732a09d98376032ba 107940 partman-auto_133.tar.xz e1d86bfef1ee49b9333e4d06e1dba354edd6fcd5 86812 partman-auto_133_i386.udeb Checksums-Sha256: d71279e38e1c7310a3f52f7248fc536849cace96b596def11221
Bug#809932: marked as done (installation-reports: Successful install of Debian Stretch on Sheevaplug)
Your message dated Sun, 10 Jan 2016 18:19:54 +
with message-id
and subject line Bug#770032: fixed in partman-auto 133
has caused the Debian Bug report #770032,
regarding installation-reports: Successful install of Debian Stretch on
Sheevaplug
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.)
--
770032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770032
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports
Severity: normal
Dear Maintainer,
First, I upgraded U-boot on the machine to version "2014.10+dfsg1-5"
Second, I downloaded uImage and uInitrd from
https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/marvell/sheevaplug/
and put them on a USB stick (8GB) prepared with an ext2 filesystem.
Then I connected to the serial port (using "screen -L /dev/ttyUSB0 115200")
and followed the instructions on Martin's website
http://www.cyrius.com/debian/kirkwood/sheevaplug/install/
to boot the installer.
At the first installer screen, I hit "back" a couple of times till I got to the
main menu
where I could get a screen that allowed me to change the installer priority
to "low" (i.e. to make it an "expert" install)
Then I followed the normal installation procedure til it got to the screen
asking which
non-standard udebs I wanted to install. I chose the network-console so I could
log in
via ssh with a larger screen than 24x80.
After that, it was just answering questions as usual, taking defaults whenever
I could.
When it got to tasksel, I chose a basic installation with only the ssh server
enabled,
but nothing else.
After the reboot (and some more u-boot magic from Martin's web page) I used
tasksel
to install the print-server task. No problems were encountered.
I also moved /tmp to tmpfs
-- Package-specific info:
Boot method: I followed the instructions from Martin Michlmayer's web page,
Image version: I got the uI* files from
https://d-i.debian.org/daily-images/armel/daily/kirkwood/netboot/
Date: 2015/01/03 about 23:30 UTC
Machine: Stock Sheevaplug without SATA
Partitions:
Disk /dev/sda: 7.2 GiB, 7748222976 bytes, 15133248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x74cb16e8
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 499711 497664 243M 83 Linux
/dev/sda2499712 4829183 4329472 2.1G 83 Linux
/dev/sda3 4831230 15132671 10301442 4.9G 5 Extended
/dev/sda5 4831232 5294079 462848 226M 82 Linux swap / Solaris
/dev/sda6 5296128 15132671 9836544 4.7G 83 Linux
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev devtmpfs 10240 0 10240 0% /dev
tmpfs tmpfs 102788 348102440 1% /run
/dev/sda2 ext4 2065152 1878636 61896 97% /
tmpfs tmpfs 256964 0256964 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
tmpfs tmpfs 256964 0256964 0% /sys/fs/cgroup
tmpfs tmpfs 102400 20102380 1% /tmp
/dev/sda6 ext4 47099209736 4437888 1% /home
/dev/sda1 ext2240972 44594183937 20% /boot
tmpfs tmpfs51396 0 51396 0% /run/user/1000
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [o]
Detect network card:[o]
Configure network: [o]
Detect CD: [ ]
Load installer modules: [o]
Clock/timezone setup: [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives: [o] see note 1
Install base system:[o]
Install tasks: [o]
Install boot loader:[ ]
Overall install:[o]
Comments/Problems:
note 1: As you can see from the partition table shown above, It took
almost 5GB of the 8GB USB stick I gave it for /home. This leaves root
and swap perilously little space for anything but a very basic install.
If I ran the world, I'd make sure that the root ("everything but /home and swap)
partition got at least 4GB; and swap got at least 4 times the size of system
RAM.
--
Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.
Once you have filled out this report, mail it to sub...@bugs.debian.org.
=
Bug#725642: marked as done (maximum for root is too small in home and multi recipes)
Your message dated Sun, 10 Jan 2016 18:19:54 + with message-id and subject line Bug#770032: fixed in partman-auto 133 has caused the Debian Bug report #770032, regarding maximum for root is too small in home and multi recipes 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.) -- 770032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770032 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: important Tags: d-i Dear Maintainer, When installing Debian Wheezy I chose to separate my home partition from the rest of the system, installing it all on an encrypted LVM volume. However, I chose to let the debian installer automatically choose the sizes for these two partitions. Out of a hard drive of 300 GB, the installer assigned 9 - 10 GB to the root partion, leaving the rest (minus 5 gb swap) to the home partition. I didn't expect it to allocate the root partition so little space. I have ended up having a mostly full root partition, occasionally causing problems, and recently when I installed more programs, this became full and parts of my system ceased to function. With a hard drive this size I could easily have spared 5 GB more to avoid these problems, so it might be good to increase the amount allocated to the root partition by default in future - perhaps it should be allocated a minimum of 5 % of the volume? Cheers, Nick -- Package-specific info: Boot method: Image version: Date: Machine: Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 9611492 7558416 1564836 83% / udevdevtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 385740 876384864 1% /run /dev/mapper/fog--on--the--tyne-root ext4 9611492 7558416 1564836 83% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 77146092771368 1% /run/shm /dev/sda1 ext2233191 87712133038 40% /boot /dev/mapper/fog--on--the--tyne-home ext4 289953024 147817992 127406228 54% /home tmpfs tmpfs 2366440 120 2366320 1% /tmp Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ O] Detect network card:[O] Configure network: [O] Detect CD: [O ] Load installer modules: [O ] Clock/timezone setup: [ O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7.0 (wheezy) - installer build 20130430" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux fog-on-the-tyne 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:fd10] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:ff1e] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 5 Ser
Processing of partman-auto_133_i386.changes
partman-auto_133_i386.changes uploaded successfully to ftp-master.debian.org along with the files: partman-auto_133.dsc partman-auto_133.tar.xz partman-auto_133_i386.udeb Greetings, Your Debian queue daemon (running on host coccia.debian.org)
Re: What's the deal with discover*?
[Cyril Brulebois] > Currently, there's no python in d-i, so isenkram is a no-go (as already > mentioned a few months ago). The isenkram-autoinstall-firmware script is bourne shell, not python. There is no need for python in d-i to use this. The python related stuff part is for running when /target/ is operational (ie when tasksel is executed. I suspect we are talking past each other, as your comment do not make sense to me. -- Happy hacking Petter Reinholdtsen
Processing of partman-auto_133_i386.changes
partman-auto_133_i386.changes uploaded successfully to localhost along with the files: partman-auto_133.dsc partman-auto_133.tar.xz partman-auto_133_i386.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org)
partman-auto_133_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 07:01:50 +0100 Source: partman-auto Binary: partman-auto Architecture: source i386 Version: 133 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 725642 770032 803604 Changes: partman-auto (133) unstable; urgency=medium . [ Martin Michlmayr ] * Update partition layout defaults: - atomic: - Set minimimum size of / partition to 900 MB for platforms without separate /boot partition and to 800 MB for those with /boot. - home: - Increase maximum size of / partition to 20 GB or 30 GB, depending on the platform. - Increase minimum size of / partition to 1500 MB and of /home to 1000 MB. This allocates more space to the / partition on smaller disks and ensures the separate /home option is not offered on 2 GB disks. - Increase priority of / partition so more space is allocated to it on small disks. Closes: #770032 - multi: - Increase maximum size of / partition to 25 GB. Closes: #725642 - Increase maximum size of /var partition to 10 GB. Closes: #803604 - Increase maximum size of /tmp partition to 2 GB. - Increase minimum size of / partition to 2000 MB, of /var to 1000 MB, of /tmp to 256 MB and of /home to 4000 MB. This ensures that this option is no longer offered on 4 GB disks. - Increase priority of /home partition since most space should be allocated to it. - Increase priority of /tmp partition so more than the minimum is allocated to it. - Adjust priority of / partition in relation to other partitions. Checksums-Sha1: cd98dfea7dd5f0f79d67f91b8bb2a347e5824544 1614 partman-auto_133.dsc c25f3c1f6b19fffbba7d343732a09d98376032ba 107940 partman-auto_133.tar.xz e1d86bfef1ee49b9333e4d06e1dba354edd6fcd5 86812 partman-auto_133_i386.udeb Checksums-Sha256: d71279e38e1c7310a3f52f7248fc536849cace96b596def11221643ba208aabb 1614 partman-auto_133.dsc 1539ca5288812328d6bab07f3a7891bdb59f4990354240ee8d68ddc7b55ea391 107940 partman-auto_133.tar.xz 6586c6533874f03fac9b58ce4febe109e8ddec2bff47f12cf872146e4a03d092 86812 partman-auto_133_i386.udeb Files: 9a1a1e0ec0a2af927d279e529fdce66c 1614 debian-installer standard partman-auto_133.dsc e9c51e5d8a2174656157422948766f4a 107940 debian-installer standard partman-auto_133.tar.xz 3b251c8befc2628c5ac3ae61793d4c91 86812 debian-installer standard partman-auto_133_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWkptfAAoJEIcvcCxNbiWoxK4QAIbtkSt7QsyTvqlZjJMX/O/E 39YRy0Y6gu763EGTg+p+JnycIa4g58++PnqoEByfPVjU/bNcI/C0ZGZRu3A5ws63 xLsUwBuYAaZVoWULsxuVcLqqoPzcP4NpTohdFBJlgnGnwEJzRjIctjaqHQz/Aofb j0dvNPmNY+MQsG1YsYiHGsGqUnpwyonwCv+STFnkx0cl6hGiTDLo7xhsQkqXiP14 JU1soqjIj03QQ23B3al+oOgFrh8+HQzhyfK92YHuHz2CZYBxsVRKkvi+BSLJXDXI 9ulc8YlWqBkUqGu0YPINdF7fEv5Hb1s/weU7rIygM3hKvX5+m42BMenieAgAQPyD Ue4U9eqqxlO0wjk2y9A0ETe9GC2Le+anj/eIsDsjX3GOgbO3h6p5rPBm5rOgCkiz QDwNJ6nnxSiREh2XoYJxq8U5RkddwbxMOHe9cFBzyhYBdNt9b0ZDqtOjMfUAEp91 fpJTp+6MvYJK2suELw31BSQTXrq7kE/a1l1gxShMwMB5ecBuieEKbeYE43aj/Jjs qyT6brWpUoaMMwnaQdUX8k2njt+uxyH6f9Nn+7/u+xJJT5ZW7S4f/l1MdPgXlCkG NCBzfaYLFHeYwllj7+PL19JzuCtMhCXnzVfj8o14bl3JglS9LTcF5TNp9bgoAaKZ 4CCf3tmzoiwF/Z09w/H5 =2xck -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#788062: tagging 788062
> On Sun, 10 Jan 2016 18:52:04 +0100, Guido Günther said: > Hi Thomas, > On Mon, Sep 28, 2015 at 02:10:11PM +0200, Thomas Lange wrote: >> tags 788062 + pending I just realized that the pending tag was set by me because of an error in my workflow. I will unset it now. -- regards Thomas
Processed: tagging 788062
Processing commands for cont...@bugs.debian.org: > tags 788062 - pending Bug #788062 [os-prober] os-prober corrupts LVs/partitions while being mounted inside a VM Bug #810121 [os-prober] linux: KVM guests randomly get I/O errors on VirtIO based devices Removed tag(s) pending. Removed tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 788062: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788062 810121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810121 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: What's the deal with discover*?
Petter Reinholdtsen (2016-01-10): > [Cyril Brulebois] > > Currently, there's no python in d-i, so isenkram is a no-go (as already > > mentioned a few months ago). > > The isenkram-autoinstall-firmware script is bourne shell, not python. This probably could have been mentioned earlier. > There is no need for python in d-i to use this. The python related > stuff part is for running when /target/ is operational (ie when tasksel > is executed. I suspect we are talking past each other, as your comment > do not make sense to me. Probably. I read your previous mail as “let's use isenkram-cli from d-i”, which we can't for the reason I mentioned. Reusing its logic (contents and/or shell scripts) could make sense though. Mraw, KiBi. signature.asc Description: Digital signature
Bug#571136: Fwd: Re: Bug#571136: please remove useless devices from devices.tar.gz
Hi, Marco d'Itri wrote: > On Jan 10, Cyril Brulebois wrote: > > We have a bug report with a patch by Marco against debootstrap (see > > attachment), which changes how devices are generated; I can't really > > tell how much this might affect all of you (especially with debootstrap > It is not supposed to, since both hurd and kfreebsd already used > a different method to manage /dev. Yes, the code Marco changed cannot be reached when HOST_OS is kfreebsd*, freebsd* or hurd*. kfreebsd devfs provides all the device nodes without manually creating any or using devices.tar.gz; even for more exotic use cases like BSD jails. hurd appears to have something equivalent. Thanks for letting us know. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
More cdebconf patches
Hi everyone, I just pushed a couple of patches for cdebconf-gtk. Besides removing conditional code to handle old versions of glib, the main change is for the display of text in the banner, done directly with cairo, thus removing the last bit of deprecated GDK code. I believe I've reproduced the same behaviour ; but if you notice something different I might have missed, please shout. The next patch could be the one attached. It makes it possible to chose at configure time to compile for either GTK+2 or GTK+3, and in this version compiles the udeb for GTK+2, and the deb for GTK+3. Unfortunately the #if in the code are rather ugly ; but my attempts at making it cleaner ended with something even less readable, so I left them that way. And there's only 6 occurrences, so it's not that bad. Any thought about whether I should merge this patch ? If yes, about enabling GTK+3 for the deb ? Thanks, Regis >From d7c6920fc2293c4d3782988990234a29ab079ccb Mon Sep 17 00:00:00 2001 From: Regis Boudin Date: Sat, 9 Jan 2016 18:11:39 + Subject: [PATCH] First shot at being able to build for either GTK+2 or GTK+3 --- configure.ac | 13 - debian/control | 1 + debian/rules | 2 +- src/modules/frontend/gtk/Makefile.in | 6 +++--- src/modules/frontend/gtk/align_text_renderer.c | 14 ++ src/modules/frontend/gtk/screenshot.c | 4 src/modules/frontend/gtk/ui.c | 8 7 files changed, 39 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index 1defce9..0982f0e 100644 --- a/configure.ac +++ b/configure.ac @@ -148,15 +148,18 @@ if test -z "$FRONTEND_MODULES"; then PKG_CHECK_EXISTS([slang], [FRONTEND_MODULES="$FRONTEND_MODULES slang"], [AC_MSG_WARN([cannot build Slang frontend])]) fi +FRONTEND_MODULES_BUILD="" for frontend in $FRONTEND_MODULES; do case $frontend in - gtk) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= 2.24 pango gdk-pixbuf-2.0]);; - ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses]);; - newt) PKG_CHECK_MODULES([NEWT],[libnewt slang]);; - slang) PKG_CHECK_MODULES([SLANG],[slang]);; - *);; + gtk|gtk2) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= 2.24 pango gdk-pixbuf-2.0], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);; + gtk3) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-3.0 pango gdk-pixbuf-2.0], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);; + ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD ncurses"]);; + newt) PKG_CHECK_MODULES([NEWT],[libnewt slang], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD newt"]);; + slang) PKG_CHECK_MODULES([SLANG],[slang], [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD slang"]);; + *) FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD $frontend";; esac done +FRONTEND_MODULES="$FRONTEND_MODULES_BUILD" AC_SUBST([FRONTEND_MODULES]) AC_SUBST([DB_MODULES]) diff --git a/debian/control b/debian/control index 5a6625b..c57d8eb 100644 --- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: libdebian-installer4-dev (>= 0.41) | libdebian-installer-dev, libglib2.0-dev (>= 2.31), libgtk2.0-dev (>= 2.24), + libgtk3.0-dev, libcairo2-dev (>= 1.8.10-3), libselinux1-dev (>= 2.3) [linux-any] | libselinux-dev [linux-any], dh-autoreconf, diff --git a/debian/rules b/debian/rules index b2b35f4..d00bbb7 100755 --- a/debian/rules +++ b/debian/rules @@ -18,7 +18,7 @@ CONFFILE=/etc/cdebconf.conf LIBDEBCONFDEV=libdebconfclient0-dev LIBDEBCONF=libdebconfclient0 -DEB_FRONTENDS=passthrough text newt gtk +DEB_FRONTENDS=passthrough text newt gtk3 UDEB_FRONTENDS=passthrough text newt gtk ifeq ($(DEB_HOST_ARCH_OS),linux) diff --git a/src/modules/frontend/gtk/Makefile.in b/src/modules/frontend/gtk/Makefile.in index 09fc801..aa45ede 100644 --- a/src/modules/frontend/gtk/Makefile.in +++ b/src/modules/frontend/gtk/Makefile.in @@ -19,9 +19,9 @@ endif MODCFLAGS = @GTK_X11_CFLAGS@ LIBS = @GTK_X11_LIBS@ -MODCFLAGS += -DGTK_DISABLE_DEPRECATED -MODCFLAGS += -DGDK_DISABLE_DEPRECATED -MODCFLAGS += -DGSEAL_ENABLE +#MODCFLAGS += -DGTK_DISABLE_DEPRECATED +#MODCFLAGS += -DGDK_DISABLE_DEPRECATED +#MODCFLAGS += -DGSEAL_ENABLE # XXX: Does not work because of a path issue, needs to be fixed. #MODLDFLAGS += -Wl,--version-script=linker-script diff --git a/src/modules/frontend/gtk/align_text_renderer.c b/src/modules/frontend/gtk/align_text_renderer.c index e85832c..ff5cbf8 100644 --- a/src/modules/frontend/gtk/align_text_renderer.c +++ b/src/modules/frontend/gtk/align_text_renderer.c @@ -203,7 +203,11 @@ static PangoLayout * get_layout(AlignTextRenderer * renderer, } static void align_text_renderer_get_size( +#if GTK_CHECK_VERSION(3,0,0) +GtkCellRenderer * cell, GtkWidget * widget, const GdkRectangle * cel
Re: More cdebconf patches
Hi, I'm sorry I didn't follow up to earlier mails about cdebconf patches, haven't been able to process enough other requests… Regis Boudin (2016-01-10): > I just pushed a couple of patches for cdebconf-gtk. Besides removing > conditional code to handle old versions of glib, the main change is > for the display of text in the banner, done directly with cairo, thus > removing the last bit of deprecated GDK code. I believe I've > reproduced the same behaviour ; but if you notice something different > I might have missed, please shout. IIRC we mostly use this for things like rescue mode, did you check this with various languages/fonts (esp. CJK)? > The next patch could be the one attached. It makes it possible to > chose at configure time to compile for either GTK+2 or GTK+3, and in > this version compiles the udeb for GTK+2, and the deb for GTK+3. Great, I suppose this totally obsoletes my pu/gtk3 branch then. I'm not totally convinced by building one with gtk2 and the other with gtk3 though. Some things which come to mind for a gtk3 switch in d-i: - we need theming - we need to check theme=dark has some equivalent - we now need to check that ctrl-+/- still works - we need to update the freeze hints - we need to make sure there are no uninstallable udebs; this used to be the case, that was solved a few times, but we now have a bogus dependency on libepoxy0 (#788703). - [ what am I forgetting? ] Once everything is ready I think switching both cdebconf deb/udeb to gtk3 at the same time would make more sense. (OTOH getting some gtk3 testing through the deb would be nice; but I'm not sure how common that is, and how useful that'll be to test it from outside d-i.) > Unfortunately the #if in the code are rather ugly ; but my attempts at > making it cleaner ended with something even less readable, so I left > them that way. And there's only 6 occurrences, so it's not that bad. Those are fine with me. > Any thought about whether I should merge this patch ? If yes, about > enabling GTK+3 for the deb ? The src/modules/frontend/gtk/Makefile.in changes look like something that might have been needed during development, but that shouldn't be needed anymore now that we have a clean patch? For configure.ac, I think I'd prefer if we could align things a bit to get better readability (but that's entirely subjective, and not a reason not to merge the patch in its current state). I've tweaked this part of your diff to show what I mean: > --- a/configure.ac > +++ b/configure.ac > @@ -148,15 +148,18 @@ if test -z "$FRONTEND_MODULES"; then > PKG_CHECK_EXISTS([slang], [FRONTEND_MODULES="$FRONTEND_MODULES slang"], > [AC_MSG_WARN([cannot build Slang frontend])]) > fi > > +FRONTEND_MODULES_BUILD="" > for frontend in $FRONTEND_MODULES; do > case $frontend in > - gtk) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 >= > 2.24 pango gdk-pixbuf-2.0]);; > - ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses]);; > - newt) PKG_CHECK_MODULES([NEWT],[libnewt slang]);; > - slang) PKG_CHECK_MODULES([SLANG],[slang]);; > - *);; > + gtk|gtk2) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-2.0 > >= 2.24 pango gdk-pixbuf-2.0], > + > [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);; > + gtk3) PKG_CHECK_MODULES([GTK_X11],[glib-2.0 >= 2.31 gtk+-x11-3.0 > pango gdk-pixbuf-2.0], > + > [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD gtk"]);; > + ncurses) PKG_CHECK_MODULES([NCURSES],[ncurses], > + > [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD ncurses"]);; > + newt) PKG_CHECK_MODULES([NEWT],[libnewt slang], > + > [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD newt"]);; > + slang)PKG_CHECK_MODULES([SLANG],[slang], > + > [FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD slang"]);; > + *) FRONTEND_MODULES_BUILD="$FRONTEND_MODULES_BUILD $frontend";; > esac > done > +FRONTEND_MODULES="$FRONTEND_MODULES_BUILD" Mraw, KiBi. signature.asc Description: Digital signature
Debian Installer Stretch Alpha 5 release
The Debian Installer team[1] is pleased to announce the fifth alpha release of the installer for Debian 9 "Stretch". Important change in this release of the installer = * The i386 architecture now requires 686-class processors: https://lists.debian.org/debian-devel/2015/09/msg00589.html Improvements in this release * at-spi2-atk: - Enable accessibility for all desktops (#786674). * cdebconf: - Add support for showing/hiding characters typed in password field with the GTK+ and Newt frontends (#700924). - Add Control-+/- shortcuts to adjust font size. * debian-installer: - Adjust proposed-updates support to handle file:// instead of http:// and ftp:// only (#803711). - bootscr.mainline_common: Prefer newer u-boot distro_bootpart variable. - Apply various improvements for build reproducibility. - Bump linux kernel version from 4.2.0-1 to 4.3.0-1. - Replace the module-init-tools build-dep with a kmod one. - Fix new warnings with perl 5.22 (#808875). * hw-detect: - Fix a hang during ethdetect (#803769). * installation-report: - Include /proc/device-tree/model to gather information on DT-based machines (#807625). * netcfg: - ethtool-lite: read the kernel's carrier detection result from sysfs on Linux (#591012). - Default wireless_security_type to WPA (#798373). * win32-loader: - Switch d-i.debian.org URIs from http to https. Hardware support changes * debian-installer: - Update i386 config to use 686 kernel flavour instead of 586. - Include leds-modules on armhf if available. - Provide u-boot and SD-card images for the LinkSprite pcDuino. - Add the part_gpt module into the core grub image; include support for GPT partition tables as well as msdos (#789600). - Remove minix-modules from the orion5x network-console image (support for D-Link DNS-323 was dropped previously). - Exclude usb-serial-modules from the armel network-console image since it's not useful there (#809301). - Exclude usb-modules explicitly on armel/orion5x network-console to work around a bug in util/pkg-list. - Stop including sata and ext2/ext3 modules on the armel/orion5x network-console image due to size limitations on QNAP TS-x09. - Re-introduce installer images for QNAP TS-x09. - Recognize /dev/disk1_1 and /dev/ls_disk1_1 as boot devices on Linkstation (#722735). - Add initial support for sparc64. * debian-installer-utils: - Add support for NVMe devices (#799117). * libdebian-installer: - armel: Add kirkwood mapping for the Iomega Iconnect dtb. * linux: - [armhf] udeb: Add stmmac platform modules dwmac-generic, dwmac-socfpga and dwmac-sunxi to nic-modules (#805098). - udeb: Add dm-service-time to multipath-modules (#806131). - udeb: Add hid-chicony to input-modules (#766570). - [armhf] udeb: Add leds-modules package containing leds-gpio driver (#807721). - [s390x] udeb: Add crc-modules package (#808051). - [armhf] udeb: Add more USB PHY drivers to usb-modules. - [armhf] udeb: Add modular clock, GPIO, PCIe PHY and regulator drivers to core-modules (#809521). * u-boot: - Build rockchip package, with firefly-rk3288 as the initial target (#803166). - u-boot-sunxi: Enable the A20-Olimex-SOM-EVB target (#803335). - Add config_distro_bootcmd support for various targets. - Patch mx6cuboxi to specify the baudrate in the console setting. - u-boot-sunxi: Enable the A10s-OLinuXino-M target (#806151). - u-boot-imx: Add novena patches to include fdtfile variable, and load fdt file into correct address. - u-boot-sunxi: Backport patches from upstream to enable the Lamobo_R1 target. Localization status === * 75 languages are supported in this release. * Full translation for 11 of them. Known bugs in this release == * There seems to be no known major bug as of yet. See the errata[2] for details and a full list of known issues. Feedback for this release = We need your help to find bugs and further improve the installer, so please try it. Installer CDs, other media and everything else you will need are available at our web site[3]. Thanks == The Debian Installer team thanks everybody who has contributed to this release. 1. http://wiki.debian.org/DebianInstaller/Team 2. http://www.debian.org/devel/debian-installer/errata 3. http://www.debian.org/devel/debian-installer -- Cyril Brulebois on behalf of the Debian Installer Team signature.asc Description: Digital signature
Re: What's the deal with discover*?
[Cyril Brulebois] > This probably could have been mentioned earlier. Yes. I am sorry I did not. > Probably. I read your previous mail as “let's use isenkram-cli from > d-i”, which we can't for the reason I mentioned. Reusing its logic > (contents and/or shell scripts) could make sense though. One idea is to create a new isenkram-udeb with the relevant parts, and make it a dependency of hw-detect, and either call isenkram-autoinstall-firmware from hw-detect to install the wanted firmware packages, or provide a script to list relevant firmware packages and their sections for hw-detect to show to the user. Not quite sure which approach is best. To install firmware in /target/, I suspect using the tasksel tasks provided by isenkram-cli might be a good approach, and for those to work we just need to install isenkram-cli in /target/ before calling tasksel, so the need for an isenkram-udeb package is only to handle firmware loading before creating /target/. -- Happy hacking Petter Reinholdtsen
Re: What's the deal with discover*?
[Ben Hutchings] > Like this (patch attached)? Perhaps. I do not remember the details for firmware metadata, have only used the modalias part of appstream so far, as no firmware packages had appstream info so far. But I am very happy to see the patch, and even happier to notice the change went into unstable today. Thank you! :) I'll check it out for use by isenkram as soon as possible. -- Happy hacking Petter Reinholdtsen
Re: More cdebconf patches
On 10/01/16 21:40, Cyril Brulebois wrote: > Hi, > > I'm sorry I didn't follow up to earlier mails about cdebconf patches, > haven't been able to process enough other requests… No worries. The previous patches I pushed we rather trivial. > Regis Boudin (2016-01-10): >> I just pushed a couple of patches for cdebconf-gtk. Besides removing >> conditional code to handle old versions of glib, the main change is >> for the display of text in the banner, done directly with cairo, thus >> removing the last bit of deprecated GDK code. I believe I've >> reproduced the same behaviour ; but if you notice something different >> I might have missed, please shout. > > IIRC we mostly use this for things like rescue mode, did you check this > with various languages/fonts (esp. CJK)? Hmm, I didn't test that far. I did follow the GTK doc about migrating away from gdk_draw_layout(), and use pango_cairo_show_layout() instead, so it should be fine. >> The next patch could be the one attached. It makes it possible to >> chose at configure time to compile for either GTK+2 or GTK+3, and in >> this version compiles the udeb for GTK+2, and the deb for GTK+3. > > Great, I suppose this totally obsoletes my pu/gtk3 branch then. I'm not > totally convinced by building one with gtk2 and the other with gtk3 > though. > > Some things which come to mind for a gtk3 switch in d-i: > - we need theming > - we need to check theme=dark has some equivalent > - we now need to check that ctrl-+/- still works That one probably won't work, seeing that it modifies a file that's not used by gtk3. > - we need to update the freeze hints > - we need to make sure there are no uninstallable udebs; this used to >be the case, that was solved a few times, but we now have a bogus >dependency on libepoxy0 (#788703). > - [ what am I forgetting? ] > > Once everything is ready I think switching both cdebconf deb/udeb to > gtk3 at the same time would make more sense. (OTOH getting some gtk3 > testing through the deb would be nice; but I'm not sure how common that > is, and how useful that'll be to test it from outside d-i.) Yeah, having the possibility to do some tests through the deb, and making sure both versions compile was what I had on my mind. I also did it to check it worked. At the very least we make it possible to build for gtk3 and look at dependencies, run tests, look at themes, etc >> Any thought about whether I should merge this patch ? If yes, about >> enabling GTK+3 for the deb ? > > The src/modules/frontend/gtk/Makefile.in changes look like something > that might have been needed during development, but that shouldn't be > needed anymore now that we have a clean patch? These were indeed added by me. In theory I'd have liked to keep them for GTK2 but not for GTK3. > For configure.ac, I think I'd prefer if we could align things a bit > to get better readability (but that's entirely subjective, and not a > reason not to merge the patch in its current state). I've tweaked this > part of your diff to show what I mean: Looks good. I was thinking about doing something like that. Anyway, I've cleaned things a bit and will push a patch that builds all for gtk2. Thanks for the feedback. Regis
Re: What's the deal with discover*?
Petter Reinholdtsen (2016-01-10): > [Cyril Brulebois] > > Probably. I read your previous mail as “let's use isenkram-cli from > > d-i”, which we can't for the reason I mentioned. Reusing its logic > > (contents and/or shell scripts) could make sense though. > > One idea is to create a new isenkram-udeb with the relevant parts, and > make it a dependency of hw-detect, and either call > isenkram-autoinstall-firmware from hw-detect to install the wanted > firmware packages, or provide a script to list relevant firmware > packages and their sections for hw-detect to show to the user. Not > quite sure which approach is best. I haven't thought much about how to approach this, but I had the isenkram-udeb part in mind as well: probably the easiest/best way to share the logic here. > To install firmware in /target/, I suspect using the tasksel tasks provided > by isenkram-cli might be a good approach, and for those to work we just need > to install isenkram-cli in /target/ before calling tasksel, so the need for > an isenkram-udeb package is only to handle firmware loading before creating > /target/. I'm not sure there's a need for a task; we have apt-install which handles a queue (/var/lib/apt-install/queue) until apt has been configured in /target; see apt-install in src:debian-installer-utils. We could also just copy firmwares from d-i to /target using a finish-install script. I haven't checked what isenkram-cli does or how; I'm just mentioning various ideas. Mraw, KiBi. signature.asc Description: Digital signature
Re: More cdebconf patches
Regis Boudin, on Sun 10 Jan 2016 22:54:41 +, wrote: > > - we now need to check that ctrl-+/- still works > > That one probably won't work, seeing that it modifies a file that's not > used by gtk3. Ok, no problem. AIUI gtk3 can be just made to use the dpi information, I'll have a look at that. > At the very least we make it possible to build for gtk3 and look at > dependencies, run tests, look at themes, etc Yes, committing the code without switching allows to make development much easier :) Samuel
Bug#810654: netboot.tar.gz from debian-installer is unable to load the ext2 module
Package: debian-installer Version: 20160106 When trying to use the 'ext2' module from grub (for automation purposes), I noticed grub is unable to load because the module 'fshelp' is not provided by netboot.tar.gz grub> insmod ext2 error: file /srv/tftp/debian-installer/arm64/grub/arm64-efi/fshelp.mod not found. This is basically because build/util/grub-cpmodules assumes that 'fshelp' is already provided by efi image. Either it gets removed from build/util/grub-cpmodules or added to build/util/efi-image, not sure what would be the best solution.
Re: Bug#805321: debian-installer: builds unreproducible netboot images
Hi KiBi, Please could you or I: git cherry-pick ff722581b71778707551433e0b302e4c3a341619 into master, as-is? As described by: https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=ff722581b71778707551433e0b302e4c3a341619 this is needed for kfreebsd netboot images to be reproducible. The required functionality is provided by makefs 20100306-6, now in sid+stretch. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: More cdebconf patches
Regis Boudin (2016-01-10): > On 10/01/16 21:40, Cyril Brulebois wrote: […] > Hmm, I didn't test that far. I did follow the GTK doc about migrating > away from gdk_draw_layout(), and use pango_cairo_show_layout() instead, > so it should be fine. I meant to check this part, but see below for more important matters. > > Some things which come to mind for a gtk3 switch in d-i: […] > > - [ what am I forgetting? ] We need to check runtime. :D With the little package rebuild documented in the libepoxy bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788711#12) and a cdebconf rebuild after this single change in debian/rules: -UDEB_FRONTENDS=passthrough text newt gtk +UDEB_FRONTENDS=passthrough text newt gtk3 All I'm getting at start-up (through virt-manager if that matters in any way) is a black screen and no apparent errors in syslog, but see below. The sad part is that my old branch no longer builds due to other changes in gtk3 (a bunch of functions were deprecated/removed since then), so I can't really judge whether cdebconf or the gtk3 stack isn't behaving as expected. But. I'm getting the same results without building the udeb against gtk3. Bisecting from 0.201 led to this commit being the first bad one: | commit ae9f8d0f40eecceb7c42a77300a89b9ee86dfb05 | Author: Regis Boudin | Date: Sat Jan 9 18:11:39 2016 + | | First shot at being able to build for either GTK+2 or GTK+3 Looking at it, it seems the following part of the diff is strange (src/modules/frontend/gtk/screenshot.c): | width = gdk_window_get_width(gdk_window); | height = gdk_window_get_height(gdk_window); | +#if GTK_CHECK_VERSION(3,0,0) | pixbuf = gdk_pixbuf_get_from_drawable( | NULL /* allocate a new pixbuf */, gdk_window, | gdk_colormap_get_system(), 0 /* src_x */, 0 /* src_y */, | +#else | +pixbuf = gdk_pixbuf_get_from_window(gdk_window, | +#endif | 0 /* dest_x */, 0 /* dest_y */, width, height); Contrary to other hunks, the if/else seems inverted: the else (gtk2) bit is getting the new code while the if (gtk3) gets the old one. nm seems to confirm this: /usr/lib/x86_64-linux-gnu/libgtk-3.so → U gdk_pixbuf_get_from_window /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so → U gdk_pixbuf_get_from_drawable The black screen seems easily explained by some missing symbols, leading to a UI crash (nothing shows up when grepping for gtk in /proc/*/maps). Inverting the logic fixes the black screen with gtk2, so I'm about to commit it. Going back to a gtk3 build, I'm again getting a black screen, because something is trying to open libGL.so.1; the only hit in the temporary build tree is libepoxy (unsurprisingly, since that's an OpenGL wrapper). I'll be poking the libgtk-3-0-udeb bug report to see if we could do without pulling libepoxy/libGL… > At the very least we make it possible to build for gtk3 and look at > dependencies, run tests, look at themes, etc Sure, thanks for that! > These were indeed added by me. In theory I'd have liked to keep them for > GTK2 but not for GTK3. OK. Not a big deal anyway. Mraw, KiBi. signature.asc Description: Digital signature
Re: More cdebconf patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > Looking at it, it seems the following part of the diff is strange > (src/modules/frontend/gtk/screenshot.c): | width = > gdk_window_get_width(gdk_window); | height = > gdk_window_get_height(gdk_window); | +#if GTK_CHECK_VERSION(3,0,0) > | pixbuf = gdk_pixbuf_get_from_drawable( | NULL /* > allocate a new pixbuf */, gdk_window, | > gdk_colormap_get_system(), 0 /* src_x */, 0 /* src_y */, | +#else | > +pixbuf = gdk_pixbuf_get_from_window(gdk_window, | +#endif | > 0 /* dest_x */, 0 /* dest_y */, width, height); > > Contrary to other hunks, the if/else seems inverted: the else > (gtk2) bit is getting the new code while the if (gtk3) gets the old > one. nm seems to confirm this: > /usr/lib/x86_64-linux-gnu/libgtk-3.so → U > gdk_pixbuf_get_from_window > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so → U > gdk_pixbuf_get_from_drawable Indeed it is inverted. And with the screenshot feature not getting built for deb, I managed to miss it. Combined with the fact I've had to disable -Werror because of some gcc warning flags. I'll try to see if I can fix the warnings, unfortunately we use asprintf quite a lot. > The black screen seems easily explained by some missing symbols, > leading to a UI crash (nothing shows up when grepping for gtk in > /proc/*/maps). Actually, what happens is that dlopen() fails to load the plugin because all symbols cannot be resolved (been there with my tests). But that's more informative. > Inverting the logic fixes the black screen with gtk2, so I'm about > to commit it. Thanks, that was definitely the right thing to do, as it would otherwise break gtk2 as well. > Going back to a gtk3 build, I'm again getting a black screen, > because something is trying to open libGL.so.1; the only hit in the > temporary build tree is libepoxy (unsurprisingly, since that's an > OpenGL wrapper). Oh dear. that sounds... big. But unsurprising, with dlopen failing, just like in the previous case. > I'll be poking the libgtk-3-0-udeb bug report to see if we could > do without pulling libepoxy/libGL… Well, that's at least one thing this patch will have been useful to find out and try to track. Thanks a lot for the prompt testing and bug fixing. Regis
d-i/cdebconf vs. gtk3/libepoxy?
Hi again, Cyril Brulebois (2016-01-11): > Emilio Pozuelo Monfort (2015-06-14): > > gtk+ 3.0 now depends on libepoxy, so we need a libepoxy udeb. > > The attached patch seems to do the trick. With it I was able to rebuild > gtk+3.0 so that its udeb gets the proper dependency, and to build a > netboot-gtk mini.iso Debian Installer image with the resulting udebs. > > I'm getting a black screen at start-up though, which might just be > insufficient or incorrect porting in the cdebconf gtk frontend when > built against gtk3. This will be discussed on debian-boot@: > https://lists.debian.org/debian-boot/2016/01/msg00214.html There was an issue in cdebconf indeed, see report at: https://lists.debian.org/20160111032435.gd8...@mraw.org Next issue: It seems we need libGL.so.1 so that something built against gtk3 has a chance of being displayed (through libepoxy presumably, given its purpose/description) → now getting ENOENT and a retry loop, which is a different kind of black screen in d-i. If that was at all possible, it would be nice if we could avoid pulling mesa inside d-i, and maybe disable libepoxy in src:gtk+3.0 for its udeb. libepoxy doesn't seem to be optional there though… If that can't be done, sticking with gtk2 might be an option… :( Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#805321: debian-installer: builds unreproducible netboot images
Hi, Steven Chamberlain (2016-01-11): > Please could you or I: > git cherry-pick ff722581b71778707551433e0b302e4c3a341619 > into master, as-is? > > As described by: > https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=ff722581b71778707551433e0b302e4c3a341619 > this is needed for kfreebsd netboot images to be reproducible. The > required functionality is provided by makefs 20100306-6, now in > sid+stretch. Feel free to go ahead. Mraw, KiBi. signature.asc Description: Digital signature
Re: More cdebconf patches
Regis Boudin (2016-01-11): > Indeed it is inverted. And with the screenshot feature not getting > built for deb, I managed to miss it. Combined with the fact I've had > to disable -Werror because of some gcc warning flags. > I'll try to see if I can fix the warnings, unfortunately we use > asprintf quite a lot. > > > The black screen seems easily explained by some missing symbols, > > leading to a UI crash (nothing shows up when grepping for gtk in > > /proc/*/maps). > > Actually, what happens is that dlopen() fails to load the plugin > because all symbols cannot be resolved (been there with my tests). But > that's more informative. > > > Inverting the logic fixes the black screen with gtk2, so I'm about > > to commit it. > > Thanks, that was definitely the right thing to do, as it would > otherwise break gtk2 as well. Great, thanks for confirming. > > Going back to a gtk3 build, I'm again getting a black screen, > > because something is trying to open libGL.so.1; the only hit in the > > temporary build tree is libepoxy (unsurprisingly, since that's an > > OpenGL wrapper). > > Oh dear. that sounds... big. But unsurprising, with dlopen failing, > just like in the previous case. This is slightly different: I had checked libepoxy0's (and therefore libepoxy0-udeb's) dependencies, both as Debian packages and as ELF binaries, and those are satisfied. libepoxy implements finding libGL internally (through do_dlsym on GLX_LIB, see src/dispatch_common.c, which ends up in turn with dlsym()). > > I'll be poking the libgtk-3-0-udeb bug report to see if we could > > do without pulling libepoxy/libGL… > > Well, that's at least one thing this patch will have been useful to > find out and try to track. > > Thanks a lot for the prompt testing and bug fixing. Bah, you did all the heavy work. I'm only pointing out what isn't working yet. ;) Mraw, KiBi. signature.asc Description: Digital signature
Re: Going ahead with non-free-firmware
On Sat, 9 Jan 2016 19:27:22 -0500 Hendrik Boom wrote: > On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote: > > And btw: > > Even if Debian doesn't want to do the non-open thing now or perhaps > > generally doesn't want to allow people to opt-out of closed source > > software while keeping other non-free software, then the name > > non-free-firmware seems to break the current naming, doesn't it? > > main > > contrib > > non-free > > > > These all give the "license status" of their packages. > > But non-free-firmware, would give license status and package type. > > > > > > Oh and since this has been brought up by someone. > > It seems better if packages wouldn't be in multiple suites. > > That's also what I'd have intended with non-open, in other words, a > > package that is in non-open is only there and not also in e.g. > > non-open/firmware (and vice versa). > > Maybe closed-source would be clearer than non-open. > > -- hendrik > One thing that really bugs me about the Debian component system is failure to differentiate between software (the functional component to any computer system) and data (the non-functional component of a computer hardware/software system). Example: I personally oppose non-free software and will not install or run it. But I have no such qualms about non-free data- that is something for the free *culture* movement, not the free *software* movement- of which Debian is a project, and in which Debian should maintain its focus. The inclusion of both non-free software and data in non-free means that in order to use, say, AlienArena, which is free software but relies on non-free data, one must enable both non-free and contrib! It is a pretty silly situation- that in order to play a free game one must sacrifice their freedom and enable the non-free component. I would divide the Debian package repository as follows: 1. free-software This would be for free software. 2. free-data This would be for free data. 3. non-free-software This would be for non-free software. 4. non-free-data This would be for non-free data. One could go even further and divide the non-free-software component into components based on exactly *what* freedom is being withheld- so 'drm' (for freedom 0), 'no-source' (for freedom 1), 'non-redistributable' (for freedom 2) and 'non-modifiable' (for freedom 3) or something along those lines. Of course, being a free software fanatic myself, I would prefer that Debian just stopped encouraging the use of and distributing non-free software, but since that isn't happening anytime soon, I see this as the best solution.
Re: Debian Installer Stretch Alpha 5 release
On Sun, 10 Jan 2016 23:39:35 +0100 Cyril Brulebois wrote: > The Debian Installer team[1] is pleased to announce the fifth alpha > release of the installer for Debian 9 "Stretch". > > > Important change in this release of the installer > = > > * The i386 architecture now requires 686-class processors: >https://lists.debian.org/debian-devel/2015/09/msg00589.html Why not just call it i686 then, in the Arch style?
Re: Debian Installer Stretch Alpha 5 release
* Adam Wilson [2016-01-11 07:41]: > > * The i386 architecture now requires 686-class processors: > >https://lists.debian.org/debian-devel/2015/09/msg00589.html > > Why not just call it i686 then, in the Arch style? i386 is the name of the architecture for historical reasons. If we were to rename the port, we'd have to re-compile the whole archive and upgrades wouldn't be as smooth because the architecture name would have changed. It's just not worth the hassle. -- Martin Michlmayr http://www.cyrius.com/
Re: Going ahead with non-free-firmware
On Sat, 9 Jan 2016 20:56:08 +0800 Paul Wise wrote: > On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote: > > > I think there was consensus to introduce the non-free-firmware section > > and move the non-free firmware blobs there. I'm wondering what we need > > to do next? > > I have a question about the implementation; will non-free firmware be > in non-free and non-free-firmware or just non-free-firmware? > If one wanted both non-free firmware and other non-free packages one would simply enable both non-free and non-free-firmware. There need be no duplication of package placement.
Re: Reiser4-enabled Debian Unstable (Sid) netboot iso
On Thu, 7 Jan 2016 00:11:27 -0800 Jose R R wrote: > On Wed, Jan 6, 2016 at 2:19 AM, Jose R R wrote: > > Niltze, all- > > > > I have been building iterations of Debian-Installer (d-i) enhanced > > with Reiser4 4.0.1 kernel, disk and filesystem utilities. Thus far I > > have used a local build on Debian Sid of VirtualBox 5.0.10 environment > > to test multiple Reiser4 installations. > > > > For flexibility, especially if you are testing in a VM, the following > > d-i options may help: > > > > -Network-console: continue installation remotely using SSH > > -Openssh-client-udeb: secure shell client for the Debian installer > > > > Now: > > > > d-i offers three(3) choices: > > > > Jessie (stable) > > Stretch (testing) > > Sid (unstable) > > > > I have verified that *all* can be installed from my custom Reiser4 > > d-i; Nevertheless Jessie (stable) needs access to testing and/or > > unstable repositories added at /etc/apt/sources.list in order to > > fulfill dependencies of the unstable kernel in my d-i. Jessie (stable) > > also needs to have newer Reiser4 4.0.1 packages because d-i downloads > > the older (stable) version. I have covered *all* of Jessie conditions > > by building newer unstable versions of its requirements. The downside > > of it is that a user needs to manually intervene at the shell, > > possibly at the expert level. > > Important note for Jessie: > Opening a shell in the installer environment prior to d-i menu > suggesting to install GRUB, enter: > > chroot /target > > Modify /etc/initramfs-tools/modules file by adding directives > > crc32c_intel > reiser4 > > at the end of the file and saving the modifications, > > And *prior* to installing the Reiser4 -enabled kernel make sure to > replace the older reiser4progs 1.0.9 with the newer reiser4progs > 1.1.0-1.1 -- which may be downloaded from previously posted link, > i.e.: > > http://metztli.it/readOnlyEphemeral/reiser4progs-4.0.1.tar > > These last utilites will require download access to Stretch or Sid (Unstable) > for instance adding a line: > deb http://httpredir.debian.org/debian sid main non-free contrib > > in /etc/apt/sources.list and performing apt-get update > > to fulfill dependencies needed in Jessie: > > libncurses5 > libncursesw5 > libreadline5 > libtinfo5 > > The above is necessary since when the Reiser4 -enabled kernel is > installed, it will trigger initramfs-tools creation of > initrd.img-xyz-amd64 which *should* have newer reiser4progs 1.1.0-1.1 > file utilities. > > Optional: parted-reiser4_3.2-12 dependencies form Stretch and/or > Sid(Unstable): > > dmsetup > libdevmapper1.02.1 > > > > > As for Stretch and Sid, manual intervention is required only to modify > > /etc/initramfs-tools/modules file by adding at the end: > > > > crc32c_intel > > reiser4 > > > > *before* installing the custom Reiser4 kernel, thus: > > dpkg -i linux-image-4.3.0-1-amd64_4.3.3-5_amd64.deb > > > > so that initramfs can be appropriately updated *before* rebooting the > > new Reiser4 installation. > > > > Note that GRUBX does not support booting from /boot Reiser4 > > filesystem; accordingly, a small partition must be provisioned for > > booting into a Reiser4 -formatted root (/) partition. The d-i > > partman-reiser4 will format Reiser4 partitions thus: > > > > mkfs.reiser4 -yo "create=reg40" > > > > Additionally, user may want to provision a /tmp in a non-Reiser4 > > partition if the intention is to run MariaDB (MySQL) because -- at the > > very least -- the DB will complain about /tmp issues if it is > > formatted in Reiser4 --personal experience ;-) > > > > With the above said and warning that this is an alpha effort *without* > > any explicit and/or implied guarantee that will be risk-free, here is > > the current yield of of Reiser4 effort: > > > > Reiser4 -enabled Debian-Installer (d-i) netboot mini.iso renamed as: > > http://metztli.it/readOnlyEphemeral//metztli_it-reiser4_d-i.iso > > > > Reiser4 -enabled kernel & modules.README_1st: > > http://metztli.it/readOnlyEphemeral/linux-image-4.3.0-1-amd64_4.3.3-5_amd64.tar > > > > Reiser4 -enabled Debian GNU Parted packages (install at the end of > > installation procedure); please note that those packages under > > reiser4-parted_3.2-12/misc are optional): > > http://metztli.it/readOnlyEphemeral/reiser4-parted_3.2-12.tar > > (after untarring above referenced, install as) > > cd reiser4-parted_3.2-12 > > dpkg -i parted_3.2-12_amd64.deb libparted2_3.2-12_amd64.deb > > > > Next resource is only needed if Jessie was installed. Package below > > will replace the older Reiser4 file utilities: > > http://metztli.it/readOnlyEphemeral/reiser4progs-4.0.1.tar > > > > Although I have created patches for most (or all ;-) of the above at > > GitHub, I realize Debian Unstable (Sid) is a fast moving development > > effort and within a couple of weeks the kernel referenced above will > > be outdated and d-i will refuse to install. > > > > With the previous statement said, and if anyone is willi
Re: Reiser4-enabled Debian Unstable (Sid) netboot iso
Adam Wilson (2016-01-11): > This is somewhat off-topic, but why was ReiserFS support removed from > d-i? I am a big fan of Reiser3 personally, but I use XFS now. In linux's changelog: | linux (3.10.1-1) unstable; urgency=low | […] | * udeb: Remove obsolete and unsupported drivers and filesystems | - Remove ppa from scsi-modules | - Remove floppy-modules, irda-modules, parport-modules, plip-modules, | qnx4-modules, reiserfs-modules, ufs-modules | […] | -- Ben Hutchings Tue, 16 Jul 2013 02:06:53 +0100 It seems it was already being phased out in d-i a few years before that: https://www.debian.org/devel/debian-installer/News/2010/20101030 Mraw, KiBi. signature.asc Description: Digital signature
