Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Package: src:debian-installer Version: 20230607+deb12u5 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: sbuild-build-depends-main-dummy : Depends: linux-image-6.1.0-18-amd64 but it is not installable E: Unable to correct problems, you have held broken packages. apt-get failed. E: Package installation failed Not removing build depends: cloned chroot in use The above is just how the build ends and not necessarily the most relevant part. If required, the full build log is available here: https://people.debian.org/~sanvila/build-logs/202405/ About the archive rebuild: The build was made on virtual machines of type m6a.large and r6a.large from AWS, using sbuild and a reduced chroot with only build-essential packages. If you could not reproduce the bug please contact me privately, as I am willing to provide ssh access to a virtual machine where the bug is fully reproducible. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
Re: base-files: EFI System Partition should mount on /efi not /boot/efi
reassign 1055583 debian-installer thanks Dear debian-installer people: In this bug report, I'm asked to provide /efi as a mount point for the EFI partition. Given that base-files does not even contain /boot/efi (the supposedly "old" location), I believe this is a decision for you to make, hence the reassign. [ I would be open to include /efi in base-files, but only if you consider necessary ]. Thanks.
Bug#1068935: debootstrap: Creating buildd chroots of trixie/sid from bookworm
Package: src:debootstrap Version: 1.0.128+nmu2+deb12u1 Dear maintainer: Please make debootstrap in bookworm to follow the same rules as debootstrap in trixie/sid when creating a buildd chroot of trixie/sid (i.e. install only build-essential packages). Rationale and full explanation here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060#134 Thanks.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
Hello Luca. Thanks a lot for implementing this! I'm going to answer to an old message of yours, because I think that things have changed a little bit since then. El 18/10/23 a las 19:17, Luca Boccassi escribió: We can do an upload, but note that it won't have any effect on package builds, given the buildds use stable/oldstable - and this is not material for p-u, given the effect. [...] That was the prudent thing to do, indeed, when the change affected all suites (oldstable, stable, testing, unstable, etc). However, I see that the latest git version has introduced a small change so that only trixie and above are affected: https://salsa.debian.org/installer-team/debootstrap/-/commit/3c71d6473f746cbe15a6fa1d1cf6950773c432ee which I agree that it makes sense to avoid breaking builds for bookworm and below. As a result, the new debootstrap behaviour currently in git would be no longer dangerous to have in bookworm (for chroots of trixie and above), and now I believe it would be not only suitable but highly beneficial for proposed-updates (to be included in a future point release). What would be required for that to happen? As Sebastian pointed out, this is the right time in the release cycle to do this kind of "potentially breaking changes", and compared to the usr-merge changes that have been already put in proposed-updates, I would say this one would be way less troublesome. Thanks.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
El 30/10/23 a las 21:16, Johannes Schauer Marin Rodrigues escribió: Quoting Luca Boccassi (2023-10-18 19:17:40) We can do an upload, but note that it won't have any effect on package builds, given the buildds use stable/oldstable actually we forgot something here. The upload *does* have an effect on buildds right now even before Trixie gets released because riscv buildds (in contrast to the others) do run debootstrap from unstable, resulting in this recent build failure of src:siridb-server: https://buildd.debian.org/status/fetch.php?pkg=siridb-server=riscv64=2.0.48-1%2Bb1=1698686860=0 This was reported already by Santiago as #1027381 last year and Paul Gevers quickly did another upload of src:siridb-server fixing this. So if riscv keeps being part of the release arches for trixie, then the FTBFS bugs reported by Santiago will have real effects on buildds building packages for riscv going forward. So unless that change gets reverted in debootstrap, this class of bugs will likely go away by itself before trixie gets released. So, if I understood correctly, if a package has this bug, and it's already reported, and the maintainer does a new upload but they forget to fix the bug, then the package will FTBFS on riscv, and as a result, the package will not propagate to testing. This is actually a good thing, it means the bugs are "factually RC". So, while I personally don't see a special hurry to raise the severities of the currently reported bugs, maybe it makes sense that we start to report *new* bugs like this one as serious. Thanks.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
El 10/10/23 a las 13:46, Luca Boccassi escribió: Given the list of affected packages is short (and it's all about tzdata IIRC), how about we wait until that list is down to zero (and if you have time, maybe you could help with that?), and then merge this change? That way we don't add instability, and fix the issue at the same time. Hello. In my opinion, the main problem here is the discrepancy between policy saying "packages must build from source after BD are installed" and what actually happens in the buildds (packages with missing BD not always failing in the buildds). When there is a category of bugs which are considered important and we want to make it serious, we report the bugs first, we give plenty of time to fix them, and we finally raise the severities. We usually don't wait for the bug number to become zero, because the number of affected packages usually decays exponentially. In general, when the list of affected packages is short enough, that's usually a sign that it's already ok to make the bugs RC. Johannes has asked the RMs in this thread: https://lists.debian.org/debian-release/2023/10/msg00425.html if they are ready to consider the bugs as RC. I believe it would be better if we can make the bugs "factually" RC by uploading the fixed debootstrap first. After that, complains about this kind of bugs not happening in the buildds or being difficult to reproduce should stop completely, and as far as I'm concerned, the underlying problem will be solved. In fact, we could upload deboostrap already and still have a moratorium on already reported bugs. For example, we could agree on not raising the severities for three months on old bugs. This way we give even more time for people to fix those bugs, NMUs would not be needed, but anybody trying to upload an affected package without fixing the bug will see that it will not work in the buildds. That was, after all, the whole idea in this bug, to optimize the way these kind of bugs are detected by detecting them in the buildds. I believe we would be nice enough to people if we do that (i.e. fixing debootstrap now, and delaying severity change a little more if we really want to give more time). Thanks.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
El 28/9/23 a las 11:50, Julien Cristau escribió: I still think that is absolutely the wrong thing to do, and makes debootstrap more fragile for no good reason. Julien, I believe you are mixing two different things here. (A) What this bug is really about. (B) What the effect of the bug is. The bug (A) is that debootstrap, being the tool used to create chroots to build packages, has the responsibility of ensuring that the chroot is composed by build-essential packages only, and it should try hard not to install packages which are not build-essential. In other words, the bug says that the algorithm followed by debootstrap to determine which packages should be installed is *flawed*. Then there is the effect of the bug (B). The effect, obviously, is that we end up having non-build-essential packages in a chroot when using the buildd profile, which is definitely not ok. Why do you suggest that we fix only the effects of the bug but not the bug itself? In other words: Why are you apparently mixing (A) and (B) as if they were the same thing? True, the ftpmasters might change priorities so that debootstrap does the right thing by default, but this would be "by pure chance", as the algorithm would still be wrong. Even if they change the priorities today, it would suffice that some day another essential package becomes non-essential but still required, and then we would have to wait another seven years for debootstrap to do the right thing again. We could avoid all that by fixing debootstrap once and for good. If you think a particular package shouldn't be priority:required then file a bug against ftp.debian.org to change it. That may also be true, but it's not the bug that was reported here. Thanks.
Bug#1032219: apt-setup: Regression in a string which was correctly translated (es.po)
Package: apt-setup
Version: 1:0.177
Tags: patch
Hello.
After trying debian-installer alpha2 today I've noticed there is an
error in debian/po/es.po for the string "release updates",
introduced in commit 11c8e244 dated 2023-02-07.
Apparently, somebody has misinterpreted it as if "release" acted
as a verb and "updates" was the direct object of such verb (!).
The end result is a screen like this:
[ ] actualizaciones de seguridad (de security.debian.org)
[ ] Publicar actualizaciones
[ ] programas migrados a nuevas versiones
The old translation ("actualizaciones de la distribución")
was essentially correct (except that the previous extra ":"
is not needed).
(X-Debian-CC to debian-l10n-span...@lists.debian.org in
case they want to comment on this).
Patch attached.
Thanks.--- a/debian/po/es.po
+++ b/debian/po/es.po
@@ -219,7 +219,7 @@ msgstr "actualizaciones de seguridad (de ${SEC_HOST})"
#. :sl1:
#: ../apt-setup-udeb.templates:11001
msgid "release updates"
-msgstr "Publicar actualizaciones"
+msgstr "actualizaciones de la distribución"
#. Type: multiselect
#. Choices
Bug#1031828: debootstrap: Please document --usr-merge option in --help output
severity 1031828 normal tags 1031828 - patch retitle 1031828 debootstrap: Please document --usr-merge option in --help output thanks El 24/2/23 a las 0:12, Luca Boccassi escribió: Please see: https://lists.debian.org/debian-ctte/2022/09/msg5.html Ok, did read, but also too long, and that was before the changes made on 2022-11. I don't use debootstrap every day. Instead, I usually upgrade already existing chroots from the bookworm of yesterday to the bookworm of today. As a result, my chroots were naturally upgraded to usr-merge. If this is not supposed to happen, I would ideally like to see it documented somewhere (but I could agree that debootstrap is not to blame for that). So, if the buildds are still running non-usr-merged chroot, can you at least document the --usr-merge option which already exists? It will certainly be needed when creating chroots for trixie from bookworm, so I would say it should be documented (I guess that would be a one line change). I'm retitling the bug accordingly. Thanks.
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
El 23/2/23 a las 22:26, Luca Boccassi escribió: On Thu, 23 Feb 2023 at 20:50, Santiago Vila wrote: The buildds already did the switch several months ago. Wait, what? Specific changes were made to debootstrap in order to allow the buildd machines to stay un-merged, as the CTTE wanted, Can you elaborate on that? What you say sounds as something that could be said two years ago before the release of bullseye, i.e. newly installed systems have usr-merge by default but we keep building packages on not usr-merged chroots. When did the switch happen, and how? I believe it was sometime in 2022-11, but I can't tell for sure. I believe it happened because I sometimes monitor debian-bugs-rc and at some point bugs about packages which FTBFS on usr-merged systems became serious. Sorry not to be more precise. I hope somebody who knows better can answer. ( In case it's confirmed that the buildds are already using usr-merge for bookworm and sid, would you agree that the debootstrap program in bookworm should do the same by default? ) Thanks.
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
El 23/2/23 a las 21:38, Luca Boccassi escribió: It's too soon for this. I think the right time will be the first point release of Bookworm - at that point we can get the buildds to switch too. But the release should be built in the current default as per CTTE's instructions. The buildds already did the switch several months ago. Thanks.
Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later
Package: debootstrap
Version: 1.0.128+nmu2
Severity: important
Tags: patch
Dear maintainer:
Because Debian has decided that bookworm will have
usr-merge by default even for building packages,
I would expect usr-merge to be enabled by default
in all cases, including when using the buildd profile.
Currently, such thing does not happen.
I think the attached patch would fix this
(but I've not tested it).
A better approach would be to select --usr-merge
in the buildd profile when appropriate (i.e. bookworm
and above). (How feasible would this be?)
I am aware that the proposed patch (but not the "better approach")
may force some people to do some things differently.
However, let's compare the two scenarios:
A) If the patch is applied, then once that bookworm becomes stable:
- Those who want to build packages for stable the official way
do not have to do anything special. I think this is the category
of users that should be better supported.
- Those still running bullseye who want to build packages for
bullseye (using debootstrap from bullseye) do not have to do
anything special.
- Only people who want to build packages for bullseye from
bookworm would have to add --no-usr-merge by hand, and only
when using the buildd profile. I think this is a special case
and having to add an option by hand for such special case would
not be a big deal.
B) If the patch is not applied, then once that bookworm becomes stable:
- Those who want to build packages for stable the official way
should add --usr-merge by hand when calling debootstrap.
This option is *undocumented* in "debootstrap --help" (!).
Also, failure to add the --usr-merge option may result in packages
being misbuilt, or even failing to build at all. And this would
happen when building packages from stable to be installed in a
stable system.
- Those still running bullseye who want to build packages for
bullseye (using debootstrap from bullseye) do not have to do
anything special.
- Those who want to build packages for bullseye from bookworm
would not have to do anything special.
In summary: I think A is better default than B for bookworm, and
I believe it would be ok to change debootstrap default behaviour
before the release.
In either case, if debootstrap behaviour is not going to change
for bookworm, then option --usr-merge should be much better
documented, both in --help output and maybe in Release Notes.
Thanks.--- a/functions
+++ b/functions
@@ -1367,7 +1367,7 @@ setup_dselect_method () {
# either installs the RTLD in a directory different from /lib or builds
# multilib library packages.
setup_merged_usr() {
- if doing_variant buildd && [ -z "$MERGED_USR" ]; then
+ if [ -z "$MERGED_USR" ]; then
MERGED_USR="no"
fi
Bug#837060: Undeclared dependencies on tzdata
[ Adding 837...@bugs.debian.org and the submitter to Cc for the reasons explained below ]. El 22/11/22 a las 13:09, Guillem Jover escribió: So it seems to me we have a bunch of packages that are prio:required but not Essential (some have switched to Protected:yes), that should get their priority lowered to (at least to) important: debconf e2fsprogs libpam-modules libpam-modules-bin libpam-runtime mount passwd tzdata So, someone should probably file a bug report against ftp.debian.org to get the overrides updated. Strictly speaking, we would not need to change priorities, only the behaviour of debootstrap when using the "buildd" profile (which is used to create chroots suitable for building packages). Such suboptimal behaviour was already reported here as a bug six years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 Of course, if debootstrap maintainers and ftpmasters decide that the best way to fix this is by debootstrap continuing to install required packages "no matter what", then yes, the priorities should be downgraded, I just wanted to point out that it does not have to be the only possible solution. Thanks.
Bug#917491: debian-installer-netboot-images: FTBFS (BAD signature from "Debian Archive Automatic Signing Key (8/jessie) ")
Package: src:debian-installer-netboot-images Version: 20170615+deb9u5 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-indep dh build-indep dh_update_autotools_config -i fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i debian/rules override_dh_auto_install make[1]: Entering directory '/<>/debian-installer-netboot-images-20170615+deb9u5' if ! ./get-images.sh amd64 && [ -n "stretch" ]; then\ echo; echo; echo; \ echo "Version not found in stretch-proposed-updates, falling back to stretch"; \ echo; echo; echo; \ sleep 5; \ [... snipped ...] --2018-12-20 03:03:08-- http://deb.debian.org/debian/dists/stretch/Release.gpg Resolving deb.debian.org (deb.debian.org)... 149.20.4.15, 130.89.148.14, 128.31.0.62, ... Connecting to deb.debian.org (deb.debian.org)|149.20.4.15|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://cdn-fastly.deb.debian.org/debian/dists/stretch/Release.gpg [following] --2018-12-20 03:03:08-- http://cdn-fastly.deb.debian.org/debian/dists/stretch/Release.gpg Resolving cdn-fastly.deb.debian.org (cdn-fastly.deb.debian.org)... 151.101.120.204, 2a04:4e42:1d::204 Connecting to cdn-fastly.deb.debian.org (cdn-fastly.deb.debian.org)|151.101.120.204|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 2434 (2.4K), 833 remaining Saving to: '/<>/debian-installer-netboot-images-20170615+deb9u5/Release.gpg' 0K ,.100% 44.9M=0s 2018-12-20 03:03:08 (44.9 MB/s) - '/<>/debian-installer-netboot-images-20170615+deb9u5/Release.gpg' saved [2434/2434] --2018-12-20 03:03:08-- http://deb.debian.org/debian/dists/stretch/Release Resolving deb.debian.org (deb.debian.org)... 149.20.4.15, 130.89.148.14, 128.31.0.62, ... Connecting to deb.debian.org (deb.debian.org)|149.20.4.15|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://cdn-fastly.deb.debian.org/debian/dists/stretch/Release [following] --2018-12-20 03:03:08-- http://cdn-fastly.deb.debian.org/debian/dists/stretch/Release Resolving cdn-fastly.deb.debian.org (cdn-fastly.deb.debian.org)... 151.101.120.204, 2a04:4e42:1d::204 Connecting to cdn-fastly.deb.debian.org (cdn-fastly.deb.debian.org)|151.101.120.204|:80... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 117946 (115K), 23339 (23K) remaining Saving to: '/<>/debian-installer-netboot-images-20170615+deb9u5/Release' [ skipping 50K ] 50K ,, ,, ,, ,, ,, 86% 2.13G 0s 100K .. . 100% 16.8M=0.001s 2018-12-20 03:03:08 (24.6 MB/s) - '/<>/debian-installer-netboot-images-20170615+deb9u5/Release' saved [117946/117946] gpgv: Signature made Wed Dec 19 20:22:50 2018 UTC gpgv:using RSA key A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553 gpgv: Can't check signature: No public key gpgv: Signature made Wed Dec 19 20:22:50 2018 UTC gpgv:using RSA key 126C0D24BD8A2942CC7DF8AC7638D0442B90D010 gpgv: BAD signature from "Debian Archive Automatic Signing Key (8/jessie) " make[1]: *** [debian/rules:20: get-images-amd64] Error 1 make[1]: Leaving directory '/<>/debian-installer-netboot-images-20170615+deb9u5' make: *** [debian/rules:15: binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" but it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/debian-installer-netboot-images.html where you can get a full build log if you need it. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
Bug#902226: debian-installer-netboot-images: FTBFS in stretch, even when allowing network access
Package: src:debian-installer-netboot-images Version: 20170615+deb9u3 Tags: ftbfs Dear Debian Installer people: Even when we allow network access in the autobuilder, building this package no longer works since version 20170615+deb9u1. --- Connecting to cdn-fastly.deb.debian.org (cdn-fastly.deb.debian.org)|151.101.132.204|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 20 [application/x-gzip] Saving to: 'amd64.Packages.gz' 0K 100% 7.00M=0s 2017-07-22 15:38:16 (7.00 MB/s) - 'amd64.Packages.gz' saved [20/20] amd64.Packages.gz: OK Building 20170615+deb9u1, but stretch-proposed-updates has , failing the build debian/rules:19: recipe for target 'get-images-amd64' failed make[1]: *** [get-images-amd64] Error 1 --- Without using any special flag or environment variable, what I would expect is that it downloads things from stretch as well, as every point release of stretch should ideally be "self-contained" for building purposes. I see this line in debian/rules: export DISTRIBUTION?=stretch-proposed-updates Maybe that's the problem. I'm putting all my build logs here for you to see: https://people.debian.org/~sanvila/build-logs/debian-installer-netboot-images/ You will see that version 20170615 of this package used to build ok in the past. [ Note: I fear that this could be another wontfix bug, like the one complaining about network access, so I will not bother to set a severity, but I still believe that for consistency, packages in stretch should be buildable in stretch by default, even when they need network access ]. If, after all, you consider that the cure is worse than the disease, then please consider this as a documentation bug and if possible explain somewhere why we are not expected to build this package without failures ]. Thanks.
Bug#858104: win32-loader: FTBFS (error parsing Built-Using field)
Package: src:win32-loader Version: 0.8.1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" but it failed: [...] debian/rules build-indep /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator dh build-indep dh_testdir -i dh_update_autotools_config -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>' /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator /bin/sh: 1: test: xloadlin: unexpected operator [... snipped ...] Total size: 632178 / 1137727 bytes (55.5%) 1 warning: Generating version information for language "1033-English" without standard key "FileVersion" du -h win32-loader.exe 620Kwin32-loader.exe make[2]: Leaving directory '/<>' make[1]: Leaving directory '/<>' dh_auto_test -i create-stamp debian/debhelper-build-stamp fakeroot debian/rules binary-indep /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator dh binary-indep create-stamp debian/debhelper-build-stamp dh_testroot -i dh_prep -i dh_auto_install -i dh_install -i dh_installdocs -i dh_installchangelogs -i dh_perl -i dh_link -i dh_strip_nondeterminism -i dh_compress -i dh_fixperms -i dh_installdeb -i debian/rules override_dh_gencontrol make[1]: Entering directory '/<>' /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator /bin/sh: 1: test: xloadlin: unexpected operator /bin/sh: 1: test: xnsis: unexpected operator dh_gencontrol -- -Vw32-loader:built-using="grub2 (= 2.02~beta3-5), cpio (= 2.11+dfsg-6), gzip (= 1.6-5), gnupg2 (= 2.1.18-6), debian-archive-keyring (= 2014.3), loadlin (1.6f-5) (= 1.6f-5+b1), ipxe (= 1.0.0+git-20161027.b991c67-1), nsis (2.51-1) (= 2.51-1+b1), libgcrypt20 (= 1.7.6-1), libgpg-error (= 1.26-2), " dpkg-gencontrol: warning: can't parse dependency loadlin (1.6f-5) (= 1.6f-5+b1) dpkg-gencontrol: error: error occurred while parsing Built-Using field: grub2 (= 2.02~beta3-5), cpio (= 2.11+dfsg-6), gzip (= 1.6-5), gnupg2 (= 2.1.18-6), debian-archive-keyring (= 2014.3), loadlin (1.6f-5) (= 1.6f-5+b1), ipxe (= 1.0.0+git-20161027.b991c67-1), nsis (2.51-1) (= 2.51-1+b1), libgcrypt20 (= 1.7.6-1), libgpg-error (= 1.26-2), dh_gencontrol: dpkg-gencontrol -pwin32-loader -ldebian/changelog -Tdebian/win32-loader.substvars -Pdebian/win32-loader -Vw32-loader:built-using=grub2 (= 2.02~beta3-5), cpio (= 2.11+dfsg-6), gzip (= 1.6-5), gnupg2 (= 2.1.18-6), debian-archive-keyring (= 2014.3), loadlin (1.6f-5) (= 1.6f-5+b1), ipxe (= 1.0.0+git-20161027.b991c67-1), nsis (2.51-1) (= 2.51-1+b1), libgcrypt20 (= 1.7.6-1), libgpg-error (= 1.26-2), returned exit code 255 debian/rules:79: recipe for target 'override_dh_gencontrol' failed make[1]: *** [override_dh_gencontrol] Error 2 make[1]: Leaving directory '/<>' debian/rules:38: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 The same thing happens in the reproducible builds autobuilders: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/win32-loader.html so this should be easy to reproduce. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the page for this package. Thanks.
Bug#850232: installation-guide: FTBFS randomly (ERROR: xref linking to appendix-gpl has no generated link text.)
On Sun, Jan 08, 2017 at 12:55:38AM +0100, Samuel Thibault wrote: > Control: tags -1 + pending > > Hello, > > Santiago Vila, on Sat 07 Jan 2017 23:37:03 +0100, wrote: > > On Sat, Jan 07, 2017 at 11:20:35PM +0100, Samuel Thibault wrote: > > > > > Could you also post build logs which are successful? > > > > Ok, all the build logs I have, same place as before: > > > > https://people.debian.org/~sanvila/build-logs/installation-guide/ > > Ok, thanks! > > What was in common in failed builds was that it started creating xml > files from gpl.xml (depending in which order the filesystem laid > files). I could then reproduce the issue easily by starting with it. > What happens is that for 'da' there is no translation, and in that > case msgattrib does *not* create the file, and thus po2xml just fails > without an explicit error message. I fixed it by passing --force-po to > msgattrib to always create a file, even if without any translation. Reminds me of this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096#47 Was debian/rules and the various Makefiles following Policy 4.6 before the fix you applied? (i.e. errors must be trapped so that the build stops) Thanks.
Bug#850232: installation-guide: FTBFS randomly (ERROR: xref linking to appendix-gpl has no generated link text.)
On Sat, Jan 07, 2017 at 11:20:35PM +0100, Samuel Thibault wrote: > Could you also post build logs which are successful? Ok, all the build logs I have, same place as before: https://people.debian.org/~sanvila/build-logs/installation-guide/ As usual, if you find a fix please consider uploading in source-only form (dpkg-buildpackage -S), so that we always have official build logs here: https://buildd.debian.org/status/package.php?p=installation-guide Thanks.
Bug#850232: installation-guide: FTBFS randomly (ERROR: xref linking to appendix-gpl has no generated link text.)
Package: src:installation-guide
Version: 20161031
Severity: important
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
[...]
debian/rules build-indep
rm -f build-stamp
rm -rf /<>/debian/manual
set -e && cd build && \
MAKEFLAGS="-j1" \
official_build=1 manual_release=wheezy \
architectures="i386 amd64 arm64 armel armhf mips mips64el mipsel
ppc64el s390x" languages="en cs da de el es fr it ja ko pt ru sv vi zh_CN" \
destination=/<>/debian/manual/'${arch}' noarchdir=1 \
./build.sh
Generating integrated XML files and POT files
Building list of entities...
Converting XML files to UTF-8...
Merging XML files per 'chapter'...
[... snipped ...]
Writing build.out.da.i386/html/apas01.html for sect1(howto-preliminaries)
Writing build.out.da.i386/html/apas02.html for sect1(howto-getting-images)
Writing build.out.da.i386/html/apas03.html for sect1(howto-installation)
Writing build.out.da.i386/html/apas04.html for sect1(howto-installation-report)
Writing build.out.da.i386/html/apas05.html for sect1(howto-installation-finally)
Writing build.out.da.i386/html/apa.html for appendix(installation-howto)
Writing build.out.da.i386/html/apbs01.html for sect1(preseed-intro)
Writing build.out.da.i386/html/apbs02.html for sect1(preseed-using)
Writing build.out.da.i386/html/apbs03.html for sect1(preseed-creating)
Writing build.out.da.i386/html/apbs04.html for sect1(preseed-contents)
Writing build.out.da.i386/html/apbs05.html for sect1(preseed-advanced)
Writing build.out.da.i386/html/apb.html for appendix(appendix-preseed)
Writing build.out.da.i386/html/apcs01.html for sect1(partition-sizing)
Writing build.out.da.i386/html/apcs02.html for sect1(directory-tree)
Writing build.out.da.i386/html/apcs03.html for sect1
Writing build.out.da.i386/html/apcs04.html for sect1(device-names)
Writing build.out.da.i386/html/apcs05.html for sect1(partition-programs)
Writing build.out.da.i386/html/apc.html for appendix(partitioning)
Writing build.out.da.i386/html/apds01.html for sect1(linuxdevices)
Writing build.out.da.i386/html/apds02.html for sect1(tasksel-size-list)
Writing build.out.da.i386/html/apds03.html for sect1(linux-upgrade)
Writing build.out.da.i386/html/apds04.html for sect1(plip)
Writing build.out.da.i386/html/apds05.html for sect1(pppoe)
Writing build.out.da.i386/html/apd.html for appendix(random-bits)
Writing build.out.da.i386/html/apes01.html for sect1(about)
Writing build.out.da.i386/html/apes02.html for sect1(contributing)
Writing build.out.da.i386/html/apes03.html for sect1(contributors)
Writing build.out.da.i386/html/apes04.html for sect1(trademarks)
Writing build.out.da.i386/html/ape.html for appendix(administrivia)
Writing build.out.da.i386/html/index.html for book
Info: creating temporary .tex file...
openjade:build.tmp.da.i386/install.da.profiled.xml:32:178:X: reference to
non-existent ID "appendix-gpl"
openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dblink.dsl:200:1:E:
XRef LinkEnd to missing ID 'appendix-gpl'
Error: build of pdf failed with error code 1
Info: creating temporary .html file...
ERROR: xref linking to appendix-gpl has no generated link text.
Error: no ID for constraint linkend: "appendix-gpl".
Info: creating .txt file...
Warning: The following formats failed to build: pdf
Makefile:8: recipe for target 'da.i386' failed
make[1]: *** [da.i386] Error 2
make[1]: Leaving directory '/<>/build'
debian/rules:60: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
This is just how the build ends, not necessarily the relevant part.
I've put several build logs here:
https://people.debian.org/~sanvila/build-logs/installation-guide/
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the page for this package.
The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).
Thanks.
Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)
On Wed, Oct 05, 2016 at 12:22:31AM +0200, Cyril Brulebois wrote: > Hi, > > Santiago Vila <sanv...@debian.org> (2016-10-04): > > I am aware that this is the same version in jessie, but if it's not > > appropriate for stretch, then we might better have this package > > autoremoved from stretch than present and not building. > > FWIW it gets propped-up from jessie on each point release. > > It might make sense to start uploading it to unstable since we're > slowly approaching freeze time. Say: starting with the next d-i > release. I agree. That would be indeed a lot better than any of the other options. Thanks.
Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)
Package: src:debian-installer-netboot-images Version: 20150422+deb8u4.b1 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep dh_testdir -i dh_update_autotools_config -i dh_auto_configure -i dh_auto_build -i dh_auto_test -i fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i debian/rules override_dh_auto_install make[1]: Entering directory '/<>/debian-installer-netboot-images-20150422+deb8u4.b1' [... snipped ...] Connecting to httpredir.debian.org (httpredir.debian.org)|5.153.231.35|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz [following] --2016-09-17 22:40:30-- http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36 Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 20 [application/x-gzip] Saving to: 'amd64.Packages.gz' 0K 100% 5.71M=0s 2016-09-17 22:40:30 (5.71 MB/s) - 'amd64.Packages.gz' saved [20/20] amd64.Packages.gz: OK --2016-09-17 22:40:30-- http://httpredir.debian.org/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb Resolving httpredir.debian.org (httpredir.debian.org)... 128.31.0.66, 5.153.231.35, 2001:41c8:1000:21::21:35 Connecting to httpredir.debian.org (httpredir.debian.org)|128.31.0.66|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb [following] --2016-09-17 22:40:31-- http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36 Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 736654 (719K) [application/x-debian-package] Saving to: 'debian-installer_20150422+deb8u4+b1_amd64.deb' 0K .. .. .. .. .. 6% 1.11M 1s 50K .. .. .. .. .. 13% 2.84M 0s 100K .. .. .. .. .. 20% 6.38M 0s 150K .. .. .. .. .. 27% 8.54M 0s 200K .. .. .. .. .. 34% 2.55M 0s 250K .. .. .. .. .. 41% 130M 0s 300K .. .. .. .. .. 48% 14.5M 0s 350K .. .. .. .. .. 55% 10.7M 0s 400K .. .. .. .. .. 62% 2.72M 0s 450K .. .. .. .. .. 69% 93.0M 0s 500K .. .. .. .. .. 76% 1.15M 0s 550K .. .. .. .. .. 83% 2.44M 0s 600K .. .. .. .. .. 90% 206M 0s 650K .. .. .. .. .. 97% 247M 0s 700K .. . 100% 233M=0.2s 2016-09-17 22:40:31 (3.83 MB/s) - 'debian-installer_20150422+deb8u4+b1_amd64.deb' saved [736654/736654] sha256sum: debian-installer_20150422+deb8u4+b1_amd64.deb.sha256sum: no properly formatted SHA256 checksum lines found debian/rules:19: recipe for target 'get-images-amd64' failed make[1]: *** [get-images-amd64] Error 1 make[1]: Leaving directory '/<>/debian-installer-netboot-images-20150422+deb8u4.b1' debian/rules:14: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 The relevant part of the build log is included above. I am aware that this is the same version in jessie, but if it's not appropriate for stretch, then we might better have this package autoremoved from stretch than present and not building. Thanks.
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Thu, Sep 08, 2016 at 07:40:15PM +0200, Sven Joachim wrote: > | Setting up perl-base (5.22.2-5) ... > | dpkg: error: --install needs at least one package archive file argument > ` > > Looking at the code in scripts/sid, it is "x_core_install mawk" which > fails here. The reason is that mawk has not been downloaded, > debootstrap's limited dependency resolver cannot resolve base-files' > pre-dependency on awk. > > The good news is that with "--include=mawk" added to the commandline, > debootstrap succeeds and does not include tzdata or lsb-base in the > chroot. :-) > > So changing base-files to Pre-depend on mawk | awk seems to be the only > blocker here. Would you like to file a blocking bug on base-files? You don't need to change base-files for that. Package awk is essential and virtual. The dependency of base-files on awk is just to ensure that there is always an awk available (once that you already have a running system), but it's not meant to tell debootstrap which one is "the awk of preference". debootstrap already knows that, and the proof is that it deliberately installs "mawk" and no other awk implementation. If we switch from installing required packages to installing just the essential packages (which are a subset), we will miss mawk, so for all purposes, since we are bootstrapping, you should treat mawk as if it were essential. Could you please try something like this? required="mawk $(get_debs Essential: yes)" I think that should be more than enough. Thanks.
Bug#770217: cannot be run from source on !debian
Is this an issue at all considering the changes in debootstrap version 1.0.82 regarding devices.tar.gz? Thanks.
Re: Bug#835516: General: Incorrect permissions on /bin for Debian Jessie
> I did not know this Lintian tool used internally to verify the packages > automatically. That's interesting. In the thread mentioned by Adam, Yves > said that Lintian is used on testing and unstable, but he was not sure > if it is also used to stable. Do you know if that's the case? The automatic lintian checks here: https://lintian.debian.org/ are only performed on the latest version of a given package... > Because, if so, we could use this tool to automatically identify the > existence of other packages that might cause problems on the > permissions for the /bin directory. ... but nothing prevents anyone to run lintian (which is a program in a package of the same name) on each and every of the packages in stable (or only on the packages installed by default) and share the results. Thanks.
Re: Bug#835516: General: Incorrect permissions on /bin for Debian Jessie
On Sat, Aug 27, 2016 at 04:50:27PM -0300, Daniel Bareiro wrote: > El sábado 27 de agosto del 2016 a las 20:50:28 +0200, > Santiago Vila escribió: > > Reading the message by Adam carefully, this is a bug in sed. > > > > I would hope the release managers would allow this to be fixed in a > > point release. > > Hi, Santiago. > > Do you think it's a problem of sed specifically? Because Yves > mentioned two other packages (lpe and ucspi-proxy) that could also > change the permissions of /bin. It is a problem in every package having wrong permissions, but sed is always installed by default (it's even Essential: yes), while the others are not. So if we fix sed in jessie, new installs will probably have the /bin directory fixed. > What is not clear to me is why this happens in netinstall and not on > LXC. Because I believe that in both cases the same package is installed. > Or am I missing something? If you could clarify this, I would appreciate > it. Sorry, I don't know.
Re: Bug#835516: General: Incorrect permissions on /bin for Debian Jessie
reassign 835516 debian-installer thanks I think this is a bug in debian-installer, because debootstrap is apparently not affected by the umask setting (be it 002 or 022). Reassigning accordingly. Dear d-i people: Short summary: New systems installed from Debian 8 netinst image have /bin with mode 775 instead of 755. Thanks.
Bug#835516: General: Incorrect permissions on /bin for Debian Jessie
reassign 835516 sed thanks Oops. Not. Reading the message by Adam carefully, this is a bug in sed. I would hope the release managers would allow this to be fixed in a point release. Thanks.
Bug#806218: base-installer: FTBFS when built with dpkg-buildpackage -A (Directory nonexistent)
Package: src:base-installer Version: 1.157 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] debian/rules build-indep dh build-indep dh_testdir -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>' debian/templates-build.pl amd64 < debian/templates-arch > debian/templates.gen # give the new templates file the same mtime as the input file, so # that po2debconf doesn't decide that it needs to run # debconf-updatepo touch -mr debian/templates-arch debian/templates.gen /usr/bin/make small [... snipped ...] armeb: 6 passes, 0 failures. armel: 92 passes, 0 failures. armhf: 104 passes, 0 failures. hppa: 36 passes, 0 failures. i386: 314 passes, 0 failures. ia64: 22 passes, 0 failures. m68k: 14 passes, 0 failures. mips: 97 passes, 0 failures. mipsel: 85 passes, 0 failures. powerpc: 134 passes, 0 failures. ppc64el: 16 passes, 0 failures. s390x: 7 passes, 0 failures. sh4: 20 passes, 0 failures. sparc: 36 passes, 0 failures. kfreebsd-amd64: 16 passes, 0 failures. kfreebsd-i386: 32 passes, 0 failures. make[2]: Leaving directory '/<>/kernel' make[1]: Leaving directory '/<>' fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i dh_auto_install -i debian/rules override_dh_install make[1]: Entering directory '/<>' dh_install if [ -e "kernel/amd64.sh" ]; then \ install -D -m644 "kernel/amd64.sh" \ debian/bootstrap-base/usr/lib/base-installer/kernel.sh; \ fi make[1]: Leaving directory '/<>' dh_installdocs -i dh_installchangelogs -i debian/rules override_dh_installdebconf make[1]: Entering directory '/<>' dh_installdebconf (echo ; cat debian/templates.gen) >> debian/bootstrap-base/DEBIAN/templates /bin/sh: 1: cannot create debian/bootstrap-base/DEBIAN/templates: Directory nonexistent debian/rules:40: recipe for target 'override_dh_installdebconf' failed make[1]: *** [override_dh_installdebconf] Error 2 make[1]: Leaving directory '/<>' debian/rules:3: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 Sorry not to have a fix, as I am reporting many bugs similar to this one. In this case, I see that you are using "dh", which allow (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo"). Maybe using them this problem could be fixed. Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, the package would be suitable to be uploaded in source-only form if you wish. Thanks.
Bug#805994: apt-setup: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
Package: src:apt-setup Version: 1:0.102 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] fakeroot debian/rules binary-indep dh binary-indep dh_testroot -i dh_prep -i dh_auto_install -i dh_install -i dh_installdocs -i dh_installchangelogs -i debian/rules override_dh_installdebconf make[1]: Entering directory '/<>' dh_installdebconf WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed WARNING: se: spurious newline removed sed -i 's/@MULTIARCH@//' \ debian/apt-setup-udeb/DEBIAN/templates sed: can't read debian/apt-setup-udeb/DEBIAN/templates: No such file or directory debian/rules:14: recipe for target 'override_dh_installdebconf' failed make[1]: *** [override_dh_installdebconf] Error 2 make[1]: Leaving directory '/<>' debian/rules:3: recipe for target 'binary-indep' failed make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2 Sorry not to have a fix, as I am reporting many bugs similar to this one, but I can give some general hints: * If all the arch-independent packages are dummy transitional packages released with jessie, the easy fix is to drop them now. * If not, debian/rules should be modified so that the binary-indep target works in all cases, even when binary-arch is not used (this is what the "Architecture: all" autobuilder does). For that: * If you are using debhelper, you might want to use options -a and -i for dh_* commands so that they do not act on packages they do not have to act. * Also, if you are using dh, the (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo") may be useful to write a debian/rules which behaves exactly as desired. After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, this package will be suitable to be uploaded in source-only form if you wish (you might want to try it). Thanks.
Re: purging packages
On Thu, Sep 17, 2015 at 09:24:41AM +0100, Alfred Hanny wrote: > Why is it, that if i purge unwanted packages (like zeitgeist), apt > starts removing my whole gnome desktop? > This stupid behaviour cost me a whole day of re-installing my system. Please try debian-user, this list (debian-boot) is for the development of the Debian installer.
Bug#799293: tasksel: Extra directory tasks/po/INTER in source package
Package: tasksel Version: 3.33 The source for this package contains an extra directory "tasks/po/INTER" which apparently is just an old copy of "tasks/po". Suggested fix: git rm tasks/po/INTER/* Thanks. P.S. Discovered by accident. I was trying to understand why this package does currently not build reproducibly. See https://reproducible.debian.net/rb-pkg/unstable/amd64/tasksel.html for details. I would file this as a separate bug, but unfortunately I don't have a fix.
Bug#524877: installation-guide: Creating multiarch USB stick
For the record: I managed to do this a long time ago. Maybe starting with Debian 6.0, which is the release where multi-arch netinst CD image was only for amd64 and i386 (i.e. no more powerpc). I agree that the wiki seems a good place to document this, if I find the time. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1505051654560.6...@cantor.unex.es
Re: base system size
On Sat, Nov 29, 2014 at 02:48:12AM +0100, Samuel Thibault wrote: Now that perl is out of the base system again, I've had a look at the figures of a base system install. We're ~80Mib bigger, from 277MiB to 360MiB: - aptitude is not installed by default any more - -18MiB - grub got 12MiB bigger. - wget now depends on libicu52, 27MiB. - linux-image got 37MiB bigger - systemd takes about 12MiB more than sysvinit - udev got 5MiB bigger. - util-linux got 1.3MiB bigger, and added 5MiB locale data - various bloat and optimizations (bash got 1MiB bigger for instance) I was going to say something about this yesterday, but postponed the email! On a minimal system having a custom kernel, these are the installed sizes: 27324 libicu52 15877 locales 14995 grub-common 13855 coreutils 11362 systemd 10220 libc6 [...] Maybe wget is too bloated for the base system? OTOH, 277 to 360 is just a 30% increase, in approximately two years, which is probably expected following Moore's law... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129094943.ga31...@cantor.unex.es
Re: base system size
On Sat, Nov 29, 2014 at 12:13:52PM +0100, Samuel Thibault wrote: Santiago Vila, le Sat 29 Nov 2014 10:49:43 +0100, a écrit : Maybe wget is too bloated for the base system? Having a wget available has been quite convenient to me several times to easily transfer a file. We could however in the future consider packaging another, lightweight wget. Yes, I agree that wget is very convenient, and in fact it fits the What on earth! Where is wget? definition quite well, so it is unlikely that we want to replace it by something completely different. [ I was actually thinking about replacing it with curl. Unfortunately, curl puts the output on stdout by default, which means it may not be used as a drop-in replacement for wget easily ]. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129133058.ga4...@cantor.unex.es
Bug#767999: problem with debootstrap in wheezy
Note: dpkg 1.17.21 has migrated to testing, and, as a result, the current debootstrap in wheezy is now unable to create chroots for both jessie and sid (previously it was only sid and jessie still worked). As of today, in jessie we still have base-files 7.6. So, as I suspected, the recent changes in dpkg are the most likely reason why this problem didn't bite us before, not the changes I did in base-files 7.7. I hope this might definitely clarify some past misunderstandings about this problem. Thanks a lot. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411061227090.10...@cantor.unex.es
Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd
On Thu, Nov 06, 2014 at 02:06:07PM +, Michael Tautschnig wrote: [ BCC'ing Santiago, Holger, Adam, Cyril ] Hi all, I'm refraining from quoting the preceding mails as most of you will have those in their inbox, and I'd rather summarise the situation right here: At least Santiago's and my opinion diverge on whether base-passwd is presently in line with policy on 3.8 Essential packages. Therefore the route from here appears to hinge on interpreting policy in one of two ways: my point is that base-passwd, at present, is not providing its functionality after just being unpacked - it does require postinst having been run. Santiago claims, if I interpret this correctly, that every package has to be configured at least once before being useful at all (irrespective of whether it is essential or not). Yes, and I should add that my interpretation of policy is based on the wording being used: Since dpkg will not prevent upgrading of other packages while an `essential' package is in an unconfigured state, all `essential' packages must supply all of their core functionality even when unconfigured. The use of upgrading here suggests to me that the rule saying packages must work even when in unconfigured state does not refer to the temporary unconfigured state of essential packages while they are being installed by debootstrap but instead the unconfigured state set by dpkg when they are being *upgraded*. I think that this interpretation is the best one to follow because it simplifies greatly the job of package maintainers in general, and essential package maintainers in particular. The job of debootstrap is to put everything together so that we can actually rely on the functionality provided by essential packages after debootstrap has done its job. By doing this, we transfer part of the complexity of the problem of putting a complete system together from the individual packages to the debootstrap tool. In a previous email I said something like we put the hacks in debootstrap so that we don't have to put hacks in the individual packages (Joey didn't like the wording I used). Well, debootstrap is not a hacky program really, it just unpacks and configures the packages following an order which is known to be good. But thanks to the fact that we made a certain set of packages essential and thanks to debootstrap, we don't have to use, for example, numeric UIDs in postinst, we can use root and mail. I think this is good and it's how we should do things. In particular, I think it would be good that we consider configuring every package at least once one of debootstrap's jobs, so that what base-passwd currently does is allowed. Now, a long patch is proposed for base-passwd. A patch which is quite a lot longer than the required patch that would fix this in debootstrap. I can't honestly tell Colin that he should not apply the patch, it's his package after all, but I should say that the patch seems ugly and hacky to me, and it introduces an additional complexily which IMHO is against the idea of having a tool like debootstrap to break the cycles and avoid complexity in the packages themselves. So, my opinion about the patch is that we should ideally not need so much code in base-passwd if we can fix the same problem by applying a one line patch in debootstrap. In either case, this is an issue to be solved between debootstrap and base-passwd maintainers, so I might better disappear and take a step back, like KiBi recommendsd. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106225336.ga24...@cantor.unex.es
Bug#767999: debootstrap/base-passwd: #767999 and #766459 should really be fixed in base-passwd
On Thu, Nov 06, 2014 at 10:44:40PM +0100, Adam Borowski wrote: B) If base-passwd violates policy, then base-passwd is buggy. I say it is, but since the only consumer that matters is base-files, it might be safer to change the latter. The only consumer that matters? What do you mean? Several essential packages use chown root:root. The reason wheezy's version of debootstrap fails on base-files is that it tries to install base-passwd and base-files in the same dpkg run. If debootstrap installed any other package using chown root:root in the same dpkg run as base-passwd, the other package could easily fail in exactly the same way. Adam, you want to put us in a situation in which we change packages to accomodate the order in which debootstrap decides to install them, when in fact it should be *exactly* the opposite! The job of debootstrap is to install packages in the *right* order, an order which is known to work. And I must say it again: Your idea that we should adapt all the packages is testing and unstable so that they work with a buggy version of debootstrap is not only absurd, it's also *harmful*. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106230745.ga25...@cantor.unex.es
Re: Bug#767999: base-files: fails to install with pre-jessie debootstrap
reassign 767999 debootstrap thanks Adam Borowski, STOP this insanity! STOP IT! (And you should really read the full logs for Bug#766459 to understand this instead of killing the messenger The guilty party for this bug is either base-files or base-passwd. Wrong. It's debootstrap installing base-files and base-passwd on the same dpkg run. It should install base-passwd first, then all the remaining packages. Neither dpkg nor debootstrap are at fault: that this problem did not show up before was an issue akin to relying on hash order. Wrong. debootstrap is at fault for installing base-files and base-passwd on the same dpkg run. Sorry, I'm not going to apply a patch which is based on a twisted interpretation of policy. Your interpretation of policy means base-passwd should not be essential and we should add a lot of depends on base-passwd every time we do a trivial chown in a maintainer script. Since that's a stupid thing to do, I can't consider that to be the correct interpretation of policy, sorry. It's not a bug in base-files (or any other package) to use chown in its postinst. Lot's of packages do that and none of them have to use hardcoded uids in the postinst. That's a STUPID thing to do and that's the reason we made base-passwd essential. Again, this is debootstrap job, and the patch for debootstraop is reasonable and clean. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411050937001.27...@cantor.unex.es
Bug#767999:
On Wed, 5 Nov 2014, Adam Borowski wrote: How do you propose changing debootstrap on already burned CDs? I don't. Instead, those having a buggy version of debootstrap in a burned CD should better try to find a non buggy version on Internet. Proposing that we should make the entire Debian archive (stable, testing and unstable) to be forward compatible with buggy versions of debootstrap on burned CDs that we can't change is a stupid idea. How do you propose updating squeeze, current and past versions of Ubuntu, Knoppix, GRML, etc (live CDs often get used to install Debian). Again. I don't. Software usually has bugs. When you find a buggy software that does not work, you look for a fixed version, not try to change the rest of the Universe to accomodate for that buggy software that you have. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411051056420.29...@cantor.unex.es
Bug#767999: base-files: fails to install with pre-jessie debootstrap
On Wed, Nov 05, 2014 at 11:04:55AM +0100, Holger Levsen wrote: On Mittwoch, 5. November 2014, Santiago Vila wrote: Adam Borowski, STOP this insanity! STOP IT! It seems to me that you are quite upset about this bug, yet I fail to see why, really. Yes, I am upset, because I've explained too many times already why it is not a bug in base-files, and why trying to fix it in base-files would be a complete and ugly hack, and yet people keep filing bugs about base-files, killing the messenger, so to speak. A bug is nothing bad, it's just an id to track things... Also, you ignored a quite significant part of Adams mail: I decided to reply in a second email that you can read now. So, I'd also propose to revert this in base-files _and_ then also fix it in debootstrao for jessie. Please tell me what do you mean by revert. Do you still think that jenkings discovered this because of a change in base-files? You should also read the full logs for the other bug. Please do so, really. Tbe most probably reason for jenkings discovering this now and not before are the recent changes in *dpkg*. But of course that's just a trigger, the real bug has always been in debootstrap. BTW, I also fail to see why this change in base-files is _needed_ _now_ at all... What change do you refer? I have the feeling that you still don't understand the reason why debootstrap fails. It's not because of recent changes in base-files. Not surprisingly, just saying Adams proposal is insane didnt really convince me. OTOH, I too can see the problems pointed out by him... I'm not calling Adam's proposal insane. His proposal is just wrong. What I was calling insane is the fact that we are still having this discussion instead of making a debootstrap upload for stable. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105102901.ga30...@cantor.unex.es
Bug#766459: please don't upload this to wheezy
On Wed, Nov 05, 2014 at 06:05:59AM +0100, Adam Borowski wrote: For reasons I explained in #767999, hacking debootstrap to configure base-passwd and base-files in a specific order is neither sufficient nor necessary. It does work around the problem for those running debootstrap from fully upgraded unstable (and if it was uploaded to stable, wheezy) but doesn't help in any other use cases. I never imagined to find so much bias in a single email message. hacking debootstrap: It's not hacking, it's fixing a bug. In fact, the fix is obvious, reasonable and clean. is not necessary. Yes, it is necessary, because base-passwd is essential and base-files is just using a feature of an essential package, namely chown and default Debian system users, as does dpkg and quite a few other essential packages in their postinst. And once that this necessary thing is done, the problem will disappear, so it's sufficient as well. It does work around the problem. No, it actually fixes the problem. The problem is that base-files uses the feature of an essential package before the essential package is ready, but that's precisely what debootstrap is supposed to do: ensuring that everything works by breaking the cycles. but doesn't help in any other use cases. Sure. It only fixes the problem in stable, testing and unstable. Ok, this would leave oldstable and non Debian systems, but those will always be able to use the version in stable. debootstrap is written to be portable and only needs wget to work. (Hmm. And people still wonder why this issue makes me to be upset) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105164549.ga9...@cantor.unex.es
Re: Bug#767999: base-files: fails to install with pre-jessie debootstrap
reassign 767999 debootstrap thanks People who do not understand the essential flag keep filing bugs against base-files. Kind debootstrap maintainers: I think it's about time that you make an upload for stable fixing this. I've heard that the fix is already in git, so apparently it's just a matter of making the upload. Please. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411041003460.24...@cantor.unex.es
Bug#766459: debootstrap: should not try to configure
[ Trimming Cc list completely. After this email there is little more I have to say about this ]. On Mon, 27 Oct 2014, Michael Tautschnig wrote: Admittedly, all that *I* want is a working debootstrap, so I'm also ok just having the changes in base-files for now (or maybe also in debootstrap). I already tried to fix this problem yesterday in base-files by making minor changes. It didn't work. And it didn't work because contrary to what some people in this thread has suggested, this issue has *absolutely* nothing to do with recent changes in base-files. Most probably, this is what happened: debootstrap in wheezy installs base-passwd and base-files in the same dpkg run. The order in which base-files and base-passwd are configured is not defined in policy so it may depend on the dpkg version, which is almost like saying that it could be random. At this moment dpkg in jessie and sid are quite different, so most likely: dpkg in jessie happen to configure base-passwd first, and it works. dpkg in sid happen to configure base-files first, and it fails. So I could be wrong, but this (recent changes in dpkg) is most likely the real reason this didn't bite us before. So please next time a simple chown root:root fails, let us not kill the messenger, ok? It has been quite disappointing to me to see so many fingers wrongly pointing at base-files, when base-files was never to blame for this. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410281308250.21...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
I'm going to reply to Julien first, then to Michael. On Mon, 27 Oct 2014, Julien Cristau wrote: On Mon, Oct 27, 2014 at 08:35:14 +, Michael Tautschnig wrote: I agree this should be fixed in base-files. Bugs should be fixed where they are. If base-files, or any other package, essential or not, can't make a simple chown root:root, then it is a bug in whatever package was responsible for making sure that the root user exist in a Debian system, base-passwd and debootstrap in this case. This is regardless the fact that base-files could do things differently so that this bug remains hidden a few more months or a few more years. I am investigating the last option right now, but not as a way to fix bugs in debootstrap (which I believe they should be fixed anyway), but as a way to avoid our users to find this problem. BTW: At least once in the past I have made little changes to base-files to fix problems that happen when using debootstrap. I'm not opposed to that. See for example, changes in base-files 3.0.1 (yes, 12 years ago). But it will not be anything like adding a Depends on base-passwd. That would be a hack. chown: invalid user: 'root:root' Can't base-files call chown with 0:0 instead of root:root to sidestep this entirely? It's a little bit more complex than that. Sometimes it's root:root, sometimes is root:staff and sometimes is root:mail. See base-files postinst for details. This has worked for ages, and it should continue to work, because base-passwd is essential. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271044240.29...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
On Mon, 27 Oct 2014, Michael Tautschnig wrote: In principle, every essential package may depend on any other, and the set of real dependencies may change over time, so it's natural that debootstrap needs minor adjustments from time to time. So would you expect some sort of versioned dependencies in debootstrap? No, not at all. I just expect debootstrap maintainers to cooperate with the release managers to ensure that the version in stable is able to debootstrap the testing distribution, whenever it is possible to do so. I've heard that the version in wheezy-backports does not have this problem. Maybe it could be just a matter of making an upload for the next point release. I don't know. [...] The Depends field is implicit among the set of essential packages. I'm not too sure about the among bit here? No doubt that this is implicit for any non-essential package, but among them I'm not sure whether any rules apply right now? I mean that the rule saying Package A does not need a Depends: B if B is essential does not say anything about the essentialness of *A*, which means the rule is valid regardless of A being essential or not. The fact that base-files is essential is quite irrelevent. A chown in the postinst should not fail, and if it does, there is a bug in debootstrap. If a tool like apt-get or dpkg really behaves in a different way when I add a Depends field which was already implicit, I think that there is something fundamentally wrong here. Does dpkg really add the essential information into its dependency information? Wouldn't this rather be seen as ah, essential, so it must be there? At least briefly looking at dpkg's source code I cannot seem to see dpkg considering this implicit dependency at all (unless attempting to remove an essential package). In the general case we don't have to worry about that because once that essential packages are properly installed and configured, they will continue to work all the time unless apt-get does some really weird things. But how are we expected to have all the essential packages properly installed and configured? Should base-files worry about base-passwd being properly installed and configured before making a chown? Certainly not, this is the work of debootstrap! [...] I do appreciate being careful, but then bug fixes for a bug of normal severity (#763405) shouldn't be causing RC bugs either. Fixing bugs in one package usually makes hidden bugs in other packages to become no longer hidden. This happens all the time and it's not a good argument to *not* fix the bugs where they are. In either case, I'm going to re-examine carefully what I did in base-files 7.7 and see if there is a simple workaround that may be done to avoid this problem. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271110590.29...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
On Mon, 27 Oct 2014, Michael Tautschnig wrote: I'm hoping this is not going to be too philosophical, so I'll enlist the facts first (please let me know if I got any of them wrong): debootstrap'ing a system fails, because - chown root:root ... won't work when invoked from base-files' postinst - version 7.7 of base-files is the first to actually have this call when invoked from within (c)debootstrap Regarding previous point, it should be noted that base-files postinst has a lot of chown calls. I would like to know how it is possible that only the recently added is the one that fails and not the others (if that's really the case). BTW: I don't know what is the proper way to debug this (private repository using reprepro?). Can anybody confirm that the chown that fails is exactly the one at the very end? So let's see what Debian Policy says in 3.8 Essential packages: [...] Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate. [...] This is about dpkg when making upgrades. It means that once an essential package is properly configured, it should not stop working because of it being unconfigured by dpkg (whatever that means). I think it does not apply here. [ snipped philosophical stuff. I would much prefer to have free time to work on this rather than discuss about it. Really ]. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271158060.31...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
On Mon, 27 Oct 2014, Michael Tautschnig wrote: + [ ! -f /usr/info/dir ] + [ ! -f /usr/share/info/dir ] + install_from_default /usr/share/base-files/info.dir /usr/share/info/dir + [ ! -f /usr/share/info/dir ] + cp -p /usr/share/base-files/info.dir /usr/share/info/dir + chmod 644 /usr/share/info/dir + chown root:root /usr/share/info/dir chown: invalid user: 'root:root' Thanks a lot for this. I was mistaken/confused. The recently added three lines at the end of base-files postinst may not be the reason for debootstrap fail. I've moved them anyway to a better place. Now we have this chown root:root /usr/share/info/dir that fails. If this is the *only* place where it fails, this could be ommited because postinst is executed by root and the chown is not really required. Regarding previous point, it should be noted that base-files postinst has a lot of chown calls. I would like to know how it is possible that only the recently added is the one that fails and not the others (if that's really the case). I suppose none of the others are being executed as all of them are guarded by some combination of checks? I refer specifically to the big if block starting if [ $1 = configure ] [ $2 = ]; then There are a lot of install_directory calls there. If any of them fails because of the root user does not exist yet, all of them will fail. But those lines have been there since a long time, so after base-files_7.9 where I moved the lines that create /mnt on upgrades, I don't really see what recent change in base-files could be the reason (or better, the trigger) for debootstrap failure. It must be something else. As you please. I was just hoping to find potential options other than revert the change in base-files. I'm still open for options for the benefit of wheezy users not using backports. But I need to have a better view of why it's failing when it was not failing before, if that's really the case. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271258460.32...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
For the record, base-files postinst had three lines like this chown root:root whatever I've dropped all of them in base-files_7.10. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271343001.5...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure
On Mon, 27 Oct 2014, Michael Tautschnig wrote: Then maybe take the first sentence in 3.8 Essential packages instead: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the Unpacked state. If not this one (and not the one above), which bit of policy are you then relying on when you do the chown calls? My intrepretation of policy regarding essential packages is that *once* that they are configured for the first time, they should continue to work at all times even if they are unconfigured for a while in the middle of an upgrade. This is consistent with the usual meaning of bootstrap. It's something that you only need to do once, because after that, everything *keeps* working (but only *after* that). Your interpretation of policy is a little bit different. If you ask essential packages to provide its core functionality *even* when they have not been configured for the *first* time, I bet that we would have to rethink the whole essential thing from the beginning. For example, your interpretation would force base-passwd to lose its essential flag, because it can't provide its core functionality only when in unpacked state. Then, according to policy, base-files and *every* other package using any of the system users in any of its maintainer scripts would have to add a Depends: base-passwd, since they depend on functionality which is only available after base-passwd has been configured. Frankly, I don't think that's what we want. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410271555150.8...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system
reassign 766459 debootstrap retitle 766459 debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system thanks [ Retitled because the predependency on awk in the subject is quite old and most probably has nothing to do with this ]. On Thu, 23 Oct 2014, Holger Levsen wrote: chown: invalid user: 'root:root' base-files is in his right to use the root user, because it is setup in an essential package (base-passwd), as we are allowed to assume that essential packages work all the time. It is not base-files business (or any other essential package) to do things differently so that things work in debootstrap. Instead, the work of debootstrap is precisely to guess the right order in which packages should be configured so that everything work. In other words, essential packages should not get in the business of breaking dependency cycles, because that's debootstrap job. This way, maintainer scripts in essential packages are kept clean and all the hacks required for bootstrap are accumulated (so to speak) in debootstrap and similar tools. You will find a more complete explanation of this in the logs for Bug#760568 where I'm asked no less than to depend on base-passwd, which is essential! IMHO, this is definitely not the way to go. This happens since today, so I assume yesterdays base-files upload is at fault. The only recent change in base-files that could potentially trigger an error like this now is in the last three lines of base-files.postinst, but again, what base-files does is allowed for any essential package. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410231120440.26...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system
On Thu, Oct 23, 2014 at 12:08:50PM +0200, Holger Levsen wrote: for the avoidance of doubt: I have used debootstrap 1.0.48+deb7u1... Ok, so the problem is that in wheezy, deboostrap is no longer able to create a chroot of jessie or sid. IMHO, this is definitely worthy to be fixed in a point release of wheezy. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023105107.ga2...@cantor.unex.es
Re: Bug#766459: debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system
On Thu, Oct 23, 2014 at 01:11:40PM -0400, Joey Hess wrote:
Santiago Vila wrote:
Instead, the work of debootstrap is precisely to guess the right order
in which packages should be configured so that everything work.
In other words, essential packages should not get in the business of
breaking dependency cycles, because that's debootstrap job.
This way, maintainer scripts in essential packages are kept clean
and all the hacks required for bootstrap are accumulated (so to speak)
in debootstrap and similar tools.
As a debootstrap maintainer, I can't say I agree with this.
Well, I was talking about hacks in the general sense (I didn't mean to
be pejorative here), i.e. the kind of trick that a tool like
debootstrap needs to use to achieve its goals. There are many kind of
hacks, and I'm quite confident that the current package will surely
have only the ones that are really required.
There are very few hacks and special cases of ordering in debootstrap today,
and for our sanity we'd like to keep it that way. I consider such
complications to be warts that need to be gotten rid of eventually.
Just compare /usr/share/debootstrap/scripts/{sid,sarge}. Which would
you rather maintain?
I certainly see that the sid script is a little bit shorter than the
sarge script, but I don't see that any of them is really complex.
And BTW that sid script works for 5 different
releases of debian, largely because it's not full of special cases and
hacks specific to particular releases.
In this particular case, I believe the reason for the failure (that
didn't happen before) is some change in base-passwd, not something
that base-files does differently now.
In principle, every essential package may depend on any other, and the
set of real dependencies may change over time, so it's natural that
debootstrap needs minor adjustments from time to time.
You will find a more complete explanation of this in the logs for
Bug#760568 where I'm asked no less than to depend on base-passwd,
which is essential! IMHO, this is definitely not the way to go.
It's past time to be untangling the Essential hairball. Correct dependency
metadata is much more scalable than hacks in debootstrap.
I agree that you may have a point here. In fact, in the aforementioned
bug #760568 against cdebootstrap, which is very similar to this one,
I suggested the idea that if the knowledge about right package ordering
among essential packages were codified and written somewhere, other
similar tools could use the same information without having to
reinvent the wheel.
I see now that the control file could be such common place to have
that information, but I would like to see a little bit of *design*
before doing anything which is not in policy yet.
For example, we could use:
* The same Depends field we are using for normal dependencies.
* A new field for this particular purpose which dpkg and friends
ignore under normal circumstances, and an environment variable which
debootstrap may set to tell dpkg and friends that they should actually
honor them instead of ignoring them.
* An extension of the Depends field, much like !stage1 is used in
Build-Depends for build profiles.
So yes, we could consider to codify this metadata (the fact that
base-files postinst uses chown and expect the root user to exist,
for example) in *some* way...
Stop being part of the problem, and add the dependency already..
... but please let us think about it first. Starting to add Depends
field here and there in a random fashion just because it makes
debootstrap not to fail anymore is not something I will be happy
with.
The Depends field is implicit among the set of essential packages.
If a tool like apt-get or dpkg really behaves in a different way when
I add a Depends field which was already implicit, I think that there
is something fundamentally wrong here.
So, to summarize: I'm not opposed to modify policy when it says that
we don't need to include dependencies on essential packages, but if we
decide to go that route, please let us do it according to some *plan*,
not in a random fashion, because otherwise, IMHO, *that* would be the
real hack.
Thanks.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141023220847.GA4698@nuc
Re: diff is now diffutils
On Tue, 8 Sep 2009, Steve Langasek wrote: [...] I think diff should Pre-Depend on diffutils, as we've done in the past for other Essential package transitions. Agreed. Fixed in 1:2.8.1-17. Thanks a lot. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
diff is now diffutils
Hello. The diff binary package has been renamed diffutils. The diff package is now dummy and depends on diffutils, so nothing should break because of this change. However, you might want to adjust debootstrap and similar tools so that they don't install obsolete dummy packages. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524877: installation-guide: Creating multiarch USB stick
Package: installation-guide Version: 20081208 Severity: wishlist Is there a way to put debian-501-amd64-i386-powerpc-netinst.iso or later inside an USB stick so that the USB stick may be used to install either Debian/i386 or Debian/amd64? If so, it would be great if the install guide explains how to do that. I tried putting the vmlinuz and initrd.gz files for i386 and the multiarchitecture iso image, but the installer seems not to find it. Maybe this is just a regular expression problem? Next thing would be to provide a syslinux.cfg with a simple menu to choose between i386 and amd64. Another useful addition would be that the install manual says how to prepare the USB stick so that it starts the installer in expert mode. It seems this is everything which is needed for that: default vmlinuz append priority=low initrd=initrd.gz Would be nice to see that in the install guide. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#498010: /selinux directory should be created by base-files package
reassign 498010 debian-installer retitle 498010 mount point /selinux does not exist thanks On Sat, 6 Sep 2008, Juha Heinanen wrote: Package: base-files Version: 4.0.5 (lenny) When I install Debian Lenny using image http://cdimage.debian.org/cdimage/lenny_di_beta2/i386/iso-cd/debian-LennyBeta2-i386-netinst.iso and then, at the point, where installation asks Choose software to install, I don't choose anything, I get error message mount failed for selinuxfs on /selinux: no such file or directory when Lenny reboots itself after installation. I have been told that the way get rid of the error message is to create /selinux directory. In my opinion either that directory should have been created by base-files package or whatever package (I have been told policycoreutils) that would create the directory should have already been installed at the point where installation asks Choose software to install. I fully agree that the user should never have to create the directory by hand, but as far as selinux is something which may be disabled, it would be better to create /selinux in whatever selinux package is installed, not in base-files, which is essential. Please reassign as appropriate. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#444232: base-files: /var/tmp was 755 after a fresh install but should be 1777.
reassign 444232 debian-installer thanks On Thu, 27 Sep 2007, Dieter Brüggemann wrote: Package: base-files Version: 4 Severity: normal /var/tmp was 755 after a fresh install but should be 1777. It took me one day to find out why alt gr was not working within a freenx session. This is because nxagent (part of NX server) calls xkbcomp which tries to write to /var/tmp with the rights of the logged in user. base-files has /var/tmp as 1777: $ dpkg -c base-files_4_i386.deb | grep var/tmp drwxrwxrwt root/root 0 2006-10-28 16:06 ./var/tmp/ so this is not a bug in base-files. I'm reassigning to debian-installer for now.
Re: Installing Debian from a minimal initial cd
On Wed, 2 May 2007, bruno steckelberg wrote: I've tried to install debian from a minimal initial cd, but I got no driver supor for my SATA HD. the installing program stopped in the instruction: module sd_mod for SCSI disk support. Does this kind of installation support SATA HD's or not? AFAIK, there are a lot of SATA controllers, and every one of them is different, so there is no such thing as SATA support which ensures that every SATA disk will work. The kernel included in Debian 4.0 (etch), however, has a lot more SATA controllers than the one in Debian 3.1 (sarge), so it's more likely to work if you have a recent computer. I've installed Ubuntu without problems. How could I be proceding in order to achieve the installation of Debian? If it does not work, try submitting a detailed bug report (preferably, without the HTML stuff). [ Note: I don't speak for debian-boot, I'm a casual reader ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#418688: d-i: Points to Sarge in sources.list
On Wed, 11 Apr 2007, Frans Pop wrote: On Wednesday 11 April 2007 14:01, Luis Matos wrote: Why the installer does not has only the version-codename in the sources.list? The Etch installer _does_ only put code names in the sources.list. I'm very glad to hear that. I wonder, while we are at it, why don't we remove all the symlinks (save the stable one) in the dists directory on install CDs: /cdrom/dists# ls -l total 2 dr-xr-xr-x 4 root root 2048 2007-04-07 13:29 etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 frozen - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 stable - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 testing - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 unstable - etch Would you help me to convince debian-cd maintainers that those symlinks should be removed? Last time I tried I was told they were there just in case, but I fail to see how we could need a frozen symlink at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#418688: d-i: Points to Sarge in sources.list
On Wed, 11 Apr 2007, Frans Pop wrote: On Wednesday 11 April 2007 13:37, Santiago Vila wrote: /cdrom/dists# ls -l total 2 dr-xr-xr-x 4 root root 2048 2007-04-07 13:29 etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 frozen - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 stable - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 testing - etch lr-xr-xr-x 1 root root4 2007-04-07 13:29 unstable - etch Would you help me to convince debian-cd maintainers that those symlinks should be removed? Last time I tried I was told they were there just in case, but I fail to see how we could need a frozen symlink at all. The installer _does_ still need the suite links even if we don't put them in the sources.list anymore. Hmm, *all* of them? Would stable not be enough? Would not we have a bug somewhere if the installer failed when only the stable - etch symlink exists? I also don't know what frozen does there though, but I would guess that was used during the Sarge release process. sarge was already testing before it was released, not frozen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch netinstaller has no eth0 in qemu
On Sun, 4 Mar 2007, Eddy Petrior wrote: Also note that will have to change the sources *after* you installed sarge and that would mean extra traffic (if you prefer to install a full desktop task, the sarge packages will be downloaded, then the new ones will too). Changing before will probably not work due to changes in the kernel and udev. Installing just the base system for stable and then upgrading to testing should work. Otherwise there is a bug somewhere. A system having only the base packages installed is already Debian system, and upgrades from stable to testing are supposed to be supported. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch netinstaller has no eth0 in qemu
On Mon, 5 Mar 2007, Uwe Dippel wrote: Be fscking intelligent and *leave* a download for everyone to pick it up, before you replace it. Leave older versions in separate directories and just change the link to it. Be fscking intelligent and try this: wget http://cdimage.debian.org/cdimage/daily-builds/daily/20070304-1/i386/iso-cd/debian-testing-i386-netinst.iso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407063: wine in desktop task?
On Wed, 17 Jan 2007, Robert Millan wrote: That's good enough for a power user. But think of Joe user who just got Debian preinstalled on his laptop because he wanted to save $100 in license fees. He has no idea what wine is, but if he can just click on setup.exe and it works, he will never need to know about wine. If he has no idea, and he just clicks on anything which has an .exe extension, he will need to know about windows virus and trojans instead. Frankly, I don't think this is a good thing for Joe user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401426: partconf: useless defaults word in /etc/fstab
Package: partconf
Version: 1.19
Severity: wishlist
The defaults word in /etc/fstab exist so that one has something to write
as a 4th field, but it's really useless if there are more options. In such
cases it may be removed safely.
In most cases, removing this extra word makes fstab more readable, as
fields 5 and 6 are closer to the same fields in previous and next lines.
Before:
proc/proc procdefaults0 0
/dev/hda5 / ext3defaults,errors=remount-ro 0 1
/dev/hda3 noneswapsw 0 0
After:
proc/proc procdefaults0 0
/dev/hda5 / ext3errors=remount-ro 0 1
/dev/hda3 noneswapsw 0 0
Suggested patch:
diff -ru partconf-1.19.orig/mkfstab.c partconf-1.19/mkfstab.c
--- partconf-1.19.orig/mkfstab.c2006-07-26 00:52:11.0 +0200
+++ partconf-1.19/mkfstab.c 2006-12-03 13:46:03.044507210 +0100
@@ -93,7 +93,7 @@
} else {
if((strcmp(dummy-mountpoint, /) == 0)
((strcmp(dummy-typ, ext2) == 0) || (strcmp(dummy-typ,
ext3) == 0))) {
- dummy-options = strdup(defaults,errors=remount-ro);
+ dummy-options = strdup(errors=remount-ro);
} else {
dummy-options = strdup(defaults);
}
Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401429: debian-installer: kernel-image-* is obsolete
Package: debian-installer
Version: 20061102
Severity: minor
Tested debian-testing-powerpc-netinst.iso today.
When a menu asks the user to choose among available kernels, the
following package was one of them:
kernel-image-2.6-powerpc
but this package, while it would work, is obsolete in etch, as the
kernel packages are now named linux-image-*, so it would be very nice
if we could have the real package for etch:
linux-image-2.6-powerpc
Maybe this patch fixes this bug, but I'm not sure:
diff -ru debian-installer-20061102.orig/build/pkg-lists/kernel
debian-installer-20061102/build/pkg-lists/kernel
--- debian-installer-20061102.orig/build/pkg-lists/kernel 2006-07-26
00:48:21.0 +0200
+++ debian-installer-20061102/build/pkg-lists/kernel2006-12-03
14:17:28.068754346 +0100
@@ -1,3 +1,3 @@
# Just the kernel of right version. Included on all images that are
# bootable.
-kernel-image-${kernel:Version}
+linux-image-${kernel:Version}
Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401432: debian-installer: security.debian.org should not be mandatory in expert mode
Package: debian-installer Version: 20061102 [ I'm not sure this is the right package, please reassign as appropriate ]. In sarge, the user had the choice of adding a security.debian.org line to /etc/apt/sources.list or not. This seems to be no longer the case in etch, not even in expert mode. I think this is a step backwards in flexibility. Just because an ethernet card was detected does not mean the system is in the same net as security.debian.org (i.e. the Internet). Please add a question so that (at least in expert mode), the user is asked whether or not he/she wants a security.debian.org line in sources.list. It would not matter if the line is added anyway in commented out form if the user answer no, but it's important that a connection to Internet is not forced, because if it fails, (and sometimes the user knows that it will fail) the user will lose his valuable time while the system is trying to connect to an unreachable site. In my case, I know there is a buggy router somewhere between my system and security.debian.org, and I know the connection will fail unless I fiddle with some network options in /proc/sys/net/ipv4. More about this in another bug report. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401435: debian-installer: sometimes net install does not work because of networking change in Linux 2.6.17 or later
Package: debian-installer Version: 20061102 Severity: important This is really a feature more than a bug, but the adverse effects are so devastating that it would be nice to have a workaround in debian-installer, or have it properly documented in the install manual. It seems there is a buggy router between me and the Internet. As a result, apt-get does not work at all (it hangs, waiting for who knows what). Needless to say, this is very bad if one wants to install Debian via the Internet. I found a thread in the linux kernel mailing list which explains *exactly* my problem: http://www.gatago.com/linux/kernel/9440712.html Short summary: A change introduced in Linux 2.6.17 makes the network not to work properly in some cases, due to buggy routers. There is a trivial workaround: echo 0 /proc/sys/net/ipv4/tcp_window_scaling However, I had to spend several afternoons to *diagnose* this problem and realize what exactly the nature of the problem was. Considering that the number of systems potentially affected is very big, it would be nice if this were at least documented somewhere. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263575
reassign 263575 debian-installer retitle 263575 Some LANG values are dangerous (?) thanks [ Forgot to Cc: control last time, sorry ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263575: base-files: LANG=C for some languages when root login from console
reassign 263575 debian-installer retitle 263575 Some LANG values are dangerous (?) thanks On Thu, 5 Aug 2004, Kenshi Muto wrote: Package: base-files Version: 3.0.15 Severity: wishlist Tags: d-i Hi, d-i writes LANG which is chosen by user on /etc/environment. This is generally good, because normal user doesn't need to set LANG by him/herself. But unfortunately, Linux console can't show some languages directly (such as Japanese, Korean, Chinese). - normal user see broken characters on console: sad, but you may use X Window System. - root user see broken characters on console: Well, this is a problem. If user didn't install X Window System on d-i stage, root user needs to install by him/herself. When user runs apt-get install ... Oops. console shows broken characters and we can't read provided debconf messages. I considered how to avoid this problem, and created a code for /usr/share/base-files/dot.profile (This file will be installed as /root/.profile). - if [ $TERM = linux ]; then case $(locale charmap) in EUC-*|GB*|BIG5*) LANG=C export LANG ;; esac fi - Adding this to /usr/share/base-files/dot.profile, console root user with some (problematic) languages uses LANG=C automatically. Sorry, I don't think base-files should fiddle with the LANG variable. The CD #1 of woody had support for Asian languages via the frame buffer device, and it worked on the console. If this does not work anymore in sarge, it should probably be fixed. Setting LANG only for root would be a hack, not a solution. Moreover, if there are really some values for LANG which are dangerous and unusable on console, debian-installer should warn about it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251969: aboot-installer: should generate udeb in binary-arch
Package: aboot-installer Version: 0.0.10 Tags: patch The debian/control file for this package says Architecture: alpha, so the binary should be generated by debian/rules binary-arch target, not by binary-indep as it currently happens. Patch follows: diff -ru aboot-installer-0.0.10.orig/debian/rules aboot-installer-0.0.10/debian/rules --- aboot-installer-0.0.10.orig/debian/rulesSat May 8 17:50:16 2004 +++ aboot-installer-0.0.10/debian/rules Mon May 31 23:58:00 2004 @@ -21,6 +21,9 @@ # Build architecture-independent files here. binary-indep: build install + +# Build architecture-dependent files here. +binary-arch: build install dh_testdir dh_testroot dh_installdebconf @@ -28,9 +31,6 @@ dh_installdeb dh_gencontrol dh_builddeb - -# Build architecture-dependent files here. -binary-arch: build install binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234136: autopartkit: Using /media/cdrom instead of /cdrom
Package: autopartkit Version: 0.79 I have been asked to add /media in base-files to follow the FHS standard, which I have just done, but of course adding /media will not make our system more FHS compliant unless we actually use /media/cdrom instead of /cdrom and such. I believe this patch is the only thing required for /media/cdrom to be used by the install program, since APT relies on the information written in /etc/fstab. Please drop me a note whenever this patch or something similar is applied (or simply reassign this bug back to the base-files package) so that I can safely stop creating /floppy and /cdrom in base-files. (I suspect that I could already do this, if, as it seems, this code runs even before base-files and the other base packages are unpacked). Thanks. Patch follows: diff -ru autopartkit-0.78.orig/autopartkit.c autopartkit-0.78/autopartkit.c --- autopartkit-0.78.orig/autopartkit.c Thu Dec 18 17:21:20 2003 +++ autopartkit-0.78/autopartkit.c Sun Feb 22 00:16:53 2004 @@ -791,11 +791,14 @@ #endif /* CREATE_FSTAB */ /* Are these really needed? Who will create them if they are missing? */ -if (0 != mkdir(/target/floppy, 0755)) -autopartkit_error(1, Unable to mkdir /target/floppy: %s, +if (0 != mkdir(/target/media, 0755)) +autopartkit_error(1, Unable to mkdir /target/media: %s, strerror(errno)); -if (0 != mkdir(/target/cdrom, 0755)) -autopartkit_error(1, Unable to mkdir /target/cdrom: %s, +if (0 != mkdir(/target/media/floppy, 0755)) +autopartkit_error(1, Unable to mkdir /target/media/floppy: %s, + strerror(errno)); +if (0 != mkdir(/target/media/cdrom, 0755)) +autopartkit_error(1, Unable to mkdir /target/media/cdrom: %s, strerror(errno)); #if defined(CREATE_FSTAB) fstab = fopen(FSTAB, w); @@ -867,8 +870,8 @@ #if defined(CREATE_FSTAB) fprintf(fstab, %s\tnone\tswap\tsw\t\t0\t0\n, normalize_devfs(find_partition_by_mountpoint(mountmap,swap))); -fprintf(fstab, /dev/fd0\t/floppy\tauto\trw,user,noauto\t\t0\t0\n); -fprintf(fstab, /dev/cdrom\t/cdrom\tiso9660\tro,user,noauto\t\t0\t0\n); +fprintf(fstab, /dev/fd0\t/media/floppy\tauto\trw,user,noauto\t\t0\t0\n); +fprintf(fstab, /dev/cdrom\t/media/cdrom\tiso9660\tro,user,noauto\t\t0\t0\n); fprintf(fstab, proc\t/proc\tproc\tdefaults\t\t0\t0\n); fclose(fstab); -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: home page
On Tue, 30 Dec 2003, June Hiraki wrote: I have a home page, and you had better take your home page off my computer before I call the Better Business Bureau! Who the hell do you think you are, installing this shit operating system on my computer without even asking me first? You'd better send me an e-mail how to get rid of you ASAP You are probably using apache for your home page, just replace the default index.html by one written by you and you will get rid of us... [ I'm assuming you know what apache and index.html means, which perhaps it's assuming too much. In doubt, ask your system admin ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/mailname
On Fri, 19 Dec 2003, Falk Hueffner wrote: [EMAIL PROTECTED] writes: A few days ago I installed a Debian system (V3.0r1). When emacs is invoked it says No /etc/mailname. Reverting to default... and waits for 3 seconds. Of course this is very undesirable. Something is broken. Yes, and it's emacs. Waiting 3 seconds is just silly. Actually, it's emacsen-common. There is already a bug (#115116) asking to remove the delay, but then the message would not be seen at all. I've just asked the maintainer that he at least reduce the delay from 3 seconds to just 1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation report
On Wed, 17 Dec 2003 [EMAIL PROTECTED] wrote: [during installation of a new Debian system - select All packages] No conversation at all should occur while files are being installed on-disk. On the other hand, no daemons or so should be started without confirmation. A security risk. Do not install those packages, then. Wrong answer. I did not mean to give the right answer but the standard one for this problem, but there may be other possible answers. If you do not want any services enabled by default but still you want to install a lot of packages you don't even know what they are for, you could probably achieve that by having simple do-nothing wrappers for update-inetd and start-stop-daemon (not that I would recommend doing that, but it would be interesting to know how that would work). By the way, you can't install all packages because very often there are conflicts between them, but there is a rule in our policy saying there should not be conflicts among packages of optional priority or higher. What you should be able to do is to install all optional or higher packages. If you can't, that would be a bug. In your case, if you want to propose that any package providing a service should be of extra priority, go ahead, but I believe the extra priority was not created to avoid people installing packages providing services when they install all optional or higher packages. I do not install those packages. I install All. The number of packages will slowly grow and it will become less and less feasible to start a conversation about individual ones. That's what debconf non-interactive interface was designed for. Currently, not all packages which ask questions use debconf, but that's one of our goals. If you see a package in unstable which does not use debconf when it would be appropriate to do so, that's a bug. Selecting All during installation is a much weaker commitment than something like apt-get install. It does not follow that I know what the package is or does, or that I want to use it, or that I want to configure it. In Debian, installing a package means both unpacking it and configuring it. It's possible that install has different meanings on different systems, but that's the meaning it has in Debian. What you seem to expect is probably against Debian philosophy. If so, then perhaps Debian philosophy will have to change. Well, most of our users appreciate that installing a package leaves it in a configured state. Please try debconf's non-interactive mode and/or setting debconf priority level to critical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation report
On Mon, 15 Dec 2003 [EMAIL PROTECTED] wrote: Got a new machine and installed Debian (identified as 3.0r1). Everything went fairly smoothly. [Layout microflaw in Choose the Language: For German, de- should be de -.] [Got ext2 - no choice offered?] The default kernel for Debian 3.0 (aka woody) is Linux 2.2, but if you type bf24 at the initial boot prompt, then a special version of Linux 2.4 will be used instead and you will be able to use ext3 or reiserfs. But the package installation phase can be improved. Installing a package means getting it, unpacking it, writing it to disk, configuring it. Package authors have the more or less justified assumption that if one installs a package, one wants to use it. However, this assumption is altogether false at the initial installation. What packages do you want? All, of course. Hundreds of GB free disk space. No time (or knowledge) to go through the list and select things. What do I want? Everything installed on disk, nothing activated. As long as a package is a collection of passive files sitting on disk it does not harm me. It takes some space and I have space. Nothing configured. No questions asked. That's not exactly how Debian is supposed to work, but there are ways to circumvent the unwanted questions. As it is, I cannot walk away from the installation, because it insists on telling me lots of nonsense and waits for me to hit Return or confirm OK. In the old days, every package asked questions in different ways. This is now being standarized around debconf. It is already debian policy that packages should use debconf to interact with the user, so if you find a package in unstable which do not use debconf to ask questions, that would be a bug. One of the goals for debconf is to allow non-interactive installs. I would suggest apt-get install debconf debconf-doc dpkg-reconfigure debconf for a start. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installation report
On Mon, 15 Dec 2003 [EMAIL PROTECTED] wrote: It is undesirable to run inappropriate services. It is a security risk and takes time at boot and shutdown. The number of daemons is really not very high, so the installation script is allowed to, and indeed should, tell me for each one what it is and does, and ask me whether I want it activated. No, I do not need cannaserver, diald, postgres, innwatch. Do not install those packages, then. What you seem to expect is probably against Debian philosophy. The default in Debian is that packages providing a service run such service immediately after installing the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223087: cdrom-detect: should use binary-indep, not binary-arch
Package: cdrom-detect Version: 0.38 Tags: patch The udeb produced by this source package is Architecture: all, so it should be generated by the binary-indep target, not by binary-arch. Patch follows: diff -ru cdrom-detect-0.38.orig/debian/rules cdrom-detect-0.38/debian/rules --- cdrom-detect-0.38.orig/debian/rules Sat Oct 18 18:36:32 2003 +++ cdrom-detect-0.38/debian/rules Sat Dec 6 19:30:26 2003 @@ -43,11 +43,11 @@ # Build architecture-independent files here. -binary-indep: build install +binary-arch: build install # We have nothing to do by default. # Build architecture-dependent files here. -binary-arch: build install cdrom-detect +binary-indep: build install cdrom-detect cdrom-detect: build install dh_testdir dh_testroot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223086: baseconfig-udeb: should create the .udeb in binary-indep
Package: baseconfig-udeb Version: 0.020 Tags: patch The udeb produced by the source is Architecture: all, so it should be generated by the binary-indep target, not by binary-arch. Patch follows: diff -ru baseconfig-udeb-0.020.orig/debian/rules baseconfig-udeb-0.020/debian/rules --- baseconfig-udeb-0.020.orig/debian/rules Wed Jun 4 09:41:56 2003 +++ baseconfig-udeb-0.020/debian/rules Sat Dec 6 19:22:47 2003 @@ -33,13 +33,9 @@ install debian/$(PACKAGE).prebaseconfig debian/$(PACKAGE)/usr/lib/prebaseconfig.d/92$(PACKAGE) # Build architecture-independent files here. -binary-indep: build install -# We have nothing to do by default. - -# Build architecture-dependent files here. # # Note that this builds a .udeb, which is not policy compliant or anything. -binary-arch: build install +binary-indep: build install dh_testdir dh_testroot dh_strip @@ -50,6 +46,10 @@ dh_shlibdeps dh_gencontrol -- -n$(FILENAME) dh_builddeb --filename=$(FILENAME) + +# Build architecture-dependent files here. +binary-arch: build install +# We have nothing to do by default. binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223088: prebaseconfig: should use binary-indep, not binary-arch
Package: prebaseconfig Version: 0.42 Tags: patch The udeb produced by this source package is Architecture: all, so it should be generated in the binary-indep target, not in binary-arch. Patch follows: diff -ru prebaseconfig-0.42.orig/debian/rules prebaseconfig-0.42/debian/rules --- prebaseconfig-0.42.orig/debian/rulesSat Oct 18 18:36:33 2003 +++ prebaseconfig-0.42/debian/rules Sat Dec 6 19:40:00 2003 @@ -46,11 +46,11 @@ done # Build architecture-independent files here. -binary-indep: build install +binary-arch: build install # We have nothing to do by default. # Build architecture-dependent files here. -binary-arch: build install base-install +binary-indep: build install base-install base-install: dh_testdir dh_testroot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223090: iso-scan: should use binary-indep, not binary-arch
Package: iso-scan Version: 0.06 Tags: patch The udebs produced by this source package are both Architecture: all, so they should be generated in the binary-indep target, not in binary-arch. Patch follows: diff -ru iso-scan-0.06.orig/debian/rules iso-scan-0.06/debian/rules --- iso-scan-0.06.orig/debian/rules Mon Nov 3 03:19:14 2003 +++ iso-scan-0.06/debian/rules Sat Dec 6 19:35:28 2003 @@ -15,9 +15,9 @@ dh_testroot dh_clean -binary-indep: build - binary-arch: build + +binary-indep: build dh_testdir dh_testroot dh_installdebconf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223092: userdevfs: binary-arch target should not do anything
Package: userdevfs Version: 0.03 Tags: patch This package produces an udeb which is Arch: all, so invoking binary-arch should not do anything (currently, binary-arch depends on binary-indep, which is wrong). [ While we are at it, the comment saying this builds a .udeb would fit much better in binary-indep, which is the target that actually builds such .udeb ]. Patch follows: diff -ru userdevfs-0.03.orig/debian/rules userdevfs-0.03/debian/rules --- userdevfs-0.03.orig/debian/rulesThu Mar 27 23:08:29 2003 +++ userdevfs-0.03/debian/rules Sat Dec 6 19:47:22 2003 @@ -37,6 +37,8 @@ install init-dev debian/$(PACKAGE)/usr/bin # Build architecture-independent files here. +# +# Note that this builds a .udeb, which is not policy compliant or anything. binary-indep: install dh_testdir dh_testroot @@ -46,9 +48,7 @@ dh_builddeb --filename=$(FILENAME) # Build architecture-dependent files here. -# -# Note that this builds a .udeb, which is not policy compliant or anything. -binary-arch: binary-indep +binary-arch: binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Arch: all udebs generated by binary-arch targets
Hi. While compiling packages for GNU/K*BSD systems I noticed that there are a number of packages (in debian-installer, I think) which generate Arch: all packages in their binary-arch targets. Could someone please care about this, or do you want detailed bug reports about all of them? Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219464: libdebian-installer: Patch for GNU/Hurd
Package: libdebian-installer Version: 0.17 This package does not compile under GNU/Hurd because there is no PATH_MAX there. The following patch makes it to compile: diff -ru libdebian-installer-0.17.orig/src/system/dpkg.c libdebian-installer-0.17/src/system/dpkg.c --- libdebian-installer-0.17.orig/src/system/dpkg.c 2003-10-09 14:16:36.0 +0200 +++ libdebian-installer-0.17/src/system/dpkg.c 2003-11-06 19:26:00.0 +0100 @@ -33,6 +33,9 @@ #include sys/stat.h #include sys/types.h #include unistd.h +#ifndef PATH_MAX +#define PATH_MAX 4096 +#endif #if 0 int di_system_dpkg_package_configure (di_packages *status, const char *_package, bool force) Alternatively, you might want to check for PATH_MAX in the configure script or something alike and define PATH_MAX somewhere else (and of course, if you want to allocate the required space dynamically instead of assuming that there is a maximum path length, you are welcome to do so, but I understand it might not worth the effort). Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#210007: The package description does not follow Debian policy
On Tue, 9 Sep 2003, Javier Fernández-Sanguino Peña wrote: Package: modconf Version: 0.2.44 Severity: important Justification: section 2.3.3 Your package does not comply with the policy as it does not provide a proper extended descrition. Policy section 2.3.3 states: The description should be written so that it gives the system administrator enough information to decide whether to install the package. Hmm, really? Modconf provides a GUI for installing and configuring device driver modules. As a user, I consider this enough. If you don't even know what a device driver module is, I doubt a longer extended description will really help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#175687: link the Debian FAQ from the default /etc/motd
reassign 175687 boot-floppies thanks On Tue, 7 Jan 2003, Josip Rodin wrote: Package: base-files Severity: wishlist - Forwarded message from Rahmat M. Samik-Ibrahim [EMAIL PROTECTED] - To Whom It May Concern: I am writing in regard of Debian FAQ to the addresses that are mentioned in F8 function of the debian-boot disk as well as suggested by the debian FAQ itself. My concern is that it is not so obvious to find the Debian FAQ, and therefore I would like to suggest: - Add a line in the default /etc/motd that mention where to get the FAQs and HOWTOs (or which directory/ package). ... - End forwarded message - I think a pointer to /usr/share/doc/debian would be okay as well, to waste less screen-estate. I don't like the idea of chaning /etc/motd for this. I think such pointer would be much better placed in the final install screen, the one which says have fun or something alike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System Halded
The problem I have is that booting with loadlin from a small Dos partition the system hangs message: Uncompressing Linux Invalid compressed format ERR=1 -- SYSTEM HALTED Also with a initrd.img without any results message:Uncompressing Linux Ran out of input data --SYSTEM HALTED Use Loadlin for many years with small and big kernels without any problem. Maybe it's a problem with the new EXT3 file system ??? * You have copied the initrd.img to the DOS partition, haven't you? * Make sure you don't load any DOS drivers before invoking loadlin. Using a menu and a shell= line in config.sys is a good way to achieve that. * Try installing and using kernel-image-2.4.18-yourcpu, not the one used by the boot floppies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#146479: `defaults' keyword in /etc/fstab is often useless
Package: boot-floppies
Version: 3.0.22
Severity: wishlist
Tags: patch
I wish the /etc/fstab file to fit in 80 columns if possible, so that
it is more readable in console. It usually does not because the
installation program seems to think defaults is a required option,
but in fact this keyword is only useful when it's alone, so that there
is actually a fourth field. When there are more mount options this
defaults keyword is completely redundant and useless.
The following patch removes the use of defaults only when there are more
options to follow, it also removes a tab from the banner line so that
it fits in 80 columns.
--- orig.baseconfig.c Fri May 10 11:49:35 2002
+++ baseconfig.cFri May 10 11:55:29 2002
@@ -317,18 +317,18 @@
}
else if (is_fstype(/target, ext3)) {
fsname = ext3;
-fsopts = defaults,errors=remount-ro;
+fsopts = errors=remount-ro;
pass = 1;
}
else if (is_fstype(/target, ext2)) {
fsname = ext2;
-fsopts = defaults,errors=remount-ro;
+fsopts = errors=remount-ro;
pass = 1;
}
else if (is_fstype(/target, reiserfs)) {
fsname = reiserfs;
if (need_notail(/target))
- fsopts = defaults,notail;
+ fsopts = notail;
else
fsopts = defaults;
pass = 0; /* fsck is unusable */
@@ -341,7 +341,7 @@
fprintf(fstab,
_(# /etc/fstab: static file system information.\n
#\n
- # file system\tmount
point\ttype\toptions\t\t\tdump\tpass\n));
+ # file system\tmount point\ttype\toptions\t\tdump\tpass\n));
fprintf(fstab,
%s\t/\t\t%s\t%s\t0\t%d\n,
Root-name, fsname, fsopts, pass);
@@ -359,8 +359,8 @@
fprintf(fstab,
proc\t\t/proc\t\tproc\tdefaults\t\t\t0\t0\n);
fprintf(fstab,
- /dev/fd0\t/floppy\t\tauto\tdefaults,user,noauto\t\t0\t0\n
- /dev/cdrom\t/cdrom\t\tiso9660\tdefaults,ro,user,noauto\t\t0\t0\n);
+ /dev/fd0\t/floppy\t\tauto\tuser,noauto\t\t0\t0\n
+ /dev/cdrom\t/cdrom\t\tiso9660\tro,user,noauto\t\t0\t0\n);
proc = fopen (/proc/mounts, r);
if ( proc == NULL )
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Why is there a prompt for a root shell when the default linuxkernelboots?
Howland, Curtis wrote: Where might one find documentation on this bf2.4 kernel? See dists/woody/main/disks-i386/current/bf2.4 as I said... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is there a prompt for a root shell when the default linuxkernel boots?
Javier Fernández-Sanguino Peña wrote: 2.- someone to step up an explain how to disable this behavior Maybe something like this: 1. In /etc/mkinitrd/mkinitrd.conf, set: DELAY=0 2. Then regenerate your ramdisk image, for example: cd /boot mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7 (This is a guess by reading the docs, I have not tested myself). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is there a prompt for a root shell when the default linuxkernel boots?
Javier Fernández-Sanguino Peña wrote: Now that I think of it this might be an issue with self-installed kernels. I'm going to document this behavior in the Manual, commit the changes and close the bug. Of course, woody does *not* install 2.4 kernels IIRC. The default install does not, but the bf2.4 flavor does. Please take a look at the dists/woody/main/disks-i386/current directory in the Debian archives. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#144564: Should not we deprecate Packages in favour of Packages.gz?
Package: boot-floppies Version: 3.0.22-2002-04-03 A Release file created by hand made the boot floppies to complain in this way: no entry for main/binary-i386/Packages but there was an entry for main/binary-i386/Packages.gz. apt-ftparchive(1) is quite complex and not very easy to understand. I wish the boot floppies not to switch to mirror_style release (in debootstrap language) yet in woody, but if that's already decided, at least users should not be forced to have uncompressed Packages files, since they were not required at all in potato by APT and friends. [ The current status of things is some sort of step backwards ]. I haven't looked at the code, but it could be as simple as looking for main/binary-i386/Packages.gz, then looking for main/binary-i386/Packages if Packages.gz was not found, in that order. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies: debootstrap failure due to install-info problem
Karsten Merker wrote: I have just tried the current boot-floppies cvs on mipsel (DECstation). Installation works for the most part, but debootstrap fails when configuring the packages for the base system. dpkg outputs Processing was halted because there were to many errors. I believe it is a bug in itself that dpkg stops when there are too many errors, but this is another story :-) The problem is that install-info fails for many packages (i.e. tar, findutils, grep, fileutils, libreadline4, diff, textutils, sed, util-linux, gzip) and dpkg runs into a loop trying to configure libreadline4, util-linux and fileutils until it stops with the aforementioned message. install-info tells for all of these packages: install-info: failed to lock dir for editing! No such file or directory! Is this a mips/mipsel specific problem or does it occur on other architectures as well? It was a bug in base-files_2.2.15, but it's already fixed in base-files_3.0. It will be fixed in mips/mipsel as soon as base-files_3.0 is available for those architectures (since base-files is Architecture: any). This bug never propagated to woody, so if you use woody you should be safe. The only thing possibly fitting to my problem is bug #2904 (which is from 1996), saying that the error message is misleading and really means /usr/info/dir does not exist. According to the FHS this would have to be /usr/share/info/dir now, but this does not exist on a current system - I only have /usr/share/info and in it the info pages, which works fine. Any ideas? I believed dpkg was ready for an install from scratch to have the dir file at /usr/share/info, but I was wrong. I apologize for the inconvenience. As a result, in woody the info system will have all the info files at /usr/share/info but the index `dir' file will still remain at /usr/info. [ As long as it works everybody should be happy ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install report, using latest CVS floppies
Jordi: First error seems to be in recode. It's not translating capitalized characters like Ó to ibmpc, Try using 850 instead of ibmpc. I believe ibmpc was an alias for codepage 437 (which does not have accented uppercase letters). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/initrd
Hello. I've been suggested to remove the /initrd directory from base-files, which I will probably do unless somebody tells me it is required in some way. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#102080: /boot permissions root.disk 2775 why?
Hello. I've received a bug report requesting /boot to be made root.root and mode 755 in base-files. This is currently root.disk and mode 2775. Does anybody remember the reason for the current permissions? (If not, I'll change them as suggested). Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: do we need termwrap?
On Sun, 13 May 2001, Santiago Garcia Mantinan wrote: Could base-files (the package) as has been sugested by some here, be the right place for it? If base-files is not the right place... where do we put it? debianutils? [ Don't know exactly what termwrap does, but currently base-files does not contain any executables ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] kernel.sh
On Tue, 17 Apr 2001, James D Strandboge wrote: [...] FIX: I simply added the '--no-name' flag to gzip and the scripts works fine. Hmm, is this not what --stdout is for? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#81118: base: Wishlist: High security base system (or separate add-on package)
Anthony Towns wrote: If you want minimal, just install the "important" packages. If you want _really_ minimal, just install the "required" packages. Before telling people to do this could you please fix all the wrong priorities in testing and unstable? [ Or at least the ones regarding standard and above packages, which are only a few ]. Currently, it's not always possible to install just the important packages (and above) or just the required packages. On some architectures there are even conflicts among the set of packages which are expected to be installed by default (!). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#72327: boot-floppies: doesn't install .bash_logout for root (fwd)
Are you sure? $ tar ztvf base2_2.tgz | awk '$6 == "./root/" ' drwxr-xr-x root/root 0 2000-07-05 19:47:09 ./root/ maybe this changed. At least a have some slink boxes where 700 was the default. Indeed, this changed, and that's not good. Why was this gratuitous change made? /root has always been 755. The gratuitous thing (IMHO) was the boot floppies team overriding this in the base system. Some time ago I asked about this and 755 was considered to be good enough for /root, see the archives. Anyway, the root account does not differ so much from an ordinary user account, because the admin is usually supposed to do "su" from an unprivileged account. If you think we should change our privacy policy, please move the thread to debian-devel and consider all the cases, including default mode for directories in /home. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#72327: boot-floppies: doesn't install .bash_logout for root (fwd)
reassign 72327 bash retitle 72327 /etc/skel/.bash_logout should not exist thanks I also wonder why do we need .bash_profile and .bashrc in /etc/skel at all. Policy says /etc/skel should be as empty as we can make it. -- Forwarded message -- Date: Sun, 24 Sep 2000 19:20:02 +0200 From: Wichert Akkerman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Erik Andersen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Josip Rodin [EMAIL PROTECTED] Subject: Bug#72327: boot-floppies: doesn't install .bash_logout for root Package: bash Severity: normal File a bug on bash then... [andersen@traveller src]$ ls -l /etc/skel/.bash_logout -rw-r--r--1 root root 174 Feb 20 2000 /etc/skel/.bash_logout [andersen@traveller src]$ cat /etc/skel/.bash_logout # ~/.bash_logout: executed by bash(1) when login shell exits. Lets do that. The problem: bash should not clear the screen by default, it's imho highly annoying behaviour. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
