Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Thu, Mar 28, 2019 at 12:17:41AM +, Justin B Rye wrote: > vincent.mcint...@csiro.au wrote: > >> + > >> + The package descriptions for transitional dummy packages usually > >> indicate their > >> + purpose. However, they are not uniform; in particular, some > >> dummy > >> + packages are designed to be kept installed (e.g. to express a > >> dependency on > >> + the current latest version of some program). You might also find > >> + deborphan with the > >>--guess-* options > >> (e.g. > >> - --guess-dummy) useful to detect them in your > >> system. Note > >> - that some dummy packages are not intended to be removed after an > >> upgrade but > >> - are, instead, used to keep track of the current available version > >> of a program > >> - over time. > >> + --guess-dummy) useful to detect transitional > >> dummy packages > >> + on your system. > >> > >> > >> > > > > I agree with everything you've said about this text but as regards > > the patch I think some mention of tracking packages should be kept. > > Something like: > > > > One class of dummy package that are not intended to be removed > > are tracking packages, which are used to keep > > track of the current available version of a program over time. > > A common case is linux-image--&architecture;. > > The idea was that the earlier bit about "a dependency on the current > latest version of some program" was talking about "tracking packages", > and it seemed to make more sense to mention them in the part before > the deborphan recipe. > Ah, with you now. sorry for the noise. > Unlike Ben I rather like the idea of distinguishing version-tracking > dependency metapackages from full-suite dependency metapackages, but > we don't want to go into it in depth here. The objective is just to > tell readers enough to let them ignore both kinds while searching for > transitional dummy packages. > > I was deliberately not using linux-image-* as an example on the > grounds that it doesn't claim to be a "dummy package". In fact most > of the confusing cases seem to be "full-suite" metapackages. > > So another option would be: > > The package descriptions for transitional dummy packages usually > indicate their > purpose. However, they are not uniform; in particular, some > dummy > packages are designed to be kept installed, in order to pull in a full > software > suite, or track the current latest version of some program. You might > also find > deborphan with the > --guess-* options (e.g. > --guess-dummy) useful to detect transitional dummy > packages > on your system. > Works for me. Vince
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, Mar 27, 2019 at 11:34:20PM +, Ben Hutchings wrote: > On Wed, 2019-03-27 at 22:52 +, vincent.mcint...@csiro.au wrote: > [...] > > I agree with everything you've said about this text but as regards > > the patch I think some mention of tracking packages should be kept. > > Something like: > > > > One class of dummy package that are not intended to be removed > > are tracking packages, which are used to keep > > track of the current available version of a program over time. > > A common case is linux-image--&architecture;. > > Why do you want to introduce the term "tracking package" when we > already have the term "metapackage"? That was the term I was looking for, thank you. > > Ben. > > -- > Ben Hutchings > I say we take off; nuke the site from orbit. > It's the only way to be sure. > > --
Bug#864017: release-notes: Assumes /etc/apt/sources.list is used (and not /etc/apt/sources.list.d/*.list or deb822) [general]
On Wed, Mar 27, 2019 at 06:44:29PM +, Justin B Rye wrote: > Justin B Rye wrote: > > Sorry, I've run out of coffee! I'll have another look at this > > tomorrow. > > I'm still only running on cheap freeze-dried instant coffee, so the > attached patch will probably still need work, but I think the > reordering of paragraphs makes sense. > > In particular: > > diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk > > index 0a53d737..3d1b70ed 100644 > > --- a/en/old-stuff.dbk > > +++ b/en/old-stuff.dbk > > @@ -27,14 +27,14 @@ upgraded to the latest &oldreleasename; point release. > > > > > > > > -Checking your sources list > > +Checking your APT source-list files > > > > -If any of the lines in your /etc/apt/sources.list > > -refer to stable, it effectively > > -points to &releasename; already. This might not be what you want if > > -you are not ready yet for the upgrade. If you have already run > > -apt update, you can still get back without > > -problems by following the procedure below. > > + If any of the lines in your APT source-list files (see > + > > url="https://manpages.debian.org/&releasename;/apt/sources.list.5.html";>sources.list(5)) > > + contain references to stable, this is > > effectively pointing to > > + &releasename; already. This might not be what you want if you are not > > yet ready > > + for the upgrade. If you have already run apt update, > > + you can still get back without problems by following the procedure below. > > > > I've let this keep a fuller explanation instead of a crossreference, > partly because I haven't figured out how crossreferences work yet. > > [,,,] > > index a22924f3..d241de1f 100644 > > --- a/en/upgrading.dbk > > +++ b/en/upgrading.dbk > > @@ -244,16 +244,26 @@ > > > > > > > > - Checking system status > > + Checking APT configuration status > > "System" could mean anything; all the following checks deal with the > status of the package management system in particular. > > > > > -The upgrade process described in this chapter has been designed for > > upgrades > > -from pure &oldreleasename; systems without third-party > > packages. > > -For the greatest reliability of the > > -upgrade process, you may wish to remove third-party packages from your > > system > > -before you begin upgrading. > > +The upgrade process described in this chapter has been designed for > > +pure Debian stable systems. If your APT configuration > > mentions > > +additional sources besides &oldreleasename, or if you have installed > > packages > > +from other releases or from third parties, then to ensure a reliable > > upgrade > > +process you may wish to begin by removing these complicating factors. > > > > > > -Below there are two methods for finding such packages by using either > > +The main configuration file that APT uses to decide what sources it > > should > > +download packages from is /etc/apt/sources.list, > > but > > +it can also use files in the > > /etc/apt/sources.list.d/ > > +directory - for details see > + > > url="https://manpages.debian.org/&releasename;/apt/sources.list.5.html";>sources.list(5). > > +If your system is using multiple source-list files then you will need > > to ensure > > +they stay consistent. > > + > > Inserting the main "first" introduction of the concept of APT > sources-list files, and adding the point that having a whole > collection of different /etc/apt/sources.list.d/*.list files pointing > at different releases is a bad idea. > > > + > > +Below there are two methods for finding installed packages that > > +did not come from Debian, using either > > aptitude or apt-forktracer. > > Please > > note that neither of them are 100% accurate (e.g. the aptitude example > > will list packages that were once provided by Debian but no longer > > are, such as > > old kernel packages). > > Incidentally, why is it bad that aptitude will detect the fact you've > got an obsolete kernel installed? On a stable system, it must be: > * a homebrew kernel-package; or > * an ancient relic from &oldrelease; or at least > * a leftover from an old point release; > and any of these would be things you should consider > removing/replacing before the upgrade, i.e. a "true positive". > -- > JBR with qualifications in linguistics, experience as a Debian > sysadmin, and probably no clue about this particular package > diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk > index 0a53d737..3d1b70ed 100644 > --- a/en/old-stuff.dbk > +++ b/en/old-stuff.dbk > @@ -27,14 +27,14 @@ upgraded to the latest &oldreleasename; point release. > > > > -Checking your sources list > +Checking your APT source-list files > > -If any of the lines in your /etc/apt/sources.list > -refer to stable, it effectively > -points to &releasename; already. This might not be what you want if > -you are not ready yet for the upg
Bug#901193: Bug#901003: There is no standard way of removing transitional / dummy packages
On Wed, Mar 27, 2019 at 02:23:41PM +, Justin B Rye wrote: > diff --git a/en/upgrading.dbk b/en/upgrading.dbk > index a22924f3..37fa449d 100644 > --- a/en/upgrading.dbk > +++ b/en/upgrading.dbk > @@ -1311,24 +1311,25 @@ $ aptitude purge '~c' > > > > -Dummy packages > - > - Some packages from &oldreleasename; have been split into several > packages in &releasename;, often > - to improve system maintainability. To ease the upgrade path in such > cases, > - &releasename; often provides dummy packages: empty > packages that have the same name as > - the old package in &oldreleasename; with dependencies that cause the > new packages to be > - installed. These dummy packages are considered > redundant after the > - upgrade and can be safely removed. > - > - > - Most (but not all) dummy packages' descriptions indicate their purpose. > - Package descriptions for dummy packages are not uniform, however, so > you might > - also find deborphan with the > +Transitional dummy packages > + > + Some packages from &oldreleasename; may have been replaced in > &releasename; > + by transitional dummy packages, which are empty placeholders designed > to > + simplify upgrades. If for instance an application that was formerly a > single > + package has been split into several, a transitional package may be > provided > + with the same name as the old package and with appropriate > dependencies to > + cause the new ones to be installed. After this has happened the > redundant > + dummy package can be safely removed. > + > + > + The package descriptions for transitional dummy packages usually > indicate their > + purpose. However, they are not uniform; in particular, some > dummy > + packages are designed to be kept installed (e.g. to express a > dependency on > + the current latest version of some program). You might also find > + deborphan with the >--guess-* options (e.g. > - --guess-dummy) useful to detect them in your > system. Note > - that some dummy packages are not intended to be removed after an > upgrade but > - are, instead, used to keep track of the current available version of a > program > - over time. > + --guess-dummy) useful to detect transitional dummy > packages > + on your system. > > > I agree with everything you've said about this text but as regards the patch I think some mention of tracking packages should be kept. Something like: One class of dummy package that are not intended to be removed are tracking packages, which are used to keep track of the current available version of a program over time. A common case is linux-image--&architecture;. Kind Regards Vince
Bug#924290: [rfc] information about EFI partitions
Package: installation-guide
Version: 20180930
Severity: wishlist
Tags: patch
Hi
recently I was learning about presseding UEFI installs and
I think the install guide could use a small addition to make
that journey easier. I also sent a patch to partman-auto-recipe.txt
but I am sure the readership of that is much less than the d-i manual.
Kind regards
Vince
From 4697c54b3f61bc145980f52206bb20e2280c0a63 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre
Date: Mon, 11 Mar 2019 15:38:19 +1100
Subject: [RFC PATCH] Add some information about preseeding EFI partitions
---
en/appendix/preseed.xml | 17 +
1 file changed, 17 insertions(+)
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index c55860e34..9e334738a 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1211,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
# system labels, volume group names and which physical devices to include
# in a volume group.
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+# 538 538 1075 free \
+# $iflabel{ gpt } \
+# $reusemethod{ } \
+# method{ efi } \
+# format{ } \
+# . \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1218,6 +1232,9 @@ d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+
# When disk encryption is enabled, skip wiping the partitions beforehand.
#d-i partman-auto-crypto/erase_disks boolean false
--
2.11.0
Bug#924289: update EFI example in partman-auto-recipe.txt
Package: debian-installer
Version: 20190119
Severity: wishlist
Tags: patch
Hello
I recently spent some time working on getting EFI installs going.
It took rather a lot of digging to find out how to set up an EFI
partition in a partitioning recipe so I thought I would try to
make the documentation more accessible.
Please consider merging the attached patch.
Kind regards
Vince
From 7fb9450e3d1aacde6a32cb74e9f7a0cbfdd57831 Mon Sep 17 00:00:00 2001
From: Vincent McIntyre
Date: Mon, 11 Mar 2019 15:02:54 +1100
Subject: [PATCH] Update EFI example
Use a common architecture (amd64) in preference to an unsupported one.
Also, give an example of a path to a specific recipe within partman-auto.
---
doc/devel/partman-auto-recipe.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/devel/partman-auto-recipe.txt b/doc/devel/partman-auto-recipe.txt
index bc8b541c5..5bf64ba5f 100644
--- a/doc/devel/partman-auto-recipe.txt
+++ b/doc/devel/partman-auto-recipe.txt
@@ -259,15 +259,16 @@ formated in revision 0 ext2.
filesystem{ ext2r0 }
mountpoint{ /boot } .
-And finally, an example of how to set up the efi boot partition needed on
-ia64.
+Finally, an example of how to set up an efi boot partition on amd64.
-100 100 150 fat16
-$primary{ }
+538 538 1075 free
+$iflabel{ gpt }
+$reusemethod{ }
method{ efi }
format{ } .
For other examples, see the architecture-specific recipes in partman-auto.
+The EFI example above was taken from partman-auto/recipe-amd64-efi/atomic.
5. LIMITATIONS
--
2.11.0
Bug#813055: done?
Hi I think this may have been handled? % git remote -v origin https://salsa.debian.org/installer-team/partman-auto.git (fetch) origin https://salsa.debian.org/installer-team/partman-auto.git (push) % git log --oneline recipes-amd64-efi/atomic 4d2966b Set minimimum size of / partition a5df6f5 Increase the EFI System Partition size slightly to ensure that it's at least 512MiB, not just 512MB. See LP #1306164. 4df3586 Add x86 UEFI support, merging some code from Ubuntu to help What I am unable to check at present is whether requesting an 'atomic' partitioning in the preseed file and UEFI netbooting automagically selects the recipe above. Cheers Vince
Bug#755434: abandoned?
Hi,
this package never got migrated to salsa, I think it is dead upstream.
The archived git is here
https://alioth-archive.debian.org/git/pmount/pmount.git.tar.xz
https://alioth-archive.debian.org/git/pmount/pmount-debian.git.tar.xz
I've attached a debdiff of what I had to do with the stretch package
source to get it working.
Cheers
Vince
diff -Nru pmount-0.9.23/debian/changelog pmount-0.9.23/debian/changelog
--- pmount-0.9.23/debian/changelog 2014-05-18 18:13:54.0 +1000
+++ pmount-0.9.23/debian/changelog 2019-02-27 15:03:07.0 +1100
@@ -1,3 +1,10 @@
+pmount (0.9.23-4) stretch; urgency=medium
+
+ * Add patch for exfat from ubuntu bug 1524523
+ * Add second patch from debian bug 755434
+
+ -- Vincent McIntyre Wed, 27 Feb 2019 15:03:07
+1100
+
pmount (0.9.23-3) unstable; urgency=low
* Use dh-autoreconf at build time (closes: #727943, #744493)
diff -Nru pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff
pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff
--- pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff 1970-01-01
10:00:00.0 +1000
+++ pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff 2019-02-27
15:02:11.0 +1100
@@ -0,0 +1,10 @@
+--- a/src/fs.c
b/src/fs.c
+@@ -23,6 +23,7 @@ static struct FS supported_fs[] = {
+ { "iso9660", "nosuid,nodev,user", 1, NULL, ",iocharset=%s" },
+ { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077",
+ ",iocharset=%s",",fmask=%04o,dmask=%04o"},
++{ "exfat", "nosuid,nodev,user,quiet,nonempty", 1, "077",
",iocharset=%s",",fmask=%04o,dmask=%04o"},
+ { "hfsplus", "nosuid,nodev,user", 1, NULL, 0 },
+ { "hfs", "nosuid,nodev,user", 1, "077", NULL,
+ ",file_umask=%04o,dir_umask=%04o"},
diff -Nru pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch
pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch
--- pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch 1970-01-01
10:00:00.0 +1000
+++ pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch 2019-02-27
15:03:07.0 +1100
@@ -0,0 +1,11 @@
+--- a/src/pmount.c
b/src/pmount.c
+@@ -362,7 +362,7 @@ do_mount( const char* device, const char
+ fs->iocharset_format, iocharset );
+ }
+ }
+-else if(! strcmp(fsname, "vfat") && fs->iocharset_format) {
++else if((! strcmp(fsname, "vfat") || ! strcmp(fsname, "exfat")) &&
fs->iocharset_format) {
+ /* We still make a special case for vfat, as in certain cases,
+mount will mount it with iocharset=utf8, some times without
+warning. So, in the absence of a specified charset, we
diff -Nru pmount-0.9.23/debian/patches/series
pmount-0.9.23/debian/patches/series
--- pmount-0.9.23/debian/patches/series 2014-05-18 18:13:54.0 +1000
+++ pmount-0.9.23/debian/patches/series 2019-02-27 15:03:07.0 +1100
@@ -1 +1,3 @@
01-man-plugdev.diff
+02-exfat-launchpad1524523.diff
+03-exfat-debian_755434.patch
Bug#618607: reproducer(?)
package mutt found 618607 1.7.2-1+deb9 thanks I think I can reproduce this by using a davmail imap server (which gives easy control of the socket timeout). Disabling the socket timeout made for a much improved experience. The davmail version I used was 5.0.0.2801-2~bpo9+1. My only non-default imap setting is set imap_keepalive = 120 The $timeout variable is set at default (600s) Regards Vince
Bug#512601: multipath-tools: kpartx does not handle multi-Tb filesystems on i386
> >Did you resolve the conflict by hand?. Otherwise kpartx won't work. I >can send a patch against 0.4.8-7 instead of 0.4.8-13 if that's easier >for you. But since you only need kpartx I recommend to apply the patch I >send against 0.4.8-13 (see below). Yes, I was able to resolve the conflict by hand. In the logfile I sent I did cat kpartx/kpartx.c.rej so you could see the hunk that did not apply, and diff -u kpartx/kpartx.c.orig kpartx/kpartx.c at the point where I had hand-fixed the code so you could see the complete diff. >Yes. But since you're only interested in kpartx you can just use all of >multipath tools from etch and only the kpartx binary you backported. >That should ease things considerably on etch. That is actually the path we were considering. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
