Re: Dependencies between components.

[Tim Woodall]

On Sat, 6 Apr 2024, Simon Hollenbach wrote:


Hi,

I have not found a mistake in your considerations about "sane"
component inter-dependency.

However, package dependencies are declared upon a package with a
suitable version, whether this package can be set-up on a bespoke
target system remains to be determined by APT when the package is
installed or upgraded. Just consider for example some manually held
packages - These might break your package install even if all the
needed packages are downloadable (All the components needed are
correctly configured in sources.list ).

I hope this helps. I'd like to understand why you are asking this
question, this might enable us to give you better-suited information.



I have local packages I can install that setup sources.list.d so if, for
example, I want to use backports, I can do:
apt-get install bookworm-backports-main-sources
and I will get an appropriate file in sources.list.d. These get
autogenerated.

To cut a long story short, I was missing having backports installed
despite me having a patched version of a backports package installed. I
then missed a security fix because although my tooling saw it and
auto-rebuilt my patched local package, it couldn't install because of
missing (new) dependencies on other packages in backports. The previous
version had installed because it didn't have dependencies on other
packages in backports.

So my local packages that add files to sources.list.d now express
required dependencies - so if I have
bookworm-backports-local-main-sources installed
(which has any packages from backports that I have local changes to) I
will automatically get bookworm-backports-main-sources too.

I've never actually patched any packages from
backports-sloppy/updates/proposed-updates but while I was at it
I thought it made sense to add dependencies for those too so if I ever
do use backports-sloppy, I will get backports too rather than have to
remember to manually install it.

Tim.

Re: Dependencies between components.

[Simon Hollenbach]

Hi,

I have not found a mistake in your considerations about "sane"
component inter-dependency.

However, package dependencies are declared upon a package with a
suitable version, whether this package can be set-up on a bespoke
target system remains to be determined by APT when the package is
installed or upgraded. Just consider for example some manually held
packages - These might break your package install even if all the
needed packages are downloadable (All the components needed are
correctly configured in sources.list ).

I hope this helps. I'd like to understand why you are asking this
question, this might enable us to give you better-suited information.

Ciao,
Simon

P.S.: I am sorry for first sending this to Tim directly - I should
take extra care when using this weird web interface here.

On Sat, 30 Mar 2024 at 18:12, Tim Woodall  wrote:
>
> Is there a wiki or something else that lays out exactly what other
> distributions and components each debian (distribution,component) tuple
> is allowed to depend on?
>
> This is what I've concluded so far.
>
> I'm assuming transitive dependencies are allowed, e.g.
> bookworm-updates-contrib can depend on bookworm-non-free so I've
> considered the dependencies between distributions with the same
> component and the dependencies between components of the same
> distribution separately.
>
>
> First considering the distribution dependencies. All of these are
> always allowed between the same component.
>
> bookworm-proposed-updates : bookworm
> bookworm-updates  : bookworm
> bookworm-backports-sloppy : bookworm-backports bookworm
> bookworm-backports: bookworm
>
> I believe that updates is a subset of proposed-updates so dependency
> on updates by proposed-updates is moot
>
> I'm unclear whether backports is allowed to depend on -updates but I
> assume not as I've not seen anything saying that you need to enable
> -updates if you enable -backports. I guess the backporter would have to
> wait for the point release if they ever needed something only in
> bookworm-updates (it's hard to imagine many cases where a -updates
> package would be required for backporting so this is somewhat
> theoretical - I think it's only if there's a security update involved)
>
>
> Now considering the dependencies between components in the same
> distribution:
>
> contrib  : non-free non-free-firmware main
> non-free : non-free-firmware main
> non-free-firmware: main
>
> Some sources seem to say that non-free depends on contrib while others
> say contrib depends on non-free. My understanding on contrib is that it
> is for packages that cannot be in main because they depend on non-free
> even though they're otherwise free. But I'm not sure if there's a two
> way dependency here.
>
> I'm assuming that non-free-firmware cannot depend on non-free or contrib
> - that would seem to defeat the goal of non-free-firmware - although I
> could see a case where a firmware loader is in contrib while the
> firmware itself is in non-free so I'm not sure exactly what is allowed
> or expected here.
>

Re: Dependencies between components.

[Max Nikulin]

On 30/03/2024 22:54, Tim Woodall wrote:

I'm unclear whether backports is allowed to depend on -updates


You have not mentioned bookworm-security.


contrib  : non-free non-free-firmware main
non-free : non-free-firmware main
non-free-firmware    : main


https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas
2.2. Archive areas in Debian Policy Manual

Dependencies between components.

[Tim Woodall]

Is there a wiki or something else that lays out exactly what other
distributions and components each debian (distribution,component) tuple
is allowed to depend on?

This is what I've concluded so far.

I'm assuming transitive dependencies are allowed, e.g.
bookworm-updates-contrib can depend on bookworm-non-free so I've
considered the dependencies between distributions with the same
component and the dependencies between components of the same
distribution separately.


First considering the distribution dependencies. All of these are
always allowed between the same component.

bookworm-proposed-updates : bookworm
bookworm-updates  : bookworm
bookworm-backports-sloppy : bookworm-backports bookworm
bookworm-backports: bookworm

I believe that updates is a subset of proposed-updates so dependency
on updates by proposed-updates is moot

I'm unclear whether backports is allowed to depend on -updates but I
assume not as I've not seen anything saying that you need to enable
-updates if you enable -backports. I guess the backporter would have to
wait for the point release if they ever needed something only in
bookworm-updates (it's hard to imagine many cases where a -updates
package would be required for backporting so this is somewhat
theoretical - I think it's only if there's a security update involved)


Now considering the dependencies between components in the same
distribution:

contrib  : non-free non-free-firmware main
non-free : non-free-firmware main
non-free-firmware: main

Some sources seem to say that non-free depends on contrib while others
say contrib depends on non-free. My understanding on contrib is that it
is for packages that cannot be in main because they depend on non-free
even though they're otherwise free. But I'm not sure if there's a two
way dependency here.

I'm assuming that non-free-firmware cannot depend on non-free or contrib
- that would seem to defeat the goal of non-free-firmware - although I
could see a case where a firmware loader is in contrib while the
firmware itself is in non-free so I'm not sure exactly what is allowed
or expected here.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[David Wright]

On Wed 06 Dec 2023 at 22:40:23 (+), Albretch Mueller wrote:
>  What I had been doing is use "depends" to get all dependencies

I did that.

> and
> then download each of them.

I did that too. Not all of them, of course, as I don't need or want
all those packages.

> I think that is why I was getting those
> repeated binary files.

You haven't posted what they look like or precisely when they appear:
at the depends stage or the download?

> I thought when you said "download" you just
> meant "download".

Well, yes, and I just posted it:   apt-get download acl2
Usually I just use   apt-get -d install acl2   but in the interests
of replication, I copied your "apt-get download" version.

My only guess, not knowing or seeing your system, is that your
packages cache /var/cache/apt/{src,}pkgcache.bin is screwed,
and so a new one has to be rebuilt every time.

Cheers,
David.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Albretch Mueller]

 What I had been doing is use "depends" to get all dependencies and
then download each of them. I think that is why I was getting those
repeated binary files. I thought when you said "download" you just
meant "download".
lbrtchx

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[David Wright]

On Mon 04 Dec 2023 at 21:24:58 (+), Albretch Mueller wrote:
> On 12/2/23, David Wright  wrote:
> > Obviously I'm trying to replicate what you do.
> ...
> > Presumably you're running more commands than you revealed above?
> 
>  Yes, I am; for each "  Depends: " package I have been using apt-get download

~# mkdir /tmp/acl2 ; cd $_
/tmp/acl2# apt-get download acl2
Get:1 http://deb.debian.org/debian bullseye/main amd64 acl2 amd64 8.3dfsg-2 
[21.5 MB]
Fetched 21.5 MB in 2s (10.1 MB/s)
W: Download is performed unsandboxed as root as file 
'/tmp/acl2/acl2_8.3dfsg-2_amd64.deb' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)
/tmp/acl2# ls -laR . /var/cache/apt
.:
total 21004
drwxr-xr-x  2 root root 4096 Dec  4 17:11 .
drwxrwxrwt 17 root root20480 Dec  4 17:10 ..
-rw-r--r--  1 root root 21481292 Jan 27  2021 acl2_8.3dfsg-2_amd64.deb

/var/cache/apt:
total 69356
drwxr-xr-x  3 root root 4096 Dec  4 15:00 .
drwxr-xr-x 17 root root 4096 May  2  2022 ..
drwxr-xr-x  3 root root57344 Dec  4 09:27 archives
-rw-r--r--  1 root root 35492253 Dec  4 15:00 pkgcache.bin
-rw-r--r--  1 root root 35451043 Dec  4 15:00 srcpkgcache.bin

/var/cache/apt/archives:
total 68
drwxr-xr-x 3 root root 57344 Dec  4 09:27 .
drwxr-xr-x 3 root root  4096 Dec  4 15:00 ..
-rw-r- 1 root root 0 Apr 16  2022 lock
drwx-- 2 _apt root  4096 Dec  4 09:18 partial

/var/cache/apt/archives/partial:
total 64
drwx-- 2 _apt root  4096 Dec  4 09:18 .
drwxr-xr-x 3 root root 57344 Dec  4 09:27 ..
/tmp/acl2# 

Still no extra .bin files.

Cheers,
David.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Albretch Mueller]

On 12/2/23, David Wright  wrote:
> Obviously I'm trying to replicate what you do.
...
> Presumably you're running more commands than you revealed above?

 Yes, I am; for each "  Depends: " package I have been using apt-get download

 lbrtchx

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[David Wright]

On Sat 02 Dec 2023 at 02:10:48 (+), Albretch Mueller wrote:
> On 11/30/23, David Wright  wrote:
> > On Thu 30 Nov 2023 at 21:05:38 (+), Albretch Mueller wrote:
> >>  I also notice repeated copies of {src-, pkgcache}.bin files for each
> >> downloaded package even though I am downloading them to specific
> >> subdirectories in order to then install them using dpkg.
> >>  Do you really need those binaries and cache instructions if you are
> >> just downloading the installation dependencies? How do you remove,
> >> disregard those kinds of caching strategies in a graceful way?
> >
> > Perhaps you could elaborate on the commands you're running.
> 
>  I am using apt-rdepends --follow=Depends 
> 
>  to download all dependencies into a subdirectory for each package
> then I notice the same files: srcpkgcache.bin et pkgcache.bin in every
> subdirectory.

Obviously I'm trying to replicate what you do. In case it matters,
my bullseye system has package acl installed, but not acl2. (Despite
their names, they're unrelated.)

$ mkdir temp/rdepends ; cd $_
~/temp/rdepends$ apt-rdepends --follow=Depends acl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
acl
  Depends: libacl1 (= 2.2.53-10)
  Depends: libc6 (>= 2.14)
libacl1
  Depends: libc6 (>= 2.14)
libc6
  Depends: libcrypt1
  Depends: libgcc-s1
libcrypt1
  Depends: libc6 (>= 2.25)
libgcc-s1
  Depends: gcc-10-base (= 10.2.1-6)
  Depends: libc6 (>= 2.14)
gcc-10-base
~/temp/rdepends$ apt-rdepends --follow=Depends acl2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
acl2
  Depends: libc6 (>= 2.29)
  Depends: libgmp10
  Depends: libreadline8 (>= 6.0)
  Depends: libx11-6
libc6
  Depends: libcrypt1
  Depends: libgcc-s1
libcrypt1
  Depends: libc6 (>= 2.25)
libgcc-s1
  Depends: gcc-10-base (= 10.2.1-6)
  Depends: libc6 (>= 2.14)
gcc-10-base
libgmp10
  Depends: libc6 (>= 2.14)
libreadline8
  Depends: libc6 (>= 2.15)
  Depends: libtinfo6 (>= 6)
  Depends: readline-common
libtinfo6
  Depends: libc6 (>= 2.16)
readline-common
  Depends: dpkg (>= 1.15.4)
  Depends: install-info
dpkg
  Depends: tar (>= 1.28-1)
  PreDepends: libbz2-1.0
  PreDepends: libc6 (>= 2.15)
  PreDepends: liblzma5 (>= 5.2.2)
  PreDepends: libselinux1 (>= 3.1~)
  PreDepends: zlib1g (>= 1:1.1.4)
tar
  PreDepends: libacl1 (>= 2.2.23)
  PreDepends: libc6 (>= 2.28)
  PreDepends: libselinux1 (>= 3.1~)
install-info
  Depends: libc6 (>= 2.14)
  PreDepends: dpkg (>= 1.16.1)
libx11-6
  Depends: libc6 (>= 2.26)
  Depends: libx11-data
  Depends: libxcb1 (>= 1.11.1)
libx11-data
libxcb1
  Depends: libc6 (>= 2.14)
  Depends: libxau6 (>= 1:1.0.9)
  Depends: libxdmcp6
libxau6
  Depends: libc6 (>= 2.4)
libxdmcp6
  Depends: libbsd0 (>= 0.2.0)
  Depends: libc6 (>= 2.4)
libbsd0
  Depends: libc6 (>= 2.25)
  Depends: libmd0 (>= 1.0.3-2)
libmd0
  Depends: libc6 (>= 2.14)
~/temp/rdepends$ ls -l
total 0
~/temp/rdepends$ ls -lR /var/cache/apt
/var/cache/apt:
total 69352
drwxr-xr-x 3 root root57344 Dec  1 19:46 archives
-rw-r--r-- 1 root root 35492253 Dec  1 21:00 pkgcache.bin
-rw-r--r-- 1 root root 35451043 Dec  1 21:00 srcpkgcache.bin

/var/cache/apt/archives:
total 4
-rw-r- 1 root root0 Apr 16  2022 lock
drwx-- 2 _apt root 4096 Dec  1 15:00 partial
ls: cannot open directory '/var/cache/apt/archives/partial': Permission denied
~/temp/rdepends$ 

/var/cache/apt/archives/partial was used at 3pm when libnghttp2-14
was downloaded. The {src,}pkgcache.bin files were created when the
9pm update took place. I see no extra .bin files.

Presumably you're running more commands than you revealed above?

Cheers,
David.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Albretch Mueller]

On 11/30/23, David Wright  wrote:
> On Thu 30 Nov 2023 at 21:05:38 (+), Albretch Mueller wrote:
>>  I also notice repeated copies of {src-, pkgcache}.bin files for each
>> downloaded package even though I am downloading them to specific
>> subdirectories in order to then install them using dpkg.
>>  Do you really need those binaries and cache instructions if you are
>> just downloading the installation dependencies? How do you remove,
>> disregard those kinds of caching strategies in a graceful way?
>
> Perhaps you could elaborate on the commands you're running.

 I am using apt-rdepends --follow=Depends 

 to download all dependencies into a subdirectory for each package
then I notice the same files: srcpkgcache.bin et pkgcache.bin in every
subdirectory.

> BTW could you not write part of your post in the Subject line

 I understand, It won't happen again
 lbrtchx

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Greg Wooledge]

On Thu, Nov 30, 2023 at 04:52:01PM -0600, David Wright wrote:
> BTW could you not write part of your post in the Subject line:
> in order to respond to that specific part of the post, the
> replier has either to top post, or paste the Subject line
> back into the correct place. That's ignoring the fact that
> many MUAs will truncate the Subject in their index list, so
> users won't see what the post is about.

Agreed.  Email etiquette suggests that a Subject: header should never
be longer than fits on one line of the terminal (and terminals are 80
columns wide, you heathens).  With the "Subject: " string taking 9
characters, and allowing another 4 characters for "Re: " and one more
character to prevent line-wrapping when writing to the 80th column,
this means your Subject: should be a maximum of 65 characters.  Shorter
is better.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[David Wright]

On Thu 30 Nov 2023 at 21:05:38 (+), Albretch Mueller wrote:
>  I also notice repeated copies of {src-, pkgcache}.bin files for each
> downloaded package even though I am downloading them to specific
> subdirectories in order to then install them using dpkg.
>  Do you really need those binaries and cache instructions if you are
> just downloading the installation dependencies? How do you remove,
> disregard those kinds of caching strategies in a graceful way?

Perhaps you could elaborate on the commands you're running.
I don't get "repeated" copies (whatever that means) of
{src-,}pkgcache.bin files when I download packages. Do you
mean the .bin files in /var/cache/apt/ are being overwritten,
or that there are files matching {src-,}pkgcache.bin.* in
that directory, or that you find {src-,}pkgcache.bin files
are being created in other locations?

BTW could you not write part of your post in the Subject line:
in order to respond to that specific part of the post, the
replier has either to top post, or paste the Subject line
back into the correct place. That's ignoring the fact that
many MUAs will truncate the Subject in their index list, so
users won't see what the post is about.

Cheers,
David.

Re: Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Dan Ritter]

Albretch Mueller wrote: 
>  I also notice repeated copies of {src-, pkgcache}.bin files for each
> downloaded package even though I am downloading them to specific
> subdirectories in order to then install them using dpkg.
>  Do you really need those binaries and cache instructions if you are
> just downloading the installation dependencies? How do you remove,
> disregard those kinds of caching strategies in a graceful way?


Does 'sudo apt clean' solve this for you?

-dsr-

Could/should you set Dir::Cache::{pkgcache, srcpkgcache} = ""; if all you are doing is locally downloading dependencies of an installation package?

[Albretch Mueller]

 I also notice repeated copies of {src-, pkgcache}.bin files for each
downloaded package even though I am downloading them to specific
subdirectories in order to then install them using dpkg.
 Do you really need those binaries and cache instructions if you are
just downloading the installation dependencies? How do you remove,
disregard those kinds of caching strategies in a graceful way?
 lbrtchx

Re: Help fixing package dependencies

[Timothy M Butterworth]

On Wed, Oct 11, 2023 at 9:39 AM Rishikesh Kakade <1rishikaka...@gmail.com>
wrote:

> Hi!
>
> I am trying to upgrade my system from Debian 11 to Debian 12. When I run
> sudo apt full-upgrade,
>
> λ ~/ main* sudo apt full-upgrade
>
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Error!
> 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:
> libboost-thread1.74.0 : Breaks: libboost-regex1.74.0-icu67
> libc6-dev : Breaks: libnetcdf-dev (<= 1:4.9.0-3) but 1:4.7.4-1 is to be
> installed
> libgirepository-1.0-1 : Breaks: libgjs0g (< 1.68.4-1+b1) but 1.66.2-1 is
> to be installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused by held packages.
>
>
>
> I am afraid that I will break my system if I attempt to solve it alone.
> Can anyone help me figure out how to fix the dependency issue?
>
> Rishi
>

First run:
sudo apt update
sudo apt upgrade
sudo apt full-upgrade

Second if that does not work then check your repose. You should have
something similar to:

less /etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm main non-free contrib
non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main
contrib non-free non-free-firmware

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Help fixing package dependencies during Debian 11 -> 12 upgrade

[Michael Kjörling]

On 11 Oct 2023 11:08 +0530, from 1rishikaka...@gmail.com (Rishikesh Kakade):
> I am trying to upgrade my system from Debian 11 to Debian 12.

Okay.

First things first: did you read through and follow the upgrade
preparation portions of the Bookworm release notes? Going straight for
`apt full-upgrade` _might_ work but is not the recommended upgrade
method for going from one major release to the next.

> When I run sudo apt full-upgrade,
> [...]
> libc6-dev : Breaks: libnetcdf-dev (<= 1:4.9.0-3) but 1:4.7.4-1 is to be
> installed

I didn't check the other ones, but this doesn't seem right. For that
package, Bullseye is at package version 1:4.7.4-1, but Bookworm is at
1:4.9.0-3+b1, so apt _shouldn't_ try to install 1:4.7.4-1 as part of
an upgrade to Bookworm.

My guess would be that you have some stale Bullseye repository in your
apt sources list, either from Debian or some third-party repository.
See 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#system-status

Please share the output of: grep -r -v '^#' /etc/apt/sources.list*

Please take care to not introduce any line breaks in that output which
are not in the original.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Help fixing package dependencies

[David]

On Wed, 2023-10-11 at 11:08 +0530, Rishikesh Kakade wrote:
> Hi!
> 
> I am trying to upgrade my system from Debian 11 to Debian 12. When I
> run
> sudo apt full-upgrade,

Well, to start with what appears to be the obvious, did you begin with
`apt-get update' first?
The, `apt-get full-upgrade'.

It's important to establish the current state of your system first.
Cheers!

> λ ~/ main* sudo apt full-upgrade
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Error!
> 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:
> libboost-thread1.74.0 : Breaks: libboost-regex1.74.0-icu67
> libc6-dev : Breaks: libnetcdf-dev (<= 1:4.9.0-3) but 1:4.7.4-1 is to
> be
> installed
> libgirepository-1.0-1 : Breaks: libgjs0g (< 1.68.4-1+b1) but 1.66.2-1
> is to
> be installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused
> by held packages.
> 
> 
> 
> I am afraid that I will break my system if I attempt to solve it
> alone. Can
> anyone help me figure out how to fix the dependency issue?
> 
> Rishi

-- 
`I intend to live forever,
or die trying'.

--Groucho Marx

Help fixing package dependencies

[Rishikesh Kakade]

Hi!

I am trying to upgrade my system from Debian 11 to Debian 12. When I run
sudo apt full-upgrade,

λ ~/ main* sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Error!
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:
libboost-thread1.74.0 : Breaks: libboost-regex1.74.0-icu67
libc6-dev : Breaks: libnetcdf-dev (<= 1:4.9.0-3) but 1:4.7.4-1 is to be
installed
libgirepository-1.0-1 : Breaks: libgjs0g (< 1.68.4-1+b1) but 1.66.2-1 is to
be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused
by held packages.



I am afraid that I will break my system if I attempt to solve it alone. Can
anyone help me figure out how to fix the dependency issue?

Rishi

Re: Understanding package dependencies

[Max Nikulin]

On 08/10/2023 01:45, Greg Wooledge wrote:

On Sat, Oct 07, 2023 at 08:27:11PM +0200, Sven Joachim wrote:

In the current case, "aptitude search '~Plsb-base'" does the trick.

Why on EARTH was this not ported to apt-patterns(7)?


It is one of two features I miss in "apt list".

Another one is --showformat similar to dpkg-query. "apt" is not for 
scripting, but sometimes I do not mind to add package descriptions.

Re: Understanding package dependencies

[Greg Wooledge]

On Sun, Oct 08, 2023 at 10:47:58AM +0200, Jörg-Volker Peetz wrote:
> Greg Wooledge wrote on 07/10/2023 20:45:
> > unicorn:~$ apt list '?provides(~nlsb-base)'
> > Listing... Error!
> > E: input:0-21: error: Unrecognized pattern '?provides'
> > ?provides(~nlsb-base)
> > ^
> > 
> How about
> 
>   apt list '?reverse-depends(?name(lsb-base))'

Reverse-depends isn't the same as Provides, though.

unicorn:~$ aptitude search '~Pmail-transport-agent'
p   courier-mta - Courier mail server - ESMTP daemon
p   courier-mta:i386- Courier mail server - ESMTP daemon
p   dma - lightweight mail transport agent  
p   dma:i386- lightweight mail transport agent  
[...]
unicorn:~$ apt list '?reverse-depends(~nmail-transport-agent)'
Listing... Done
unicorn:~$ 

The only way I know of, to get that list from apt, is by parsing it
out of the output of "apt-cache showpkg".

unicorn:~$ apt-cache showpkg mail-transport-agent | sed -n '/^Reverse 
Provides/,$p'
Reverse Provides: 
mta-local 1.0 (= )
exim4-daemon-light 4.96-15+deb12u2 (= )
exim4-daemon-heavy 4.96-15+deb12u2 (= )
dma:i386 0.13-1+b1 (= )
ssmtp 2.64-11 (= )
[...]

Which is... better than nothing, admittedly, but it still mystifies me
why this *one* feature is excluded from apt-patterns, when so many others
are included.

Re: Understanding package dependencies

[Jörg-Volker Peetz]

Greg Wooledge wrote on 07/10/2023 20:45:

On Sat, Oct 07, 2023 at 08:27:11PM +0200, Sven Joachim wrote:

Yes, aptitude can do that.   Quoting the manual[1]:

,
| ?provides(pattern), ~Ppattern
|
| Matches package versions which provide a package that matches the
| pattern. For instance, “?provides(mail-transport-agent)” will match
| all the packages that provide “mail-transport-agent”.
`

In the current case, "aptitude search '~Plsb-base'" does the trick.


Why on EARTH was this not ported to apt-patterns(7)?

unicorn:~$ apt list '?conflicts(~nlsb-base)'
Listing... Done
sysvinit-utils/stable,now 3.06-4 amd64 [installed]
sysvinit-utils/stable 3.06-4 i386
unicorn:~$ apt list '?provides(~nlsb-base)'
Listing... Error!
E: input:0-21: error: Unrecognized pattern '?provides'
?provides(~nlsb-base)
^


How about

  apt list '?reverse-depends(?name(lsb-base))'

or

  apt list '~RDepends:~nlsb-base'

Regards,
Jörg.

Re: Understanding package dependencies

[Greg Wooledge]

On Sat, Oct 07, 2023 at 08:27:11PM +0200, Sven Joachim wrote:
> Yes, aptitude can do that.   Quoting the manual[1]:
> 
> ,
> | ?provides(pattern), ~Ppattern
> | 
> | Matches package versions which provide a package that matches the
> | pattern. For instance, “?provides(mail-transport-agent)” will match
> | all the packages that provide “mail-transport-agent”.
> `
> 
> In the current case, "aptitude search '~Plsb-base'" does the trick.

Why on EARTH was this not ported to apt-patterns(7)?

unicorn:~$ apt list '?conflicts(~nlsb-base)'
Listing... Done
sysvinit-utils/stable,now 3.06-4 amd64 [installed]
sysvinit-utils/stable 3.06-4 i386
unicorn:~$ apt list '?provides(~nlsb-base)'
Listing... Error!
E: input:0-21: error: Unrecognized pattern '?provides'
   ?provides(~nlsb-base)
   ^

Re: Understanding package dependencies

[Sven Joachim]

On 2023-10-07 19:24 +0200, Steve Keller wrote:

> Greg Wooledge  writes:
>
>> Package: sysvinit-utils
>> [...]
>> Provides: lsb-base (= 11.1.0)
>>
>> When you remove the physical lsb-base package, the virtual package
>> provided by sysvinit-utils remains, to satisfy the dependencies of
>> ntpsec, rsync, etc.
>
> OK, that explains, why lsb-base can be removed without ntpsec. Is there
> a way to search for "Provides" in packages? I.e. show me all packages
> (installed or all) that provide some feature "foobar"?

Yes, aptitude can do that.   Quoting the manual[1]:

,
| ?provides(pattern), ~Ppattern
| 
| Matches package versions which provide a package that matches the
| pattern. For instance, “?provides(mail-transport-agent)” will match
| all the packages that provide “mail-transport-agent”.
`

In the current case, "aptitude search '~Plsb-base'" does the trick.

Cheers,
   Sven


1. https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html#searchProvides

Re: Understanding package dependencies

[Greg Wooledge]

On Sat, Oct 07, 2023 at 07:24:24PM +0200, Steve Keller wrote:
> Greg Wooledge  writes:
> 
> > Package: sysvinit-utils
> > [...]
> > Provides: lsb-base (= 11.1.0)
> >
> > When you remove the physical lsb-base package, the virtual package
> > provided by sysvinit-utils remains, to satisfy the dependencies of
> > ntpsec, rsync, etc.
> 
> OK, that explains, why lsb-base can be removed without ntpsec. Is there
> a way to search for "Provides" in packages? I.e. show me all packages
> (installed or all) that provide some feature "foobar"?

I couldn't find one within a minute or so of looking, so I simply
searched for "Provides:.*lsb-base" in /var/lib/dpkg/status.

Now that I've had a bit more time to ponder it, I recall that there's
"apt-cache showpkg".  It's not intuitive or easy to remember, but

unicorn:~$ apt-cache showpkg lsb-base
Package: lsb-base
[... LOTS of useless info ...]
Dependencies: 
11.6 - sysvinit-utils (2 3.05-4~) 
Provides: 
11.6 - lsb-base:i386 (= 11.6) 
Reverse Provides: 
sysvinit-utils:i386 3.06-4 (= 11.1.0)
sysvinit-utils 3.06-4 (= 11.1.0)

Re: Understanding package dependencies

[Steve Keller]

Greg Wooledge  writes:

> Package: sysvinit-utils
> [...]
> Provides: lsb-base (= 11.1.0)
>
> When you remove the physical lsb-base package, the virtual package
> provided by sysvinit-utils remains, to satisfy the dependencies of
> ntpsec, rsync, etc.

OK, that explains, why lsb-base can be removed without ntpsec. Is there
a way to search for "Provides" in packages? I.e. show me all packages
(installed or all) that provide some feature "foobar"?

Steve

Re: Understanding package dependencies

[Greg Wooledge]

On Sat, Oct 07, 2023 at 01:04:56PM +, Michael Kjörling wrote:
> On 7 Oct 2023 13:47 +0200, from keller.st...@gmx.de (Steve Keller):
> > # aptitude purge lsb-base
> > The following packages will be REMOVED:
> >   lsb-base{p}
> > 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> > Need to get 0 B of archives. After unpacking 12.3 kB will be freed.
> > Do you want to continue? [Y/n/?]
> > 
> > Won't continuing here leave ntpsec with an unresolved package dependency?

> I'm not sure if that's it, and I'm pretty sure I've never seen a `{p}`
> (is that aptitude's way of indicating that a package will be purged
> rather than just uninstalled; that which apt-get shows as `*`?), but
> might at least a partial explanation be that lsb-base in Bookworm is
> an empty transitional package?

That's definitely part of the whole picture, yes.

Package: sysvinit-utils
[...]
Provides: lsb-base (= 11.1.0)

When you remove the physical lsb-base package, the virtual package
provided by sysvinit-utils remains, to satisfy the dependencies of
ntpsec, rsync, etc.

Re: Understanding package dependencies

[Michael Kjörling]

On 7 Oct 2023 13:47 +0200, from keller.st...@gmx.de (Steve Keller):
> But how can this then be explained?
> 
> # aptitude why lsb-base
> i   ntpsec Depends lsb-base
> # aptitude show ntpsec | grep ^Depends
> Depends: adduser, lsb-base, netbase, python3, python3-ntp (= 
> 1.2.2+dfsg1-1+deb12u1), tzdata, libbsd0 (>= 0.0), libc6 (>= 2.34), libcap2 
> (>= 1:2.10), libssl3 (>= 3.0.0)
> # aptitude purge lsb-base
> The following packages will be REMOVED:
>   lsb-base{p}
> 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 12.3 kB will be freed.
> Do you want to continue? [Y/n/?]
> 
> Won't continuing here leave ntpsec with an unresolved package dependency?

I'm not sure if that's it, and I'm pretty sure I've never seen a `{p}`
(is that aptitude's way of indicating that a package will be purged
rather than just uninstalled; that which apt-get shows as `*`?), but
might at least a partial explanation be that lsb-base in Bookworm is
an empty transitional package?

On a freshly installed and up-to-date Bookworm VM, installing ntpsec
doesn't pull in lsb-base (the only additional package pulled in by
`apt-get install ntpsec` is python3-ntp), nor is lsb-base installed
after installation.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Understanding package dependencies

[Steve Keller]

I've always thought, that a package's dependencies must be full-filled
to install that package and that apt-get automatically manages these
dependencies.  And also, that if I remove a package, that all other
packages are removed, that depend on it.  Like this:

# aptitude purge bind9-libs
The following packages will be REMOVED:
  bind9-libs{p} libjemalloc2{u}
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 4668 kB will be freed.
The following packages have unmet dependencies:
 bind9-host : Depends: bind9-libs (= 1:9.18.19-1~deb12u1) but it is not 
going to be installed
 bind9 : Depends: bind9-libs (= 1:9.18.19-1~deb12u1) but it is not going to 
be installed
 bind9-dnsutils : Depends: bind9-libs (= 1:9.18.19-1~deb12u1) but it is not 
going to be installed
 bind9-utils : Depends: bind9-libs (= 1:9.18.19-1~deb12u1) but it is not 
going to be installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) bind9 [1:9.18.19-1~deb12u1 (now, stable-security)]
2) bind9-dnsutils [1:9.18.19-1~deb12u1 (now, stable-security)]
3) bind9-host [1:9.18.19-1~deb12u1 (now, stable-security)]
4) bind9-utils [1:9.18.19-1~deb12u1 (now, stable-security)]


But how can this then be explained?

# aptitude why lsb-base
i   ntpsec Depends lsb-base
# aptitude show ntpsec | grep ^Depends
Depends: adduser, lsb-base, netbase, python3, python3-ntp (= 
1.2.2+dfsg1-1+deb12u1), tzdata, libbsd0 (>= 0.0), libc6 (>= 2.34), libcap2 (>= 
1:2.10), libssl3 (>= 3.0.0)
# aptitude purge lsb-base
The following packages will be REMOVED:
  lsb-base{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 12.3 kB will be freed.
Do you want to continue? [Y/n/?]

Won't continuing here leave ntpsec with an unresolved package dependency?

Steve

Re: missing dependencies

[rhkramer]

On Sunday, February 20, 2022 01:33:49 AM to...@tuxteam.de wrote:
> > Does apt-file update (cuz its cache was empty) use a different set of
> > repo's? I always thought a synaptics->reload did exactly the same thing?
> 
> No, it shouldn't. And, if I read you above correctly, apt-file and apt
> do agree. Why synaptic doesn't I don't know (but I know pretty little
> about synaptic, anyway).

What isn't clear (to me) is whether Gene looked for it again with synaptic 
after the update that apt-get called for

Re: missing dependencies

[tomas]

On Sat, Feb 19, 2022 at 09:21:42PM -0500, gene heskett wrote:
> On Saturday, February 19, 2022 8:10:34 AM EST to...@tuxteam.de wrote:

[...]

> > Remember: apt-file is your friend!

> okaay:
> gene@coyote:~$ sudo apt-file search openssl/bio.h
> android-libboringssl-dev: /usr/include/android/openssl/bio.h
> libssl-dev: /usr/include/openssl/bio.h
> libwolfssl-dev: /usr/include/cyassl/openssl/bio.h
> libwolfssl-dev: /usr/include/wolfssl/openssl/bio.h
> 
> And apt just installed it, but synaptic refused to find it. I spent at 
> least an hour scrolling around to no avail when synaptics->search didn't 
> find it. WTH?
> 
> Does apt-file update (cuz its cache was empty) use a different set of 
> repo's? I always thought a synaptics->reload did exactly the same thing?

No, it shouldn't. And, if I read you above correctly, apt-file and apt
do agree. Why synaptic doesn't I don't know (but I know pretty little
about synaptic, anyway).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: missing dependencies

[gene heskett]

On Saturday, February 19, 2022 8:52:05 AM EST Greg Wooledge wrote:
> On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> > Got yet another CF, repo has missing -dev packages, specifically
> > openssl-dev
> *sigh*
> 
> unicorn:~$ apt-get -s install libssl-dev
> NOTE: This is only a simulation!
>   apt-get needs root privileges for real execution.
>   Keep also in mind that locking is deactivated,
>   so don't depend on the relevance to the real current situation!
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Suggested packages:
>   libssl-doc
> The following NEW packages will be installed:
>   libssl-dev
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Inst libssl-dev (1.1.1k-1+deb11u1 Debian:11.2/stable,
> Debian-Security:11/stable-security [amd64]) Conf libssl-dev
> (1.1.1k-1+deb11u1 Debian:11.2/stable,
> Debian-Security:11/stable-security [amd64])
> 
> 
> Instead of asking us, "Hey guys, I'm trying to install openssl-dev, but
> there's no package by that name.  What's the correct name in Debian?"
> you just jump to the conclusion that the "repo has missing -dev
> packages".
> 
> This is part of the reason why you keep having problems, I suspect.
> 
> .

Same story, wash rinse repeat for ncurses-dev.
apt just installed it, AFTER apt-file refreshed its cache, synaptic-
>reload(ed) several times could not find it, even hand scrolling thru the 
lib listings, So 'splain to me why synaptic, fully reloaded, could not 
find either of those packages??? I wasted hours hand scrolling thru the 
listings and I couldn't find them, and niether could synaptic. But apt-
file complained of an empty cache, and when updated found them both 
exactly where I and synaptic was looking.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: missing dependencies

[gene heskett]

On Saturday, February 19, 2022 8:10:34 AM EST to...@tuxteam.de wrote:
> On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> > Greetings all;
> > 
> > 
> > Got yet another CF, repo has missing -dev packages, specifically
> > openssl-dev for its includes including openssl/bio.h. can't make a
> > kernel without it.  ncurses-dev is also missing so I can't use make
> > menuconfig, and had to install 49 pkgs just to do a make xconfig.
> Gene,
> 
> if I only knew whether this is a request for help or just
> letting of steam, I'd try to be helpful ;-)
> 
> As it is, I'll just try to leave one hint here (which, see
> above, might be misplaced). What you're looking for is called
> libssl-dev, which you could have easily fourd out by doing
> an
> 
>   apt-file search openssl/bio.h
> 
> Remember: apt-file is your friend!
> 
> > No cheers, Gene
> 
> Cheers
okaay:
gene@coyote:~$ sudo apt-file search openssl/bio.h
android-libboringssl-dev: /usr/include/android/openssl/bio.h
libssl-dev: /usr/include/openssl/bio.h
libwolfssl-dev: /usr/include/cyassl/openssl/bio.h
libwolfssl-dev: /usr/include/wolfssl/openssl/bio.h

And apt just installed it, but synaptic refused to find it. I spent at 
least an hour scrolling around to no avail when synaptics->search didn't 
find it. WTH?

Does apt-file update (cuz its cache was empty) use a different set of 
repo's? I always thought a synaptics->reload did exactly the same thing?

/me goes off scratching what little hair I have left.

Tace care and stay well.
Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: missing dependencies

[Brian]

On Sat 19 Feb 2022 at 15:03:38 +0100, to...@tuxteam.de wrote:

> On Sat, Feb 19, 2022 at 08:52:05AM -0500, Greg Wooledge wrote:
> > On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> > > Got yet another CF, repo has missing -dev packages, specifically 
> > > openssl-dev
> 
> [...]
> 
> > This is part of the reason why you keep having problems, I suspect.
> 
> OTOH... everyone of us "keeps having problems". Ain't that an adequate
> description of "life"?
> 
> :-)

Indeed. But most users do not make a somg and a dance out of their
problems with Debian. :)

-- 
Brian.

Re: missing dependencies

[tomas]

On Sat, Feb 19, 2022 at 08:52:05AM -0500, Greg Wooledge wrote:
> On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> > Got yet another CF, repo has missing -dev packages, specifically openssl-dev

[...]

> This is part of the reason why you keep having problems, I suspect.

OTOH... everyone of us "keeps having problems". Ain't that an adequate
description of "life"?

:-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: missing dependencies

[Greg Wooledge]

On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> Got yet another CF, repo has missing -dev packages, specifically openssl-dev

*sigh*

unicorn:~$ apt-get -s install libssl-dev
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  libssl-doc
The following NEW packages will be installed:
  libssl-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst libssl-dev (1.1.1k-1+deb11u1 Debian:11.2/stable, 
Debian-Security:11/stable-security [amd64])
Conf libssl-dev (1.1.1k-1+deb11u1 Debian:11.2/stable, 
Debian-Security:11/stable-security [amd64])


Instead of asking us, "Hey guys, I'm trying to install openssl-dev, but
there's no package by that name.  What's the correct name in Debian?" you
just jump to the conclusion that the "repo has missing -dev packages".

This is part of the reason why you keep having problems, I suspect.

Re: missing dependencies

[tomas]

On Sat, Feb 19, 2022 at 04:41:46AM -0800, Gene Heskett wrote:
> Greetings all;
> 
> 
> Got yet another CF, repo has missing -dev packages, specifically openssl-dev 
> for its includes including openssl/bio.h. can't make a kernel without it.  
> ncurses-dev is also missing so I can't use make menuconfig, and had to 
> install 49 pkgs just to do a make xconfig.

Gene,

if I only knew whether this is a request for help or just
letting of steam, I'd try to be helpful ;-)

As it is, I'll just try to leave one hint here (which, see
above, might be misplaced). What you're looking for is called
libssl-dev, which you could have easily fourd out by doing
an

  apt-file search openssl/bio.h

Remember: apt-file is your friend!

> No cheers, Gene

Cheers
-- 
t


signature.asc
Description: PGP signature

missing dependencies

[Gene Heskett]

Greetings all;


Got yet another CF, repo has missing -dev packages, specifically openssl-dev 
for its includes including openssl/bio.h. can't make a kernel without it.  
ncurses-dev is also missing so I can't use make menuconfig, and had to install 
49 pkgs just to do a make xconfig.


No cheers, Gene

Re: I'm getting a dependencies error when trying to install roundcube 1.5.1 on my bullseye machine

[Andrei POPESCU]

On Sb, 11 dec 21, 06:04:09, Tim Woodall wrote:
> On Sat, 11 Dec 2021, Steve Dondley wrote:
> 
> > > I've not used apt to install packages from files but can you put
> > > ../roundcube*.deb?

Yes, that would have worked.
 
> > Thanks but I just figured it out literally 30 seconds ago. Had to do the
> > following:
 
[...]
 
> You might want to apt-mark auto the dependencies, currently they're set
> to manual.

+1

> And I'd create a local repo to hold the packages using apt-ftparchive -
> then, in future, all you'd need to do is update the repo and do apt-get
> upgrade to update the roundcube version after you'd built it.

+1

I've also seen reprepro suggested for local repositories, though it's 
probably overkill just for a few packages.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: I'm getting a dependencies error when trying to install roundcube 1.5.1 on my bullseye machine

[Tim Woodall]

On Sat, 11 Dec 2021, Steve Dondley wrote:







I've not used apt to install packages from files but can you put
../roundcube*.deb?

You need to install both roundcube and roundcube-core from your local
build.

If mt first suggestion doesn't work, try installing roundcube-core
first.

If you haven't built roundcube-core then you need to do that first.

Not sure why you used this pattern:

$ sudo apt-get install ../roundcube_*_*.deb

but

$ sudo apt-get install ../roundcube-core_*_*.deb

matches for roundcube-core


Thanks but I just figured it out literally 30 seconds ago. Had to do the 
following:


1) Get a list of all roundcube pacakges:

dpkg -l | grep roundcube

2) For each of the older, uwanted packages, do:

sudo apt-get remove 

3) Now, to install roundcube, you first have to install roundcube-core .deb 
package first. So the command given in the tutorial won't work. But you can't 
install roundcube-core until you install its dependencies:


sudo apt-get install ../roundcube-mysql_*_*.deb
sudo apt-get install ../roundcube-sqlite3_*_*.deb
sudo apt-get install ../roundcube-pgsql_*_*.deb

Note that above commands assume you are in the directory that the tutorial 
places you into.



4) No you can install roundcube-core

sudo apt-get install ../roundcube-core_*_*.deb

5) And now you can install the plain ol' "roundcube" package:

sudo apt-get install ../roundcube_*_*.deb

6) Finally, install the other misc. package:

sudo apt-get install ../roundcube-plugins_*_*.deb



apt-get autoremove roundcube might have removed the dependencies.

You might want to apt-mark auto the dependencies, currently they're set
to manual.

And I'd create a local repo to hold the packages using apt-ftparchive -
then, in future, all you'd need to do is update the repo and do apt-get
upgrade to update the roundcube version after you'd built it.

Tim

Re: I'm getting a dependencies error when trying to install roundcube 1.5.1 on my bullseye machine

[Steve Dondley]

I've not used apt to install packages from files but can you put
../roundcube*.deb?

You need to install both roundcube and roundcube-core from your local
build.

If mt first suggestion doesn't work, try installing roundcube-core
first.

If you haven't built roundcube-core then you need to do that first.

Not sure why you used this pattern:

$ sudo apt-get install ../roundcube_*_*.deb

but

$ sudo apt-get install ../roundcube-core_*_*.deb

matches for roundcube-core


Thanks but I just figured it out literally 30 seconds ago. Had to do the 
following:


1) Get a list of all roundcube pacakges:

dpkg -l | grep roundcube

2) For each of the older, uwanted packages, do:

sudo apt-get remove 

3) Now, to install roundcube, you first have to install roundcube-core 
.deb package first. So the command given in the tutorial won't work. But 
you can't install roundcube-core until you install its dependencies:


sudo apt-get install ../roundcube-mysql_*_*.deb
sudo apt-get install ../roundcube-sqlite3_*_*.deb
sudo apt-get install ../roundcube-pgsql_*_*.deb

Note that above commands assume you are in the directory that the 
tutorial places you into.



4) No you can install roundcube-core

sudo apt-get install ../roundcube-core_*_*.deb

5) And now you can install the plain ol' "roundcube" package:

sudo apt-get install ../roundcube_*_*.deb

6) Finally, install the other misc. package:

sudo apt-get install ../roundcube-plugins_*_*.deb

Re: I'm getting a dependencies error when trying to install roundcube 1.5.1 on my bullseye machine

[Tim Woodall]

On Fri, 10 Dec 2021, Steve Dondley wrote:

I'm running bullseye with roundcube version 1.4.11 currently installed. I am 
trying to upgrade to version 1.5.1.


I followed the instructions at "SimpleBackportCreation" at 
https://wiki.debian.org/SimpleBackportCreation


Everything went fine until the very last step:

===

$ sudo apt-get install ../roundcube_*_*.deb

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'roundcube' instead of '../roundcube_1.5.1+dfsg-1_all.deb'
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:
roundcube : Depends: roundcube-core (= 1.5.1+dfsg-1) but 1.4.11+dfsg.1-4 is 
to be installed

E: Unable to correct problems, you have held broken packages.




I tried "sudo apt-get remove roundcube" but that didn't help.

Can someone please tell me how I might resolve this?




I've not used apt to install packages from files but can you put
../roundcube*.deb?

You need to install both roundcube and roundcube-core from your local
build.

If mt first suggestion doesn't work, try installing roundcube-core
first.

If you haven't built roundcube-core then you need to do that first.

Not sure why you used this pattern:

$ sudo apt-get install ../roundcube_*_*.deb

but

$ sudo apt-get install ../roundcube-core_*_*.deb

matches for roundcube-core

I'm getting a dependencies error when trying to install roundcube 1.5.1 on my bullseye machine

[Steve Dondley]

I'm running bullseye with roundcube version 1.4.11 currently installed. 
I am trying to upgrade to version 1.5.1.


I followed the instructions at "SimpleBackportCreation" at 
https://wiki.debian.org/SimpleBackportCreation


Everything went fine until the very last step:

===

$ sudo apt-get install ../roundcube_*_*.deb

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'roundcube' instead of 
'../roundcube_1.5.1+dfsg-1_all.deb'

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:
 roundcube : Depends: roundcube-core (= 1.5.1+dfsg-1) but 
1.4.11+dfsg.1-4 is to be installed

E: Unable to correct problems, you have held broken packages.




I tried "sudo apt-get remove roundcube" but that didn't help.

Can someone please tell me how I might resolve this?

Re: What is libc5-i686 | lib32gcc1 (proliant package dependencies)

[The Wanderer]

On 2021-10-27 at 06:57, Alessandro Vesely wrote:

> Hi all,
> 
> I have a .deb package from HP (hp-health) that has this requirement,
> and doesn't install because of it.  It got damaged somehow during the
> last dist-upgrade.  I think I'd better re-install it.
> 
> I have both libc6:i386 and lib32gcc-s1 (on an AMD 64bit machine). 
> libc6-i686:i386  is tagged 'rc' transitional dummy package.

libc6, or libc5? The Subject line says the latter, but AFAIK the latter
hasn't been a thing for Quite A Long While Now (if indeed at all).

What version? On my system (tracking testing+stable), libc6:i386 is
available at versions 2.32-4 and 2.31-13+deb11u2, and neither one of
them is a transitional or a dummy package. I check with 'apt-cache
policy libc6:i386' and then 'apt-cache show libc6:i386'.

The 'rc' tag, as reported by e.g. 'dpkg -l', indicates "this package
used to be installed, but it's been removed, although its configuration
files have been left behind". I believe the 'r' stands for 'removed' and
the 'c' for 'config-files' or similar. So, if that's what you have
showing, then you don't actually have this package installed at the
moment. It seems possible that this might have been what changed during
the dist-upgrade you mentioned.

> HP doesn't seem to be inclined to update their support packages.
> Should I force the install, rebuild the package with a different
> DEBIAN/control, or something else?

If the dependencies actually list a package and version that aren't
available, for something as fundamental as the C library, I wouldn't
expect any good results from overriding the dependencies like that;
there might well be an actual incompatibility, such that at best you'd
get an installed program that wouldn't run.

> BTW, is the latter option just dpkg-deb -R followed by dpkg-deb -b?

That I don't know.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

What is libc5-i686 | lib32gcc1 (proliant package dependencies)

[Alessandro Vesely]

Hi all,

I have a .deb package from HP (hp-health) that has this requirement, and 
doesn't install because of it.  It got damaged somehow during the last 
dist-upgrade.  I think I'd better re-install it.


I have both libc6:i386 and lib32gcc-s1 (on an AMD 64bit machine).
libc6-i686:i386  is tagged 'rc' transitional dummy package.

HP doesn't seem to be inclined to update their support packages.  Should I 
force the install, rebuild the package with a different DEBIAN/control, or 
something else?


BTW, is the latter option just dpkg-deb -R followed by dpkg-deb -b?


Thanks for any hint
Ale
--

Re: Apt dependencies

[Ángel]

On 2020-12-05 at 18:48 +, Joe wrote:
> What does the >= sign mean as regards dependencies? I took it to mean
> 'this version or later', but apparently not.

It does.

> 
> I've had a logjam on sid for a while now, so I thought I'd
> investigate.
> 
> debfoster cannot be upgraded because of a dependency on guile-2.0-
> libs.
> 
> guile-2.0-libs depends on libgc1c2 (>= 1:7.2d) but it is not
> installable.
> 
> Currently installed version of libgc1c2 is 1:7.6.4-0.4.
> 
> Why does this not satisfy '>= 1:7.2d'?

It does:

$ dpkg --compare-versions 1:7.6.4-0.4 '>=' 1:7.2d
$ echo $?
0


The issue seem to lie in that there are two different packages
involved:
guile-2.0-libs depends on libgc1c2 (>= 1:7.2d)
debfoster depends on libgc1 (>= 1:7.2d)
libgc1 conflicts and replaces libgc1c2

I think guile-2.0-libs would need to be changed to depend on libgc1,
but that will probably also require a rebuild, to link with the new
library.

Apt dependencies

[Joe]

What does the >= sign mean as regards dependencies? I took it to mean
'this version or later', but apparently not.

I've had a logjam on sid for a while now, so I thought I'd investigate.

debfoster cannot be upgraded because of a dependency on guile-2.0-libs.

guile-2.0-libs depends on libgc1c2 (>= 1:7.2d) but it is not
installable.

Currently installed version of libgc1c2 is 1:7.6.4-0.4.

Why does this not satisfy '>= 1:7.2d'?

-- 
Joe

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Göktuğ Kayaalp]

> It looks as though you have installed from security.debian.org but now
> it's not in your sources.list. If you add a line like
>
> deb http://security.debian.org/  buster/updates main contrib non-free
>
> then do "apt-get update", does that help the "apt-get build-dep"?

This seems to have fixed the issue. I added the line and
updated, now I have this:

libtiff-dev:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 500
500 http://security.debian.org/debian-security stable/updates/main 
amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

Thanks a lot!

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Re: apt-get build-dep emacs-gtk: unmet dependencies

[Clive Standbridge]

> > $ apt-cache policy libtiff-dev libtiff5
> 
> The command (w/ libidn2-0 added) reports:
> 
> libtiff-dev:
>   Installed: (none)
>   Candidate: 4.0.10-4
>   Version table:
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libtiff5:
>   Installed: 4.1.0+git191117-2~deb10u1
>   Candidate: 4.1.0+git191117-2~deb10u1
>   Version table:
>  *** 4.1.0+git191117-2~deb10u1 100
> 100 /var/lib/dpkg/status
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libidn2-0:
>   Installed: 2.0.5-1+deb10u1
>   Candidate: 2.0.5-1+deb10u1
>   Version table:
>  *** 2.0.5-1+deb10u1 100
> 100 /var/lib/dpkg/status
>  2.0.5-1 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> 

Your installed versions of libtiff5 and libidn2-0 are the same as the versions 
currently in the buster security updates. Contrast:

$ apt-cache policy libtiff-dev libtiff5 libidn2-0
libtiff-dev:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 990
990 http://deb.debian.org/debian buster/main amd64 Packages
libtiff5:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 990
990 http://deb.debian.org/debian buster/main amd64 Packages
libidn2-0:
  Installed: 2.0.5-1+deb10u1
  Candidate: 2.0.5-1+deb10u1
  Version table:
 *** 2.0.5-1+deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2.0.5-1 990
990 http://deb.debian.org/debian buster/main amd64 Packages


It looks as though you have installed from security.debian.org but now it's not 
in your sources.list. If you add a line like

deb http://security.debian.org/  buster/updates main contrib non-free

then do "apt-get update", does that help the "apt-get build-dep"?

-- 
Cheers,
Clive

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Göktuğ Kayaalp]

> You could try downgrading the two library packages explicitly:
>
> $ apt-get install libtiff5=1.0.10-4 libidn2-0=2.0.5-1

This is what I tried eventually, and it worked, thanks!

> That might result in other errors if doing this breaks versioned
> dependencies from other packages, but it's at least a starting point,
> and worth trying.

It luckily didn’t.

> The real questions are A: how you wound up with these newer versions
> installed in the first place, and B: whether there are similarly "newer
> than anything available in your-configured repos" versions of any
> *other* packages installed.

For A, well, my installation process is like this: use netinst (first I
had tried w/ 10.0, the last time I downloaded 10.2, because who knows,
but it persisted), usual stuff, partitioning (UEFI, rest is ext4, one
LVM vg which includes / and /home, separate /boot in primary partition),
then install, selecting print server, ssh server, and standard packages
(bottom three in tasksel screen).  Then, I reboot and run a script that
basically builds up an ‘apt-get install ...’ command with ~200 pkgs
(ends up installing >4k dependencies).  It uses usual debian stable
repos.  No local .debs, no other repos.  I don’t even use
backports. /etc/apt/preferences is empty.  FWIW, the mentioned
installation command is as follows:

,
| apt-get install -y apt-transport-https curl cups-bsd dnsutils equivs
| gawk gvfs-bin net-tools netcat-openbsd telnet traceroute bind9utils
| moreutils lftp libpam-cgroup libpam-cgfs bridge-utils qemu rsync
| openssh-server network-manager smartmontools entr docker.io snapd rar
| unrar dunst pasystray i3-wm i3status i3lock xinit libxrandr-dev
| network-manager-gnome dbus-x11 pulseaudio pulseaudio-utils pavucontrol
| alsa-oss alsa-utils alsamixergui pcmanfm ristretto xbacklight feh
| gvfs-backends gvfs-fuse okular cheese gimp gparted libreoffice
| libreoffice-gtk3 libreoffice-gnome mpv simple-scan transmission-gtk
| vokoscreen redshift-gtk suckless-tools laptop-mode-tools xclip xdotool
| xinput libnotify-bin devhelp audacity flameshot xfce4-clipman compton
| dconf-editor wmctrl arandr inkscape pdfsam xarchiver lmms libjansson-dev
| libpoppler-glib-dev libpoppler-private-dev spek praat python3-matplotlib
| python3-numpy python3-scipy python3-matplotlib python3-pandas
| python3-sympy python3-nose texlive-full perl-tk pass pv tmux units vim
| vorbis-tools vorbisgain w3m w3m-el webalizer whois syncthing libnss-mdns
| mailutils mairix mutt mpop msmtp procmail certbot dirmngr youtube-dl
| hugo inotify-tools pandoc fbi ddgr hledger jq djvulibre-bin gitit lynx
| pwgen gnupg2 qemu-utils qemu-system-x86 build-essential cvs git git-cvs
| git-email mercurial python-hglib python-dulwich python-fastimport
| python3-pip quilt rcs subversion autoconf autoconf-archive automake
| bmake libuniversal-isa-perl libimage-exiftool-perl libswitch-perl
| cpanminus liblocal-lib-perl perlbrew python python-pip python3-tk
| python3-venv ipython3 python3-notify2 r-base r-recommended r-doc-info
| r-cran-tidyverse r-cran-rio r-cran-psych ruby bundler ri
| haskell-platform haskell-platform-doc redis-server redis-tools gjs
| libgjs-dev gnome-js-common valac valadoc gnuplot feedgnuplot
| exuberant-ctags gdb strace make-doc gawk-doc apt-doc autoconf-doc
| bash-doc binutils-doc aspell-doc binutils-doc bzip2-doc cvs-doc
| debconf-doc diffutils-doc ffmpeg-doc gdb-doc gettext-doc git-doc
| glibc-doc gmp-doc gnuplot-doc gnutls-doc graphviz-doc grub-doc
| imagemagick-doc libtool-doc m4-doc mailutils-doc make-doc multiboot-doc
| ncurses-doc parted-doc pinentry-doc python-apt-doc python-certbot-doc
| python-doc python-numpy-doc python-setuptools-doc python3-doc
| readline-doc rsyslog-doc sgml-base-doc sharutils-doc sqlite3-doc tar-doc
| vim-doc libgtk-3-doc libcairo2-doc libxaw-doc libx11-doc libxcb-doc
| libglib2.0-doc iproute2-doc libasound2-doc docker-doc
| libreoffice-help-en-us
`


> Tracking those down and fixing them would definitely be possible, but
> honestly, if this system was installed so recently you're probably
> better off doing the reinstall and hoping whatever error it was doesn't
> happen this time.

I persistently got the same results after reinstalling twice (botched
one trying to use btrfs on root).  I suppose it could be a problem with
Debian reports.  Do you think I should report this as a bug?

In any case, I’ll try to reinstall on a VM in a few days, maybe this is
a temporary issue w/ package archives, or a packaging bug.


-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[The Wanderer]

On 2020-02-02 at 17:57, İ. Göktuğ Kayaalp wrote:

>> In turn, please respond on-list only
> 
> I'll try, but I can't use my usual MUA ATM, so sorry if I fail at that.
> 
>> $ apt-cache policy libtiff-dev libtiff5
> 
> The command (w/ libidn2-0 added) reports:
> 
> libtiff-dev:
>   Installed: (none)
>   Candidate: 4.0.10-4
>   Version table:
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libtiff5:
>   Installed: 4.1.0+git191117-2~deb10u1
>   Candidate: 4.1.0+git191117-2~deb10u1
>   Version table:
>  *** 4.1.0+git191117-2~deb10u1 100
> 100 /var/lib/dpkg/status
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

So apparently you have a newer version of libtiff5 installed (from
somewhere), but no matching newer version of libtiff-dev is available...

> libidn2-0:
>   Installed: 2.0.5-1+deb10u1
>   Candidate: 2.0.5-1+deb10u1
>   Version table:
>  *** 2.0.5-1+deb10u1 100
> 100 /var/lib/dpkg/status
>  2.0.5-1 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

...and similarly a newer version of libidn2-0; you didn't show
libidn-dev, but I'm guessing the same "no newer version available" holds
true there.

You could try downgrading the two library packages explicitly:

$ apt-get install libtiff5=1.0.10-4 libidn2-0=2.0.5-1

That might result in other errors if doing this breaks versioned
dependencies from other packages, but it's at least a starting point,
and worth trying.

The real questions are A: how you wound up with these newer versions
installed in the first place, and B: whether there are similarly "newer
than anything available in your-configured repos" versions of any
*other* packages installed.

Tracking those down and fixing them would definitely be possible, but
honestly, if this system was installed so recently you're probably
better off doing the reinstall and hoping whatever error it was doesn't
happen this time.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> In turn, please respond on-list only

I'll try, but I can't use my usual MUA ATM, so sorry if I fail at that.

> $ apt-cache policy libtiff-dev libtiff5

The command (w/ libidn2-0 added) reports:

libtiff-dev:
  Installed: (none)
  Candidate: 4.0.10-4
  Version table:
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
libtiff5:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 100
100 /var/lib/dpkg/status
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
libidn2-0:
  Installed: 2.0.5-1+deb10u1
  Candidate: 2.0.5-1+deb10u1
  Version table:
 *** 2.0.5-1+deb10u1 100
100 /var/lib/dpkg/status
 2.0.5-1 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages


I don't have any holds in my prefs.  "showholds" shows none.

I'll probably try a reinstall and report if I still fail installing
emacs25 builddeps.

Cheers,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> In my experience with 8 and before, yes, it may be a sign of trouble
> ahead. Was there an apt-get process spinning on a CPU after that point
> in the install?

I didn't check, so IDK.

> IIRC the network-assisted install of a package may have failed because
> the pkg couldn't be found online (say, with sources.list in some certain
> state). Then the install asks for the next mount but fails quietly. It's
> a couple years since Ive had to deal with this.

And I was indeed using the netinst ISO, so it's highly likely it skipped
something.

Guess I just reinstall, that seems to be easier than tracking the cause
of this error.

Cheers,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[deloptes]

İ. Göktuğ Kayaalp wrote:

>> But libgnutls28-dev is in buster
> 
> They all are, the problem is that build-dep:emacs requires packages
> which seem to require some downgrades.  These are not major downgrades,
> but minor version or debian package version:
> 
> libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1
> is to be installed
> 
> libgnutls28-dev : Depends: libidn2-dev but it is not going to be installed
> libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be
> installed
> 
> libmagick++-6.q16-dev : Depends: libmagickcore-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be installed
> Depends: libmagickwand-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be
> installed
> 
> libmagickcore-6.q16-dev : Depends: libtiff-dev but it is not going to be
> installed libmagickwand-6.q16-dev : Depends: libmagickcore-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be installed
> 
> So there's a minor version mismatch w/ libtiff5 and a debian patch
> version mismatch w/ libidn2-0.
> 
> Is there any way I resolve this w/o making a mess?

Don't know what you've done to your system, but here

root@debian10:~# apt-get install libtiff-dev libmagick++-6.q16-dev
libidn2-dev
The following NEW packages will be installed:
  autoconf automake autotools-dev bzip2-doc gir1.2-freedesktop
gir1.2-gdkpixbuf-2.0 gir1.2-rsvg-2.0 icu-devtools javascript-common
libblkid-dev
  libbz2-dev libcairo-gobject2 libcairo-script-interpreter2 libcairo2-dev
libcroco3 libdjvulibre-dev libdpkg-perl libexif-dev libexif-doc libffi-dev
  libfile-fcntllock-perl libfontconfig1-dev libfreetype6-dev
libgdk-pixbuf2.0-dev libglib2.0-bin libglib2.0-dev libglib2.0-dev-bin
libice-dev libicu-dev
  libidn2-dev libilmbase-dev libjbig-dev libjpeg-dev libjpeg62-turbo-dev
libjs-jquery liblcms2-dev liblqr-1-0-dev libltdl-dev liblzma-dev
  libmagick++-6-headers libmagick++-6.q16-8 libmagick++-6.q16-dev
libmagickcore-6-arch-config libmagickcore-6-headers libmagickcore-6.q16-dev
  libmagickwand-6-headers libmagickwand-6.q16-dev libmount-dev
libopenexr-dev libopenjp2-7-dev libpcre16-3 libpcre3-dev libpcre32-3
libpcrecpp0v5
  libpixman-1-dev libpng-dev libpng-tools libpthread-stubs0-dev librsvg2-2
librsvg2-common librsvg2-dev libselinux1-dev libsepol1-dev libsigsegv2
  libsm-dev libtiff-dev libtiffxx5 libtool libwmf-dev libx11-dev libxau-dev
libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxdmcp-dev libxext-dev
  libxml2-dev libxrender-dev libxt-dev m4 pkg-config uuid-dev
x11proto-core-dev x11proto-dev x11proto-xext-dev xorg-sgml-doctools
xtrans-dev zlib1g-dev
0 upgraded, 88 newly installed, 0 to remove and 0 not upgraded.
Need to get 43.1 MB of archives.
After this operation, 142 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Install the dependencies required and build.

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Nicholas Geovanis]

On Sun, Feb 2, 2020, 9:51 AM İ. Göktuğ Kayaalp  wrote:

> Hi all,
> 
> Lastly, there was an error during installation yesterday, package
> installation was paused when I returned to my computer, so I restarted
> the installation process.  It downloaded one more package and installed
> it, and the rest was fine.  Could that have anything to do with the
> present situation?
>

In my experience with 8 and before, yes, it may be a sign of trouble ahead.
Was there an apt-get process spinning on a CPU after that point in the
install?
IIRC the network-assisted install of a package may have failed because the
pkg couldn't be found online (say, with sources.list in some certain
state). Then the install asks for the next mount but fails quietly. It's a
couple years since Ive had to deal with this.

Thanks in advance,
> -gk.
>
> --
> İ. Göktuğ Kayaalp / @cadadr / 
> pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
>

Re: apt-get build-dep emacs-gtk: unmet dependencies

[The Wanderer]

(I'm replying both public and private in response to your request for
such in another message. In turn, please respond on-list only -
preferably to the copy transmitted via the list, if possible; the way
you replied to deloptes seems to have produced the desired effect, at
least by what is publicly visible.)

On 2020-02-02 at 11:55, İ. Göktuğ Kayaalp wrote:

>> But libgnutls28-dev is in buster
> 
> They all are, the problem is that build-dep:emacs requires packages
> which seem to require some downgrades.  These are not major downgrades,
> but minor version or debian package version:
> 
> libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1 is 
> to be installed

What versions of libtiff-dev do you have available? In particular, what does

$ apt-cache policy libtiff-dev libtiff5

say?

> libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be 
> installed

Similarly here.

> So there's a minor version mismatch w/ libtiff5 and a debian patch
> version mismatch w/ libidn2-0.
> 
> Is there any way I resolve this w/o making a mess?

Almost certainly. You just have to figure out what is making it decide
not to upgrade libtiff5 and libidn2.

The most common reasons in my experience are package holds / pins; I
think there are other reasons possible, but I can't think of them
offhand.

Is there anything relevant in /etc/apt/preferences, or in files inside
/etc/apt/preferences.d/ ?

What does

$ apt-mark showhold

report?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

BTW I'd really appreciate if you could reply to me on-list instead of to
the list only, given I'm not subscribed to the list.

Thanks a lot in advance!

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> But libgnutls28-dev is in buster

They all are, the problem is that build-dep:emacs requires packages
which seem to require some downgrades.  These are not major downgrades,
but minor version or debian package version:

libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1 is 
to be installed

libgnutls28-dev : Depends: libidn2-dev but it is not going to be installed
libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be 
installed

libmagick++-6.q16-dev : Depends: libmagickcore-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed
Depends: libmagickwand-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed

libmagickcore-6.q16-dev : Depends: libtiff-dev but it is not going to be 
installed
libmagickwand-6.q16-dev : Depends: libmagickcore-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed

So there's a minor version mismatch w/ libtiff5 and a debian patch
version mismatch w/ libidn2-0.

Is there any way I resolve this w/o making a mess?

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[deloptes]

İ. Göktuğ Kayaalp wrote:

> I follow Emacs' master branch for my day-to-day use, so I need to build
> it manually for my daily workflow.  Yesterday I did a fresh reinstall of
> Debian 10, after which I haven't been able to install build dependencies
> for emacs25 or emacs-gtk.  The error is as follows:
> 
> ,
> | Reading package lists... Done
> | Picking 'emacs' as source package instead of 'emacs25'
> | Reading package lists... Done
> | Building dependency tree
> | Reading state information... Done
> | 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:
> | builddeps:emacs : Depends: libtiff-dev but it is not going to be
> | installed Depends: libgnutls28-dev but it is not going to be installed
> | Depends: libmagick++-6.q16-dev but it is not going to be installed
> | E: Unable to correct problems, you have held broken packages.
> `

But libgnutls28-dev is in buster

https://packages.debian.org/buster/amd64/libgnutls28-dev/download

perhaps you need to setup the sources properly and apt-get update/upgrade
and try again

same for libtiff-dev

https://packages.debian.org/buster/amd64/libtiff-dev/download

and libmagick++-6.q16-dev

https://packages.debian.org/buster/amd64/libmagick++-6.q16-dev/download

regards

apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

Hi all,

I follow Emacs' master branch for my day-to-day use, so I need to build
it manually for my daily workflow.  Yesterday I did a fresh reinstall of
Debian 10, after which I haven't been able to install build dependencies
for emacs25 or emacs-gtk.  The error is as follows:

,
| Reading package lists... Done
| Picking 'emacs' as source package instead of 'emacs25'
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| 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:
|  builddeps:emacs : Depends: libtiff-dev but it is not going to be installed
|Depends: libgnutls28-dev but it is not going to be 
installed
|Depends: libmagick++-6.q16-dev but it is not going to be 
installed
| E: Unable to correct problems, you have held broken packages.
`

The output for emacs-gtk is also identical.  My /etc looks like this:
https://github.com/cadadr/configuration/tree/master/systems/alpha/etc

When I investigate further, trying to "apt-get install" the packages
with unmet dependencies, my observation is that installing these
packages requires downgrading some dependencies.

Is this a temporary problem, or does it have anything to do with my
configuration?  If it's possible, how can I fix this?  I really need a
build of Emacs ASAP, so I'm willing to force downgrade or upgrade any
packages if they don't really pose a problem to the end user.

Lastly, there was an error during installation yesterday, package
installation was paused when I returned to my computer, so I restarted
the installation process.  It downloaded one more package and installed
it, and the rest was fine.  Could that have anything to do with the
present situation?

Thanks in advance,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Dependencies et al (was: Default Debian install harassed me)

[Felmon Davis]

On Mon, 7 Oct 2019, Michael Stone wrote:


On Mon, Oct 07, 2019 at 04:39:56PM +0300, Reco wrote:

No, I got you first time. Rather it's my response deviated elsewhere.

I see nothing in those three packages that would qualify as "xyzzy".
Alternatives? No. Mime types registration? No.
About the only common thing about all three packages is that they are
GUI archivers.
I do not question a choice of these three archivers as "lxqt"
dependency. What I do question is the kind of dependency itself.


I don't agree that responding to a troll will lead to a beneficial outcome. 
In this case, unless you're specifically trying to remove all of these 
specific dependencies (for no apparent reason) *it simply doesn't matter*. 
Saying, "there was a troll post which shows that this is an issue" just isn't 
compelling. Are there any real users with valid use cases for which this as 
an issue? If not, why encourage another dozen messages about it?


not sure about encouraging a dozen messages as such but the discussion 
has been very instructive for me at least.


fjd

--
Felmon Davis

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Brian]

On Tue 08 Oct 2019 at 00:25:44 -0500, David Wright wrote:

> On Mon 07 Oct 2019 at 18:42:38 (+0100), Brian wrote:
> > On Mon 07 Oct 2019 at 15:09:09 +0200, Thomas Schmitt wrote:
> > 
> > [...]
> > 
> > > But how do Debian list servers know ?
> > 
> > A good question. How are my mails matched with my subscribed address
> > so that I am awarded the accolade of LDOSUBSCRIBER? On the basis that
> > my past statements about the SMTP protocol (whatever they were) have
> > not been well received, I decline to offer any suggestion.
> 
> Have we been told what your subscribed address is? I've assumed
> that it's the one in the envelope-from of the post I'm replying to.
> (I don't want to quote it.) Is that correct? Or maybe that …CII.eu one?

A decent assumption but, unfortunately, not correct. I've come to the
tentative conclusion that Debian can somehow link my envelope-from and
the subscribed address via their A records (or something like that).

Note that there isn't any LDOSUBSCRIBER in the headers of this mail.
 
> > > Is it because Exim 4.89 said "MAIL FROM:<...subscribed.address...>" to
> > > lists.debian.org ?
> > 
> > "subscribed.address" is the HELO and can be what I want it to be. See
> > the headers of my previous mail.
> 
> Why would you use a "subscribed.address" (presumably an email address)
> for your HELO (presumably actually a EHLO). I was under the impression
> that it should be a domain, ie a FQDN.

Sorry, I was probably less than precise. The 127.0.1.1 line in /etc/hosts
is a FQDN and is used by exim for the HELO/EHLO. /etc/mailname determines
the envelope-from.

> > > Or is it because the first mail hop added "envelope-from" to its Received:
> > > header ?
> > > 
> > >   Received: from ... by ... with local (Exim 4.89)
> > >   (envelope-from <...>)
> > >   id 1iHRiB-0006S7-Ks
> > >   for debian-user@lists.debian.org; Mon, 07 Oct 2019 13:01:59 
> > > +0100
> > 
> > I can alter that too, and still be designated LDOSUBSCRIBER.
> 
> Have we observed that? I only had LDOSUBSCRIBER bestowed on me when my
> envelope-from became the same as my subscribed address, which followed as
> a consequence of my adopting the .corp domain name last year after seeing
> https://www.theregister.co.uk/2018/02/12/icann_corp_home_mail_gtlds/
> Until then, exim4 didn't seem able to rewrite my headers because I
> didn't have a dot in my FQDN, only an unadorned hostname.

What I altered was the HELO/EHLO; it made no difference. Altering the
envelope-from did, but it would be unwise to assume I am not subscribed
to the list and receiving all mails. No Ccs needed. :)

-- 
Brian.

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Joe]

On Tue, 8 Oct 2019 08:52:11 -0400
Greg Wooledge  wrote:

> On Tue, Oct 08, 2019 at 09:13:31AM +0100, Joe wrote:
> > On Tue, 8 Oct 2019 00:25:44 -0500
> > David Wright  wrote:  
> > > Why would you use a "subscribed.address" (presumably an email
> > > address) for your HELO (presumably actually a EHLO). I was under
> > > the impression that it should be a domain, ie a FQDN.  
> > 
> > It should actually be a hostname, it's the official public name of
> > the mail server, though not of course its local network name. It
> > must be resolvable in public DNS. In practice, not much of this is
> > enforced, and you can get away with a domain name and, apparently,
> > an email address.  
> 
> "Enforcement" is entirely up to the receiver's discretion. 

Yes, that's what I meant, there's nobody else to enforce anything. But
I've never had an email rejected for a mismatched HELO.

> Some
> receivers use it as an anti-spam measure -- if your HELO string
> doesn't resolve, they won't accept your connection.

Yes, I do that, and I think it's the default for Exchange servers. A
look through the Exim configuration file gives a lot of anti-spam hints
in terms of the built-in options.

>  I've even heard
> of receivers who attempt to make an STMP connection back to the MX of
> your HELO domain, to make sure you have a running incoming SMTP
> service.
> 
I haven't seen that one, that I'm aware of. But that presumably is
circumvented simply by using a HELO for a domain that is known to run a
mail server. In the days when I used Telnet to talk to mail servers, I
used a well-known six-character domain name for my HELO for brevity,
with which I had no connection whatever. No server ever refused it.

> Other receivers may simply log it, or ignore it altogether.
> 

Indeed, but it's of value. A lot of people seem to think that using
their IP address, or my own IP address or domain name as their HELO is
clever.

-- 
Joe

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Greg Wooledge]

On Tue, Oct 08, 2019 at 09:13:31AM +0100, Joe wrote:
> On Tue, 8 Oct 2019 00:25:44 -0500
> David Wright  wrote:
> > Why would you use a "subscribed.address" (presumably an email address)
> > for your HELO (presumably actually a EHLO). I was under the impression
> > that it should be a domain, ie a FQDN.
> 
> It should actually be a hostname, it's the official public name of the
> mail server, though not of course its local network name. It must be
> resolvable in public DNS. In practice, not much of this is enforced,
> and you can get away with a domain name and, apparently, an email
> address.

"Enforcement" is entirely up to the receiver's discretion.  Some receivers
use it as an anti-spam measure -- if your HELO string doesn't resolve,
they won't accept your connection.  I've even heard of receivers who
attempt to make an STMP connection back to the MX of your HELO domain,
to make sure you have a running incoming SMTP service.

Other receivers may simply log it, or ignore it altogether.

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Joe]

On Tue, 8 Oct 2019 00:25:44 -0500
David Wright  wrote:


> > 
> > "subscribed.address" is the HELO and can be what I want it to be.
> > See the headers of my previous mail.  
> 
> Why would you use a "subscribed.address" (presumably an email address)
> for your HELO (presumably actually a EHLO). I was under the impression
> that it should be a domain, ie a FQDN.

It should actually be a hostname, it's the official public name of the
mail server, though not of course its local network name. It must be
resolvable in public DNS. In practice, not much of this is enforced,
and you can get away with a domain name and, apparently, an email
address.

It's a while since I did any email diagnostics, but certainly the HELO
pretty much only had to exist, it didn't seem to be checked very much.
I have seen email from a Small Business Server refused because the
default HELO was the invalid domain name x.local, as someone had
forgotten to set it properly. I can't be bothered (i.e. I haven't had to
do it yet) setting different HELOs for each domain that I use, and it
has never been a problem.

Neither does the MX record have to match any email address, nor the PTR
record for the sending IP address. There are many complex setups where
a business might send through one third-party SMTP server and receive
through the SMTP server of a mail-cleaning service, for example. The
only constraint (again, so far) on a sending address PTR is that it must
have a complementary A record, which does not have to be the address
that the MX points to or anything related to the email itself. Many ISPs
cannot handle multiple PTRs for the same IP address, at least not in
their user control panels, though they are permitted by RFC.

-- 
Joe

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[David Wright]

On Mon 07 Oct 2019 at 18:42:38 (+0100), Brian wrote:
> On Mon 07 Oct 2019 at 15:09:09 +0200, Thomas Schmitt wrote:
> 
> [...]
> 
> > But how do Debian list servers know ?
> 
> A good question. How are my mails matched with my subscribed address
> so that I am awarded the accolade of LDOSUBSCRIBER? On the basis that
> my past statements about the SMTP protocol (whatever they were) have
> not been well received, I decline to offer any suggestion.

Have we been told what your subscribed address is? I've assumed
that it's the one in the envelope-from of the post I'm replying to.
(I don't want to quote it.) Is that correct? Or maybe that …CII.eu one?

> > Is it because Exim 4.89 said "MAIL FROM:<...subscribed.address...>" to
> > lists.debian.org ?
> 
> "subscribed.address" is the HELO and can be what I want it to be. See
> the headers of my previous mail.

Why would you use a "subscribed.address" (presumably an email address)
for your HELO (presumably actually a EHLO). I was under the impression
that it should be a domain, ie a FQDN.

> > Or is it because the first mail hop added "envelope-from" to its Received:
> > header ?
> > 
> >   Received: from ... by ... with local (Exim 4.89)
> >   (envelope-from <...>)
> >   id 1iHRiB-0006S7-Ks
> >   for debian-user@lists.debian.org; Mon, 07 Oct 2019 13:01:59 +0100
> 
> I can alter that too, and still be designated LDOSUBSCRIBER.

Have we observed that? I only had LDOSUBSCRIBER bestowed on me when my
envelope-from became the same as my subscribed address, which followed as
a consequence of my adopting the .corp domain name last year after seeing
https://www.theregister.co.uk/2018/02/12/icann_corp_home_mail_gtlds/
Until then, exim4 didn't seem able to rewrite my headers because I
didn't have a dot in my FQDN, only an unadorned hostname.

Cheers,
David.

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[David Wright]

On Mon 07 Oct 2019 at 15:09:09 (+0200), Thomas Schmitt wrote:
> i wrote:
> > > To my best knowledge, "X-Spam-Status: ... tests=...,LDOSUBSCRIBER,..."
> > > says that the "From:" address of the mail is subscribed.
> 
> Brian wrote:
> > Are you sure it is the From: and not the envelope From? My From: is
> > not subscribed.
> 
> Interesting observation.
> So the address by which you submit your mail to the remote server is
> subscribed and it is not the "From:" address which your mail client
> writes into the header part of the mail ?
> 
> I wonder whether my mail provider would allow me to send via SMTP
>   MAIL FROM:
>   RCPT TO:debian-user@lists.debian.org
> and then by DATA
>   From: "Somebody Else" 

It's fairly easy to find out by trying it out, only obviously in an
email to yourself, not the list. Perhaps not as easy as it was,
because unencrypted telnet has all but gone. And I've also found that
my ISP is more "impatient" and times out fairly quickly, so nowadays
I assemble the whole email in an emacs buffer and paste it into the
session all in one go. Here's an example, suitably mangled:

$ openssl s_client -starttls smtp -crlf -connect 
smtp.some.submission.host.tld:12345

That opens the session, and I only press Return when I've copied the
email itself into the paste buffer. Here's the email, and there's
a blank line after the header.

ehlo wren.corp
auth plain MyAuthenticationNameAndPasswordInBase64==
mail from:realusern...@realdomain.tld
rcpt to:
data
From: Whoever You Want To Be 
to: 
subject: hand written test 01

Hand written test 01
You could duplicate the headers here as a record
.
quit

I do it all in a script session so that I get a recording, from which
I snip the authentication lines before archiving it.
BTW the string in the authentication line above is generated with:
$ echo -e -n '\0username\0password' | base64
Obviously I'm assuming that your ISP has facilities comparable to
mine, which are (I use two):

250-PIPELINING
250-SIZE 2048
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

250-AUTH LOGIN PLAIN
250-SIZE 3000
250-8BITMIME
250 OK

However, I see lots of DKIM stuff in your emails, so it might not be
as simple as this for you. But in principle, it should work.

   There is no inherent relationship between either "reverse" (from
   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
   transaction ("envelope") and the addresses in the header section.
   (RFC 5321.)

> But how do Debian list servers know ?
> Is it because Exim 4.89 said "MAIL FROM:<...subscribed.address...>" to
> lists.debian.org ?
> Or is it because the first mail hop added "envelope-from" to its Received:
> header ?

I've always assumed the envelope from is generated from the 'mail
from' line, and that the envelope should reach the Debian list
processing system unchanged.

>   Received: from ... by ... with local (Exim 4.89)
>   (envelope-from <...>)
>   id 1iHRiB-0006S7-Ks
>   for debian-user@lists.debian.org; Mon, 07 Oct 2019 13:01:59 +0100
> 
> (I wonder where "envelope-from" in "Received:" is specified. The word
>  does neither appear in RFC5322 nor in RFC5321.)

I've always assumed that what is in parentheses is all "noise" as far
as SMTP is concerned, like that Exim version number, the envelope-from
and, in your email for example, (Client did not present a certificate).

> ---
> 
> > > Nevertheless, if i have no other indication then i normally add a "Cc:"
> > > to the thread starter if i do not see LDOSUBSCRIBER among the spam tests.
> 
> > On the basis, one supposes, that the situation is unclear and you wish
> > the poster to know there is a reply to her post.
> 
> It is futile to send Cc: to people who are known to reply to list messages.
> But thread starters where i am in doubt get a Cc: from me if i have
> something to tell them.

Cheers,
David.

Re: [OT] Dependencies et al

[Étienne Mollier]

(Warning: irrelevancy ahead.)

On 07/10/2019 21.29, Brian wrote:
> I am not overly bothered whether my answers are read. That is up to the
> OP. For all I know, all my mails are deleted on sight by all users on
> this list. :)

Wrong, there is at least one that hasn't.
QED  ;)
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d



signature.asc
Description: OpenPGP digital signature

Re: Dependencies et al

[Brian]

On Mon 07 Oct 2019 at 20:49:08 +0200, Thomas Schmitt wrote:

> Hi,
> 
> Brian wrote:
> > I am still wondering what use it is to "check for the existence of
> > that LDOSUBSCRIBER value of X-Spam-Status e-mail header *before*
> > replying to e-mail". How does it affect the actions one takes?
> 
> As said, i use it as guideline whether to add a Cc: for the thread starter.
> If i write an answer, then i want it to be read.

I am not overly bothered whether my answers are read. That is up to the
OP. For all I know, all my mails are deleted on sight by all users on
this list. :)

> > Or is it just another facet of cargo cult?
> 
> Cargo cult is the advise to burn DVDs with speed 1.

:)

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Michael Stone]

On Mon, Oct 07, 2019 at 10:05:30PM +0300, Reco wrote:

On Mon, Oct 07, 2019 at 02:45:29PM -0400, Michael Stone wrote:

On Mon, Oct 07, 2019 at 09:17:21PM +0300, Reco wrote:
> On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:
> > I don't agree that responding to a troll will lead to a beneficial outcome.
>
> You're entitled to your option, of course.

For context, the most recent message from that account started out with:


And, for the context, I was referring to the child of the original
e-mail, which stated:

This is harassment because you force me to use either
Xarchiver or Ark, you don't give me the choice to use none.
...
All normal package managers would just remove everything
that depends on Xarchiver, not force me to install alternative.


Whenever it's a harassment it's for an appropriate Debian Team to
decide, of course.


No, reasonable people can evaluate it on their own without an appeal to 
authority. Trying to legitimize an inappropriate email is worse for the 
overall well-being of the list than just ignoring it, and hand-wringing 
over whether there was a good point hidden in the garbage simply 
dignifies it more than it deserves.

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 14:45:29 -0400, Michael Stone wrote:

> On Mon, Oct 07, 2019 at 09:17:21PM +0300, Reco wrote:
> > On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:
> > > I don't agree that responding to a troll will lead to a beneficial 
> > > outcome.
> > 
> > You're entitled to your option, of course.
> 
> For context, the most recent message from that account started out with:
> 
> "I posted to publicly state that Debian developers are assholes, but
> now I see that Debian users are assholes too (just like religious cult
> of Theo de Raadt which we know as OpenBSD)."
> 
> I think most people would agree that's a troll account which isn't going to
> lead to any meaningful engagement. It's probably reasonable to assume that
> any issues raised by the troll account were selected to cause conflict, not
> to request assistance for a real problem in need of a solution.

If that had been in a submitted bug report, it would been closed within
seconds.

> > Still, there were some valid points in that e-mail.
> 
> We can certainly agree to disagree.

About the points? Yes. About the tone? No. It is unacceptable on this
list and does not deserve to be championed.

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 02:45:29PM -0400, Michael Stone wrote:
> On Mon, Oct 07, 2019 at 09:17:21PM +0300, Reco wrote:
> > On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:
> > > I don't agree that responding to a troll will lead to a beneficial 
> > > outcome.
> > 
> > You're entitled to your option, of course.
> 
> For context, the most recent message from that account started out with:

And, for the context, I was referring to the child of the original
e-mail, which stated:

This is harassment because you force me to use either
Xarchiver or Ark, you don't give me the choice to use none.
...
All normal package managers would just remove everything
that depends on Xarchiver, not force me to install alternative.


Whenever it's a harassment it's for an appropriate Debian Team to
decide, of course.


> I think most people would agree that's a troll account which isn't
> going to lead to any meaningful engagement.

Totally agreed. Yet even such e-mail can give a start to a meaningful
and civilized discussion, as we're currently seeing in other part of
this thread.


> It's probably reasonable to assume that any issues raised by the troll
> account were selected to cause conflict, not to request assistance for
> a real problem in need of a solution.

Hardly. OP needed to get it out their system, and choose an
inappropriate way of doing so. Ban them, and be done with it.


> > User tries to uninstall a program, for instance - "xarchiver"
> 
> Why? What is the use-case for a naive user to remove that,

I've asked to leave "gnome" metapackage as it is, as you may recall.
It's perfect as it is. GNOME is the default Debian DE, installing
something else takes skill and determination. In the process of gaining
these user tends to lose that naivity (sp?).

Reco

Re: Dependencies et al

[John Hasler]

 Michael Stone writes:
> Are there any real users with valid use cases for which this as an
> issue?

"I told it to remove xyzzy and it removed all of Gnome!" (or some other
metapackage) is a common complaint.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 21:17:21 +0300, Reco wrote:

> On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:
> > On Mon, Oct 07, 2019 at 04:39:56PM +0300, Reco wrote:
> > > No, I got you first time. Rather it's my response deviated elsewhere.
> > > 
> > > I see nothing in those three packages that would qualify as "xyzzy".
> > > Alternatives? No. Mime types registration? No.
> > > About the only common thing about all three packages is that they are
> > > GUI archivers.
> > > I do not question a choice of these three archivers as "lxqt"
> > > dependency. What I do question is the kind of dependency itself.
> > 
> > I don't agree that responding to a troll will lead to a beneficial outcome.
> 
> You're entitled to your option, of course.

It is magnanimous of you to entertain that idea.

> Still, there were some valid points in that e-mail.

The "staff" on this list are entitled to work without fear of having
explicit insults and inappropriate language thrown at them, especially
when they choose to participate. The expectation is to work in a decent,
well-ordered, respectful, unviolent, and helpful environment.

It doesn't matter how valid the points made are. If you are kicking the
target in the teeth at the same time, they are not uppermost in your
mind and deserve to be ignored.

It is not just what you say - it is the way that you say it that matters.
This isn't, or shouldn't be, an anything goes list.

-- 
Brian.

Re: Dependencies et al

[Thomas Schmitt]

Hi,

Brian wrote:
> I am still wondering what use it is to "check for the existence of
> that LDOSUBSCRIBER value of X-Spam-Status e-mail header *before*
> replying to e-mail". How does it affect the actions one takes?

As said, i use it as guideline whether to add a Cc: for the thread starter.
If i write an answer, then i want it to be read.


> Or is it just another facet of cargo cult?

Cargo cult is the advise to burn DVDs with speed 1.


Have a nice day :)

Thomas

Re: Dependencies et al (was: Default Debian install harassed me)

[Michael Stone]

On Mon, Oct 07, 2019 at 09:17:21PM +0300, Reco wrote:

On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:

I don't agree that responding to a troll will lead to a beneficial outcome.


You're entitled to your option, of course.


For context, the most recent message from that account started out with:

"I posted to publicly state that Debian developers are assholes, but
now I see that Debian users are assholes too (just like religious cult
of Theo de Raadt which we know as OpenBSD)."

I think most people would agree that's a troll account which isn't going 
to lead to any meaningful engagement. It's probably reasonable to assume 
that any issues raised by the troll account were selected to cause 
conflict, not to request assistance for a real problem in need of a 
solution.



Still, there were some valid points in that e-mail.


We can certainly agree to disagree.


User tries to uninstall a program, for instance - "xarchiver"


Why? What is the use-case for a naive user to remove that, apart from 
coming up with scenarios to troll debian-user? For an experienced user 
with esoteric requirements the solution is trivial: don't use task 
packages if you want an artisanal hand-crafted install.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 01:54:17PM -0400, Michael Stone wrote:
> On Mon, Oct 07, 2019 at 04:39:56PM +0300, Reco wrote:
> > No, I got you first time. Rather it's my response deviated elsewhere.
> > 
> > I see nothing in those three packages that would qualify as "xyzzy".
> > Alternatives? No. Mime types registration? No.
> > About the only common thing about all three packages is that they are
> > GUI archivers.
> > I do not question a choice of these three archivers as "lxqt"
> > dependency. What I do question is the kind of dependency itself.
> 
> I don't agree that responding to a troll will lead to a beneficial outcome.

You're entitled to your option, of course.
Still, there were some valid points in that e-mail.


> In this case, unless you're specifically trying to remove all of these
> specific dependencies (for no apparent reason) *it simply doesn't
> matter*.

And as I wrote in another part of this thread:

User tries to uninstall a program, for instance - "xarchiver", and user
has "lxqt" metapackage installed. User sees that apt tries to install
another dependency of "lxqt" along with removing the xarchiver.
Or, user has "lxde" metapackage installed. User tries to remove
"xarchiver", which removes "lxde" by dependency, which removes all of
LXDE as a result.


Disregarding "gnome" metapackage, which of the cases seems sane to you?
Or the end user?

Reco

Re: Dependencies et al

[Reco]

Hi.

On Mon, Oct 07, 2019 at 06:34:20PM +0200, Linux-Fan wrote:
> Citing from that:
> | 6.7.10. Best practices for meta-packages
> | A meta-package is a mostly empty package that makes it easy to install a
> | coherent set of packages that can evolve over time. It achieves this by
> | depending on all the packages of the set. Thanks to the power of APT, the
> | meta-package maintainer can adjust the dependencies and the user's system
> | will automatically get the supplementary packages. The dropped packages
> | that were automatically installed will be also be marked as removal
> | candidates (and are even automatically removed by aptitude).
> | gnome and linux-image-amd64 are two examples of meta-packages [...]
> 
> If I understand it correctly, meta-packages use Depends because this allows
> packages like the kernel meta-package to function correctly: Changing a
> Depends to a newer kernel version will cause older kernels to automatically
> be uninstalled.

It could work this way, but currently it does not in this specific case.
See /etc/apt/apt.conf.d/01autoremove* .
Current behaviour is "we do not autoremove the current kernel and the
one that's installed before". Sane enough, if you ask me.


> From my point of view, this clearly explains why the kernel meta-package
> should make use of Depends fields, but for Desktop Environments, the
> advantage of having a Depends is less clear to me:
> 
> On the one hand, it is an advantage that just removing the Desktop
> Environment package will uninstall all related programs because this allows
> trying them out and uninstalling them afterwards without leaving many
> programs installed.

It's an improvement over the current behaviour IMO.

User tries to uninstall a program, for instance - "xarchiver", and user
has "lxqt" metapackage installed. User sees that apt tries to install
another dependency of "lxqt" along with removing the xarchiver.
Or, user has "lxde" metapackage installed. User tries to remove
"xarchiver", which removes "lxde" by dependency, which removes all of
LXDE as a result.

In the former case user has to guess the metapackage which forces such
replacement. In the latter case user is scared of the dependencies
(because they remove half of the "system").


> On the other hand, the case of a user wanting to install
> a desktop environment but "without this and that" is not possible with the
> current design of meta-packages.

Why, it's possible. But user cannot use metapackages in such case, and
picking the needed packages one by one is tedious at best.
Which beats the primary purpose of metapackages.


> I can think of another good reason for having Depends: Ease of support.
...
> Thinking of a case where everything is just Recommends, it would be
> possible that dependency problems (however they occurred in the first place)

A catch here is that Recommends are treated as Depends in a default
Debian installation. A user can disable Recommends installation, but
it's discouraged. See last month discussion on this at this list, for instance.

So, for the default apt settings, there is no visible difference between
Depends metapackage and Recommends metapackage.

The real fun starts then the user discovers that APT::Install-Recommends
setting.

Reco

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 10:56:30 -0500, David Wright wrote:

> On Mon 07 Oct 2019 at 16:03:21 (+0300), Reco wrote:

[...]

> > Please show a e-mail from the list subscriber that does not have
> > aforementioned attribute, then we'll have something to talk about.
> 
> Dead easy. Just configure your email system so that the envelope-from
> does not match your subscribed address. All my list postings lacked
> LDOSUBSCRIBER until April last year for that reason. Judging by one
> of the threads I contributed to at that time, I expect that this is
> when I changed my domain's name from nothing to "corp", and stopped
> exim from nagging me about my FQDN.

That seems good to me (and Reco agrees). Problem: my envelope From
does not match my subscribed address, and is not intended to.

I am still wondering what use it is to "check for the existence of
that LDOSUBSCRIBER value of X-Spam-Status e-mail header *before*
replying to e-mail". How does it affect the actions one takes? Or
is it just another facet of cargo cult?

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Michael Stone]

On Mon, Oct 07, 2019 at 04:39:56PM +0300, Reco wrote:

No, I got you first time. Rather it's my response deviated elsewhere.

I see nothing in those three packages that would qualify as "xyzzy".
Alternatives? No. Mime types registration? No.
About the only common thing about all three packages is that they are
GUI archivers.
I do not question a choice of these three archivers as "lxqt"
dependency. What I do question is the kind of dependency itself.


I don't agree that responding to a troll will lead to a beneficial 
outcome. In this case, unless you're specifically trying to remove all 
of these specific dependencies (for no apparent reason) *it simply 
doesn't matter*. Saying, "there was a troll post which shows that this 
is an issue" just isn't compelling. Are there any real users with valid 
use cases for which this as an issue? If not, why encourage another 
dozen messages about it?

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 15:09:09 +0200, Thomas Schmitt wrote:

[...]

> But how do Debian list servers know ?

A good question. How are my mails matched with my subscribed address
so that I am awarded the accolade of LDOSUBSCRIBER? On the basis that
my past statements about the SMTP protocol (whatever they were) have
not been well received, I decline to offer any suggestion.

> Is it because Exim 4.89 said "MAIL FROM:<...subscribed.address...>" to
> lists.debian.org ?

"subscribed.address" is the HELO and can be what I want it to be. See
the headers of my previous mail.

> Or is it because the first mail hop added "envelope-from" to its Received:
> header ?
> 
>   Received: from ... by ... with local (Exim 4.89)
>   (envelope-from <...>)
>   id 1iHRiB-0006S7-Ks
>   for debian-user@lists.debian.org; Mon, 07 Oct 2019 13:01:59 +0100

I can alter that too, and still be designated LDOSUBSCRIBER.

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 10:56:30AM -0500, David Wright wrote:
> On Mon 07 Oct 2019 at 16:03:21 (+0300), Reco wrote:
> > On Mon, Oct 07, 2019 at 01:32:59PM +0100, Brian wrote:
> > > On Mon 07 Oct 2019 at 14:59:31 +0300, Reco wrote:
> > > > On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> > > > > On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> > > > > > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > > > > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > PS Just a friendly reminder. Please check for the existence of 
> > > > > > > > that
> > > > > > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* 
> > > > > > > > replying to
> > > > > > > > e-mail.  Unless, of course, you intention is *not* to reply to 
> > > > > > > > OP but
> > > > > > > > have your reply visible to the list.
> > > > > > > 
> > > > > > > The non-existence of LDOSUBSCRIBER in a mails's headers says 
> > > > > > > nothing
> > > > > > > definite about whether the poster is subscribed to the list or 
> > > > > > > reads
> > > > > > > list mails.
> > > > > > 
> > > > > > You'll excuse me if I take your suggestion with a grain of salt.
> > > > > > Just on a basis of your past statements about SMTP protocol.
> > > > > 
> > > > > What does the lack of LDOSUBSCRIBER tell us?
> > > > 
> > > > Clearly there are several people that are using a...@cityscape.co.uk 
> > > > e-mail.
> > > > Please share the answer to this question once all of you reach some 
> > > > conclusion.
> > > 
> > > Your theorising is interesting and doesn't really answer the question.
> > 
> > Because if you make a certain statement, the burden of proof lies on you.
> > Now that you have answered own question,
> > 
> > 
> > > That address is not subscribed to the list and plays no part in routeing
> > > mails to or from the list.
> > 
> > Yet e-mails with that address at From: do have X-Spam-Status: 
> > LDOSUBSCRIBER. 
> > Whenever list e-mail is delivered at another e-mail is hardly relevant.
> > 
> > Please show a e-mail from the list subscriber that does not have
> > aforementioned attribute, then we'll have something to talk about.
> 
> Dead easy. Just configure your email system so that the envelope-from
> does not match your subscribed address. All my list postings lacked
> LDOSUBSCRIBER until April last year for that reason. Judging by one
> of the threads I contributed to at that time, I expect that this is
> when I changed my domain's name from nothing to "corp", and stopped
> exim from nagging me about my FQDN.

Ok, that can work, I appreciate the explanation.

Now, the hard part. Show me a way *not* to have LDOSUBSCRIBER, and have
both Return-Path and From to be the same *and* to be subscribed to the
list. Bonus point is awarded for From to be from @gmail.com, another one
if e-mail is sent by Google MTA, with the valid DKIM.

Previous sentences refer to OP's e-mail, just in case.

Reco

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 15:09:09 +0200, Thomas Schmitt wrote:

> Hi,
> 
> i wrote:
> > > To my best knowledge, "X-Spam-Status: ... tests=...,LDOSUBSCRIBER,..."
> > > says that the "From:" address of the mail is subscribed.
> 
> Brian wrote:
> > Are you sure it is the From: and not the envelope From? My From: is
> > not subscribed.
> 
> Interesting observation.
> So the address by which you submit your mail to the remote server is
> subscribed

No. My subscribed address does not appear in the mail headers and is
not used in the transaction between my mail server and bendel.debian.org.

> and it is not the "From:" address which your mail client
> writes into the header part of the mail ?

Correct.

> I wonder whether my mail provider would allow me to send via SMTP
>   MAIL FROM:
>   RCPT TO:debian-user@lists.debian.org
> and then by DATA
>   From: "Somebody Else" 

I do not see why not; it is part of DATA.

[...]

> > > Nevertheless, if i have no other indication then i normally add a "Cc:"
> > > to the thread starter if i do not see LDOSUBSCRIBER among the spam tests.
> 
> > On the basis, one supposes, that the situation is unclear and you wish
> > the poster to know there is a reply to her post.
> 
> It is futile to send Cc: to people who are known to reply to list messages.
> But thread starters where i am in doubt get a Cc: from me if i have
> something to tell them.

You are kinder than I am! I assume no LDOSUBSCRIBER means the user
is reading replies. Unfortunarely, there are some users who never
see any replies because they don't quite appreciate how mailing
lists work and anticipate receiving personal mails.

-- 
Brian.

Re: Dependencies et al

[Linux-Fan]

John Hasler writes:


Reco writes:
> The parent thread shows that at least some of the users are
> confused by metapackages.

I think that most users are totally ignorant of the nature or even the
existence of metapackages.  As far as they are concerned the Lxqt
package *is* Lxqt and there is no way to get Lxqt other than to install
that package.  I don't see any effective way to explain it to them,
either.

It's not clear to me why metapackages don't make more use of Recommends,
though.  I understand that DE users expect a DE to provide an archiver,
but why does Lxqt *require* one?  Isn't installation of Recommends still
turned on by default?  Perhaps there's a need for "Weak-Depends" such
that Weak-Depends will always be installed but can be removed with no
more than a warning?  This would be used whenever the maintainer cannot
imagine why anyone would want to install package A and not package B,
but A doesn't absolutely require B.  All or almost all of the
dependencies in metapackages would then be weak.


I had wondered about the very same thing for multiple times already, but
this clear explanation above (thank you very much, John) has given me a good
opportunity to search the documentation for why meta-packages use Depends
instead of recommends. The best explanation I found so far is this:

https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-meta

Citing from that:
| 6.7.10. Best practices for meta-packages
| A meta-package is a mostly empty package that makes it easy to install a
| coherent set of packages that can evolve over time. It achieves this by
| depending on all the packages of the set. Thanks to the power of APT, the
| meta-package maintainer can adjust the dependencies and the user's system
| will automatically get the supplementary packages. The dropped packages
| that were automatically installed will be also be marked as removal
| candidates (and are even automatically removed by aptitude).
| gnome and linux-image-amd64 are two examples of meta-packages [...]

If I understand it correctly, meta-packages use Depends because this allows
packages like the kernel meta-package to function correctly: Changing a
Depends to a newer kernel version will cause older kernels to automatically
be uninstalled.

From my point of view, this clearly explains why the kernel meta-package
should make use of Depends fields, but for Desktop Environments, the
advantage of having a Depends is less clear to me:

On the one hand, it is an advantage that just removing the Desktop
Environment package will uninstall all related programs because this allows
trying them out and uninstalling them afterwards without leaving many
programs installed. On the other hand, the case of a user wanting to install
a desktop environment but "without this and that" is not possible with the
current design of meta-packages. Also, while I can generally think of cases
where names of packages that constitute a Desktop Environment change, from
a users point of view I would prefer not to propagate that change to
existing users, because they might be used to and happy with the previous
set of programs.

I can think of another good reason for having Depends: Ease of support.
Suppose there is someone asking for a complete Desktop Environment. As of
now, one just installs the meta-package. If it is already installed, one can
be pretty sure that all necessary programs are already on the system (they
might need to be activated by choosing a session in a display manager or
such). Thinking of a case where everything is just Recommends, it would be
possible that dependency problems (however they occurred in the first place)
cause a lot of the Desktop Environment to be missing but the meta-package
would still be installed leaving a "defective" (in terms of expected
programs to be available) installation without clear indication of the
why... I am, however, not sure if this problem is actually specific to
meta-packages but affects the whole system of Recommends?

YMMV
Linux-Fan

Re: Dependencies et al

[John Hasler]

Reco writes:
> The parent thread shows that at least some of the users are
> confused by metapackages.

I think that most users are totally ignorant of the nature or even the
existence of metapackages.  As far as they are concerned the Lxqt
package *is* Lxqt and there is no way to get Lxqt other than to install
that package.  I don't see any effective way to explain it to them,
either.

It's not clear to me why metapackages don't make more use of Recommends,
though.  I understand that DE users expect a DE to provide an archiver,
but why does Lxqt *require* one?  Isn't installation of Recommends still
turned on by default?  Perhaps there's a need for "Weak-Depends" such
that Weak-Depends will always be installed but can be removed with no
more than a warning?  This would be used whenever the maintainer cannot
imagine why anyone would want to install package A and not package B,
but A doesn't absolutely require B.  All or almost all of the
dependencies in metapackages would then be weak.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Dependencies et al (was: Default Debian install harassed me)

[David Wright]

On Mon 07 Oct 2019 at 16:03:21 (+0300), Reco wrote:
> On Mon, Oct 07, 2019 at 01:32:59PM +0100, Brian wrote:
> > On Mon 07 Oct 2019 at 14:59:31 +0300, Reco wrote:
> > > On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> > > > On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> > > > > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > > > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > PS Just a friendly reminder. Please check for the existence of 
> > > > > > > that
> > > > > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* 
> > > > > > > replying to
> > > > > > > e-mail.  Unless, of course, you intention is *not* to reply to OP 
> > > > > > > but
> > > > > > > have your reply visible to the list.
> > > > > > 
> > > > > > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > > > > > definite about whether the poster is subscribed to the list or reads
> > > > > > list mails.
> > > > > 
> > > > > You'll excuse me if I take your suggestion with a grain of salt.
> > > > > Just on a basis of your past statements about SMTP protocol.
> > > > 
> > > > What does the lack of LDOSUBSCRIBER tell us?
> > > 
> > > Clearly there are several people that are using a...@cityscape.co.uk 
> > > e-mail.
> > > Please share the answer to this question once all of you reach some 
> > > conclusion.
> > 
> > Your theorising is interesting and doesn't really answer the question.
> 
> Because if you make a certain statement, the burden of proof lies on you.
> Now that you have answered own question,
> 
> 
> > That address is not subscribed to the list and plays no part in routeing
> > mails to or from the list.
> 
> Yet e-mails with that address at From: do have X-Spam-Status: LDOSUBSCRIBER. 
> Whenever list e-mail is delivered at another e-mail is hardly relevant.
> 
> Please show a e-mail from the list subscriber that does not have
> aforementioned attribute, then we'll have something to talk about.

Dead easy. Just configure your email system so that the envelope-from
does not match your subscribed address. All my list postings lacked
LDOSUBSCRIBER until April last year for that reason. Judging by one
of the threads I contributed to at that time, I expect that this is
when I changed my domain's name from nothing to "corp", and stopped
exim from nagging me about my FQDN.

AIUI .corp became a TLD pariah earlier that year, having been
suggested for use, for example, in RFC 6762. I use it merely because
you seem to get fewest "false hits" when you  #  grep -r corp /etc
as compared with the alternatives, home and mail.

https://www.theregister.co.uk/2018/02/12/icann_corp_home_mail_gtlds/

Cheers,
David.

Re: Dependencies et al (was: Default Debian install harassed me)

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Reco wrote:
> On Mon, Oct 07, 2019 at 01:08:04PM -, Dan Purgert wrote:
>> Reco wrote:
 I don't think anything needs to be done here -- the whole idea of
 (meta)packages is that you give up some choice for the benefits of not
 having to deal with dependency hell.  
>>>
>>> I disagree. The parent thread shows that at least some of the users are
>>> confused by metapackages.
>> 
>> So then the education needs to be fixed, not the material.  I mean, at
>> one point in our lives, we were all confused by what we'd consider
>> "simple mathematics" nowadays.
>
> And we both know it does not work this way, although it should.
> One could write thousand words in the documentation, explaining
> everything in the finest detail possible. But if no one is reading the
> documentation - is there a meaning in all this work?
>
> Hence my suggestion. Users are confused already, and it won't get
> better. I have no problem filling a wishlist bugreport, but I like to
> estimate the possible users' reaction.

The ultimate underlying problem is that in this case, the user didn't
like that the package wanted to force a specific set of programs on the
system.

Now, yes, there are what sound like technical inconsistencies in the
packages (i.e. they're not actually "required" by anything other than
this metapackage itself); although it seems to be that the general user
expectation would be that a DE supplies some form of archive handling
capabilities.

Whether or not that's extraneous to the user's preferred software is
another question entirely -- I mean, I have cthulhu-knows how many
different programs installed simply from core-utils.  I probably touch
but a fraction of them, and yet they're still here.  Not to mention all
the "extras" that come along with say groff, or LaTeX.

>> [...]
>> I think I worded the response here poorly.
>> ...
>> engrampa. Of those, I assume that all three provide the necessary
>> "provides xyzzy" information (e.g. how installing postfix or exim
>> "provides" /usr/sbin/sendmail) to allow generic graphical tools to hook
>> ...
>
> No, I got you first time. Rather it's my response deviated elsewhere.
>
> I see nothing in those three packages that would qualify as "xyzzy".
> Alternatives? No. Mime types registration? No.

Certainly shows my limited understanding of how it all fits together,
that's for sure :).

> About the only common thing about all three packages is that they are
> GUI archivers.
> I do not question a choice of these three archivers as "lxqt"
> dependency. What I do question is the kind of dependency itself.

I might've deleted it in editing somewhere, I was operating under the
assumption that "a gui archiver" is a required component of a "complete
DE" (for some value of "complete", anyway).

>
>
>> In either event, I think one of the mails mentioned wanting to use
>> peaZip, which isn't even available in the repos, so it doesn't matter
>> anyway; as APT would never be able to do dependency resolution.
>
> Why, apt certainly can do it. It's just requires the user to package
> PeaZip first ☺

He's having a hard enough time with packages, that're already available
in the repos.  This is just mean :D

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl2bW1kACgkQjhHd8xJ5
ooHVbQf+NYtIWL4LMpk3GPENOaNmajaI6sVZwZ9x7llydHfxh+cDdPL5myLwBojd
mAAbEBRvvafTE8WxEG7cBeqzQ/mNvW7LSa586kJfChJx32mnnAqU1Dkigal5n/69
JV6yRlV0BR6TrgiEQXsGRIbCkadOnA6GQBa0xSTzCL2DWGgK2Odk7ab4ESWUHZKc
4IqvRChJr9hBhl9R+li+R2PcJI91jgqXXzqMuEeAAE1h0Y+73phHxMqkF4otmfru
kPBTNWYieOEfybuMigXkfIj9j0vb4bJffL6LHrDmi2+14YpmzImTIre3g9C7fjEh
jfKyiOaSh4cVQb27OYd6iorieHZbFQ==
=wH7V
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 16:03:21 +0300, Reco wrote:

> On Mon, Oct 07, 2019 at 01:32:59PM +0100, Brian wrote:
> > On Mon 07 Oct 2019 at 14:59:31 +0300, Reco wrote:
> > 
> > > On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> > > > On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> > > > 
> > > > > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > > > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > PS Just a friendly reminder. Please check for the existence of 
> > > > > > > that
> > > > > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* 
> > > > > > > replying to
> > > > > > > e-mail.  Unless, of course, you intention is *not* to reply to OP 
> > > > > > > but
> > > > > > > have your reply visible to the list.
> > > > > > 
> > > > > > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > > > > > definite about whether the poster is subscribed to the list or reads
> > > > > > list mails.
> > > > > 
> > > > > You'll excuse me if I take your suggestion with a grain of salt.
> > > > > Just on a basis of your past statements about SMTP protocol.
> > > > 
> > > > What does the lack of LDOSUBSCRIBER tell us?
> > > 
> > > Clearly there are several people that are using a...@cityscape.co.uk 
> > > e-mail.
> > > Please share the answer to this question once all of you reach some 
> > > conclusion.
> > 
> > Your theorising is interesting and doesn't really answer the question.
> 
> Because if you make a certain statement, the burden of proof lies on you.
> Now that you have answered own question,

The statement was about the lack of LDOSUBSCRIBER, not its presence.
As Thomas says - a user could be subscribed with another address.

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 01:08:04PM -, Dan Purgert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Reco wrote:
> > Hi.
> >
> > On Mon, Oct 07, 2019 at 11:56:33AM -, Dan Purgert wrote:
> >> > 3) Synaptic did not provide a user a meaningful choice.
> >> > [...]
> >> > I'm not saying that Synaptic should be transformed to aptitude (which is
> >> > famous for its multi-choice resolver), we have one aptitude already,
> >> > please leave it this way. But showing the *reason* of such replacement,
> >> > i.e. "lxqt package demands that you will have some archiver installed"
> >> > would be a definite step in right direction.
> >> 
> >> I don't think anything needs to be done here -- the whole idea of
> >> (meta)packages is that you give up some choice for the benefits of not
> >> having to deal with dependency hell.  
> >
> > I disagree. The parent thread shows that at least some of the users are
> > confused by metapackages.
> 
> So then the education needs to be fixed, not the material.  I mean, at
> one point in our lives, we were all confused by what we'd consider
> "simple mathematics" nowadays.

And we both know it does not work this way, although it should.
One could write thousand words in the documentation, explaining
everything in the finest detail possible. But if no one is reading the
documentation - is there a meaning in all this work?

Hence my suggestion. Users are confused already, and it won't get
better. I have no problem filling a wishlist bugreport, but I like to
estimate the possible users' reaction.


> >> > 4) Metapackages tend to have restrictive dependencies.
> >> >
> > [...]
> >> According to the "similar packages" lists of the three options in the
> >> Bullseye package listings, it looks like there are a handful of other
> >> alternatives that the package maintainer "might" have chosen as
> >> alternates / in addition to the three that he did.  But, then I don't
> >> know enough about those packages (e.g. file-roller, or p7zip) to say
> >> whether they'd actually work -- that is, whether they provide the
> >> ability for the other "default" applications to hook into / be compiled
> >> against.
> >
> > That's somewhat different problem. Certain applications (terminal
> > emulators, browsers to name a few) provide a virtual packages such as
> > x-terminal-emulator or x-www-browser to save the trouble of listing all
> > the possible alternatives in a package dependencies. Reduces the amount
> > of bugs if some package leaves the archive too.
> > But I see no virtual package that means "I'm an archive utility with
> > GUI".
> 
> I think I worded the response here poorly.
> ...
> engrampa. Of those, I assume that all three provide the necessary
> "provides xyzzy" information (e.g. how installing postfix or exim
> "provides" /usr/sbin/sendmail) to allow generic graphical tools to hook
> ...

No, I got you first time. Rather it's my response deviated elsewhere.

I see nothing in those three packages that would qualify as "xyzzy".
Alternatives? No. Mime types registration? No.
About the only common thing about all three packages is that they are
GUI archivers.
I do not question a choice of these three archivers as "lxqt"
dependency. What I do question is the kind of dependency itself.


> In either event, I think one of the mails mentioned wanting to use
> peaZip, which isn't even available in the repos, so it doesn't matter
> anyway; as APT would never be able to do dependency resolution.

Why, apt certainly can do it. It's just requires the user to package
PeaZip first ☺

Reco

Re: Dependencies et al (was: Default Debian install harassed me)

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Reco wrote:
>   Hi.
>
> On Mon, Oct 07, 2019 at 11:56:33AM -, Dan Purgert wrote:
>> > 3) Synaptic did not provide a user a meaningful choice.
>> > [...]
>> > I'm not saying that Synaptic should be transformed to aptitude (which is
>> > famous for its multi-choice resolver), we have one aptitude already,
>> > please leave it this way. But showing the *reason* of such replacement,
>> > i.e. "lxqt package demands that you will have some archiver installed"
>> > would be a definite step in right direction.
>> 
>> I don't think anything needs to be done here -- the whole idea of
>> (meta)packages is that you give up some choice for the benefits of not
>> having to deal with dependency hell.  
>
> I disagree. The parent thread shows that at least some of the users are
> confused by metapackages.

So then the education needs to be fixed, not the material.  I mean, at
one point in our lives, we were all confused by what we'd consider
"simple mathematics" nowadays.

>
>
>> I'm not sure what "lxqt" needs across the board, but I imagine that
>> since it wants one or the other archive program, there are one or more
>> other packages built against them.
>
> Does not seem to be the case. One of "lxqt"'s dependencies, "ark" is a
> KDE archive utility. Or so is says in the description.
> Another one, "enrgampa", comes from MATE.
> "lxqt" is a typical metapackage, listing some totally unrelated programs
> with dependencies that could fit a certain role, and said programs do
> not come with LXQT.

Fair enough.

>
>
>> > 4) Metapackages tend to have restrictive dependencies.
>> >
> [...]
>> According to the "similar packages" lists of the three options in the
>> Bullseye package listings, it looks like there are a handful of other
>> alternatives that the package maintainer "might" have chosen as
>> alternates / in addition to the three that he did.  But, then I don't
>> know enough about those packages (e.g. file-roller, or p7zip) to say
>> whether they'd actually work -- that is, whether they provide the
>> ability for the other "default" applications to hook into / be compiled
>> against.
>
> That's somewhat different problem. Certain applications (terminal
> emulators, browsers to name a few) provide a virtual packages such as
> x-terminal-emulator or x-www-browser to save the trouble of listing all
> the possible alternatives in a package dependencies. Reduces the amount
> of bugs if some package leaves the archive too.
> But I see no virtual package that means "I'm an archive utility with
> GUI".

I think I worded the response here poorly.  

As I understand things - "lxqt" requires one of three options for an "X
based compression tool" (presumably as a requirement of a "complete(tm)
DE" or similar line of thought).  The package maintainer has determined
that there are three that fit the bill -> xarchiver(default), ark, or
engrampa. Of those, I assume that all three provide the necessary
"provides xyzzy" information (e.g. how installing postfix or exim
"provides" /usr/sbin/sendmail) to allow generic graphical tools to hook
against them without needing to have compile-time options set.

Therefore, we end up with a few things we can take away:

  1. Three options is all the package maintainer can keep track of (in
  addition to everything else).
  2. Three options was deemed "enough" by the package maintainer.
  3. The other options (e.g. pz7ip) do not provide the aforementioned 
  "hooks" required by something else.
  4. The other options (e.g. p7zip) are actually part of non-free and 
  I missed that somewhere :)

In either event, I think one of the mails mentioned wanting to use
peaZip, which isn't even available in the repos, so it doesn't matter
anyway; as APT would never be able to do dependency resolution.


-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl2bOLIACgkQjhHd8xJ5
ooHZpQf/TfzcasWcOtdYzOI4j+UQOF9qx5OhHXAu3aGVqq0ToczURaEx0p3XxgIv
OjNGRLj3Sy6Fe/uJGzGcubCuHLAlezT0CpSFUM5HNhHxboiZo+CQfbwF0sBrcgxo
I5CLOg60T9etOg/QstqpwFM3IXEJpQfjlFpT+h/2mF0oS+0cywo4Dj7VlMDNF4VD
nV6WRiIaNFGezMtwQLuGkeERWsZt7AjLrZuK4UFwBe8JQw1aviuD7e20fr6zWND6
ePeN1ea1DEIa1l2ZoWXqJetMkHOtGpjG1bNMgn91BUIfrw3sxZCFe0MoxyKA6V/S
7ZjR/SYTURDHQ4xbb3Y/K+GYWnFRiQ==
=EpKU
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: et.al., (was: Dependencies et al, was: Default Debian install harassed me)

[Thomas Schmitt]

Hi,

i wrote:
> > To my best knowledge, "X-Spam-Status: ... tests=...,LDOSUBSCRIBER,..."
> > says that the "From:" address of the mail is subscribed.

Brian wrote:
> Are you sure it is the From: and not the envelope From? My From: is
> not subscribed.

Interesting observation.
So the address by which you submit your mail to the remote server is
subscribed and it is not the "From:" address which your mail client
writes into the header part of the mail ?

I wonder whether my mail provider would allow me to send via SMTP
  MAIL FROM:
  RCPT TO:debian-user@lists.debian.org
and then by DATA
  From: "Somebody Else" 

But how do Debian list servers know ?
Is it because Exim 4.89 said "MAIL FROM:<...subscribed.address...>" to
lists.debian.org ?
Or is it because the first mail hop added "envelope-from" to its Received:
header ?

  Received: from ... by ... with local (Exim 4.89)
  (envelope-from <...>)
  id 1iHRiB-0006S7-Ks
  for debian-user@lists.debian.org; Mon, 07 Oct 2019 13:01:59 +0100

(I wonder where "envelope-from" in "Received:" is specified. The word
 does neither appear in RFC5322 nor in RFC5321.)


---

> > Nevertheless, if i have no other indication then i normally add a "Cc:"
> > to the thread starter if i do not see LDOSUBSCRIBER among the spam tests.

> On the basis, one supposes, that the situation is unclear and you wish
> the poster to know there is a reply to her post.

It is futile to send Cc: to people who are known to reply to list messages.
But thread starters where i am in doubt get a Cc: from me if i have
something to tell them.


Have a nice day :)

Thomas

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 01:32:59PM +0100, Brian wrote:
> On Mon 07 Oct 2019 at 14:59:31 +0300, Reco wrote:
> 
> > On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> > > On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> > > 
> > > > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > PS Just a friendly reminder. Please check for the existence of that
> > > > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* 
> > > > > > replying to
> > > > > > e-mail.  Unless, of course, you intention is *not* to reply to OP 
> > > > > > but
> > > > > > have your reply visible to the list.
> > > > > 
> > > > > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > > > > definite about whether the poster is subscribed to the list or reads
> > > > > list mails.
> > > > 
> > > > You'll excuse me if I take your suggestion with a grain of salt.
> > > > Just on a basis of your past statements about SMTP protocol.
> > > 
> > > What does the lack of LDOSUBSCRIBER tell us?
> > 
> > Clearly there are several people that are using a...@cityscape.co.uk e-mail.
> > Please share the answer to this question once all of you reach some 
> > conclusion.
> 
> Your theorising is interesting and doesn't really answer the question.

Because if you make a certain statement, the burden of proof lies on you.
Now that you have answered own question,


> That address is not subscribed to the list and plays no part in routeing
> mails to or from the list.

Yet e-mails with that address at From: do have X-Spam-Status: LDOSUBSCRIBER. 
Whenever list e-mail is delivered at another e-mail is hardly relevant.

Please show a e-mail from the list subscriber that does not have
aforementioned attribute, then we'll have something to talk about.

Reco

Re: Dependencies et al (was: Default Debian install harassed me)

[Curt]

On 2019-10-07, Reco  wrote:
>
> 1) Call me old-fashioned, but posters' personalities should not matter
> here, at this list.

I don't see what is old-fashioned about your opinion here. I would think
it were the gentilities of polite discourse that have become outmoded
(as demonstrated finely by the OP), and your view that good breeding is
somehow immaterial the new-fangled thing.

> Whenever a OP is a teen, old person, dog or AI (there are unconfirmed
> sightings of last two posting here ;) is hardly relevant to the problem.
> The language OP is using could definitely use some improvement indeed,
> but discussing OP's personality just because of that is as low as it
> gets.

A person's nature when confronting a problem is entirely relevant to its
solution. A puerile nature blames the stone, and eventually the landscape
architects, when stubbing his toe in the rock garden.

If your objective wisdom is to assert that this specific stone has no
legitimate place in this particular garden and should be removed, well,
that may be true. File the appropriate wish-list bug report with the
architects, who have strived to create an ensemble effect and might not
wish to go without certain elements.

But as the stone in question figures on the map handed out to everyone
before entry, it seems to me it could've been avoided one way or
another by any astute visitor.

-- 
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 14:59:31 +0300, Reco wrote:

> On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> > On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> > 
> > > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > PS Just a friendly reminder. Please check for the existence of that
> > > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* replying 
> > > > > to
> > > > > e-mail.  Unless, of course, you intention is *not* to reply to OP but
> > > > > have your reply visible to the list.
> > > > 
> > > > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > > > definite about whether the poster is subscribed to the list or reads
> > > > list mails.
> > > 
> > > You'll excuse me if I take your suggestion with a grain of salt.
> > > Just on a basis of your past statements about SMTP protocol.
> > 
> > What does the lack of LDOSUBSCRIBER tell us?
> 
> Clearly there are several people that are using a...@cityscape.co.uk e-mail.
> Please share the answer to this question once all of you reach some 
> conclusion.

Your theorising is interesting and doesn't really answer the question.
That address is not subscribed to the list and plays no part in routeing
mails to or from the list.

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

Hi.

On Mon, Oct 07, 2019 at 11:56:33AM -, Dan Purgert wrote:
> > 3) Synaptic did not provide a user a meaningful choice.
> > [...]
> > I'm not saying that Synaptic should be transformed to aptitude (which is
> > famous for its multi-choice resolver), we have one aptitude already,
> > please leave it this way. But showing the *reason* of such replacement,
> > i.e. "lxqt package demands that you will have some archiver installed"
> > would be a definite step in right direction.
> 
> I don't think anything needs to be done here -- the whole idea of
> (meta)packages is that you give up some choice for the benefits of not
> having to deal with dependency hell.  

I disagree. The parent thread shows that at least some of the users are
confused by metapackages.


> I'm not sure what "lxqt" needs across the board, but I imagine that
> since it wants one or the other archive program, there are one or more
> other packages built against them.

Does not seem to be the case. One of "lxqt"'s dependencies, "ark" is a
KDE archive utility. Or so is says in the description.
Another one, "enrgampa", comes from MATE.
"lxqt" is a typical metapackage, listing some totally unrelated programs
with dependencies that could fit a certain role, and said programs do
not come with LXQT.


> > 4) Metapackages tend to have restrictive dependencies.
> >
> > The whole fuss is about the contents of the Depends field of "lxqt".
> > Last, but not least - is there a meaningful reason to use Depends
> > instead of Recommends in metapackages such as "lxqt"? Barring the
> > "gnome" package, I know the answer for it.
> 
> Does it really matter though?
> I mean, there's a basic set of "X-core-utils" that I think can be
> agreed on as required for a full-featured DE.  One of those being
> something that can handle archives.

In the case of the original "problem" - yes it does.
Installing a metapackage with Recommends only would still pull the same
dependencies (by default, that is), but removing one of said
dependencies would not force another one on a user.
Of course it leaves the user without a program to handle archives
(from user's POV), but it may be the desired outcome.

This way flexibility is gained, nothing is lost, user is saved from the
confusion. Am I missing something?


> According to the "similar packages" lists of the three options in the
> Bullseye package listings, it looks like there are a handful of other
> alternatives that the package maintainer "might" have chosen as
> alternates / in addition to the three that he did.  But, then I don't
> know enough about those packages (e.g. file-roller, or p7zip) to say
> whether they'd actually work -- that is, whether they provide the
> ability for the other "default" applications to hook into / be compiled
> against.

That's somewhat different problem. Certain applications (terminal
emulators, browsers to name a few) provide a virtual packages such as
x-terminal-emulator or x-www-browser to save the trouble of listing all
the possible alternatives in a package dependencies. Reduces the amount
of bugs if some package leaves the archive too.
But I see no virtual package that means "I'm an archive utility with
GUI".

Reco

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 13:53:43 +0200, Thomas Schmitt wrote:

> Hi,
> 
> Reco wrote:

[...]
 
> Brian wrote:
> > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > definite about whether the poster is subscribed to the list or reads
> > list mails.
> 
> To my best knowledge, "X-Spam-Status: ... tests=...,LDOSUBSCRIBER,..."
> says that the "From:" address of the mail is subscribed.
> If this sign is missing, the person-like entity which wrote the mail
> could still be subscribed by another address or other means.

Are you sure it is the From: and not the envelope From? My From: is
not subscribed.
 
> Nevertheless, if i have no other indication then i normally add a "Cc:"
> to the thread starter if i do not see LDOSUBSCRIBER among the spam tests.

On the basis, one supposes, that the situation is unclear and you wish
the poster to know there is a reply to her post.

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Reco wrote:
>   Hello, list.
>
> It may seem a thread hijacking (and may be it is), but I feel that the
> discussion of OP's problem has taken a wrong turn. Consider this a my
> attempt to put in on a right track ☺.
>
> So I've been reading this thread, and it got me thinking. I know, it's a
> somewhat strange confession to make (☺), but anyway:
> [...]
> 3) Synaptic did not provide a user a meaningful choice.
> [...]
> I'm not saying that Synaptic should be transformed to aptitude (which is
> famous for its multi-choice resolver), we have one aptitude already,
> please leave it this way. But showing the *reason* of such replacement,
> i.e. "lxqt package demands that you will have some archiver installed"
> would be a definite step in right direction.

I don't think anything needs to be done here -- the whole idea of
(meta)packages is that you give up some choice for the benefits of not
having to deal with dependency hell.  

I'm not sure what "lxqt" needs across the board, but I imagine that
since it wants one or the other archive program, there are one or more
other packages built against them.  The only way out of that then would
be to compile the affected programs from source, so that they can call
his preferred archive solution (assuming said solution can be hooked
into by the affected programs).

>
>
> 4) Metapackages tend to have restrictive dependencies.
>
> The whole fuss is about the contents of the Depends field of "lxqt".
> Last, but not least - is there a meaningful reason to use Depends
> instead of Recommends in metapackages such as "lxqt"? Barring the
> "gnome" package, I know the answer for it.

Does it really matter though?  I mean, there's a basic set of
"X-core-utils" that I think can be agreed on as required for a
full-featured DE.  One of those being something that can handle
archives.

According to the "similar packages" lists of the three options in the
Bullseye package listings, it looks like there are a handful of other
alternatives that the package maintainer "might" have chosen as
alternates / in addition to the three that he did.  But, then I don't
know enough about those packages (e.g. file-roller, or p7zip) to say
whether they'd actually work -- that is, whether they provide the
ability for the other "default" applications to hook into / be compiled
against.



-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl2bJ+8ACgkQjhHd8xJ5
ooEMWAf/foOa4n+9swQggiZCePT8g5htTVxiXeX1wqVoBGEvU19K3py6ZzOB6zvI
bbol5/AHj+Oi3ShALGtDUegY8FvNgOgjR1jnBD7ONHxu19lrjCC2cDIWdAyUltkp
bCQGE4DnXwgu3Mk+SpeM522GtWD/NeX5cJCSTKpdNp4SjuuoJbkA36ntziI/LbSo
Dc3SxgwkuySYTSxNSbW/g4Kx3dcgKfPVZ5Q1oA7weRLzg+s/F75ZoIfXMX7BWAUh
nnQ48yJIi7MnuxUWwaUehiruDgG4kSgk4S7brmPkvqYDq03pmNM0XsuzN+kq4AYg
UM/s8vn2pQA/Jjkf8pLMrtBLgmnuuQ==
=Kw3I
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 12:50:28PM +0100, Brian wrote:
> On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:
> 
> > On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > > 
> > > [...]
> > > 
> > > > PS Just a friendly reminder. Please check for the existence of that
> > > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* replying to
> > > > e-mail.  Unless, of course, you intention is *not* to reply to OP but
> > > > have your reply visible to the list.
> > > 
> > > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > > definite about whether the poster is subscribed to the list or reads
> > > list mails.
> > 
> > You'll excuse me if I take your suggestion with a grain of salt.
> > Just on a basis of your past statements about SMTP protocol.
> 
> What does the lack of LDOSUBSCRIBER tell us?

Clearly there are several people that are using a...@cityscape.co.uk e-mail.
Please share the answer to this question once all of you reach some conclusion.

Reco

Re: Dependencies et al (was: Default Debian install harassed me)

[Thomas Schmitt]

Hi,

Reco wrote:
> > 1) Call me old-fashioned, but posters' personalities should not matter
> > here, at this list. [...]
> > The language OP is using could definitely use some improvement indeed,

It would serve the general issue of constructive discussion.


> > discussing OP's personality just because of that is as low as it gets.

I made up my own theories but refrained from posting them, although i am
now sad about the consequential waste of bad pun and fake commiseration.


> > PS Just a friendly reminder. Please check for the existence of that
> > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* replying to
> > e-mail.

Brian wrote:
> The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> definite about whether the poster is subscribed to the list or reads
> list mails.

To my best knowledge, "X-Spam-Status: ... tests=...,LDOSUBSCRIBER,..."
says that the "From:" address of the mail is subscribed.
If this sign is missing, the person-like entity which wrote the mail
could still be subscribed by another address or other means.

Nevertheless, if i have no other indication then i normally add a "Cc:"
to the thread starter if i do not see LDOSUBSCRIBER among the spam tests.

> > Unless, of course, you intention is *not* to reply to OP but
> > have your reply visible to the list.

... which in this case is indeed my intention because i have nothing
useful to say about the OP's original problem.


Have a nice day :)

Thomas

Re: Dependencies et al (was: Default Debian install harassed me)

[Brian]

On Mon 07 Oct 2019 at 14:11:15 +0300, Reco wrote:

> On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> > On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> > 
> > [...]
> > 
> > > PS Just a friendly reminder. Please check for the existence of that
> > > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* replying to
> > > e-mail.  Unless, of course, you intention is *not* to reply to OP but
> > > have your reply visible to the list.
> > 
> > The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> > definite about whether the poster is subscribed to the list or reads
> > list mails.
> 
> You'll excuse me if I take your suggestion with a grain of salt.
> Just on a basis of your past statements about SMTP protocol.

What does the lack of LDOSUBSCRIBER tell us?

-- 
Brian.

Re: Dependencies et al (was: Default Debian install harassed me)

[Reco]

On Mon, Oct 07, 2019 at 11:39:05AM +0100, Brian wrote:
> On Mon 07 Oct 2019 at 11:28:03 +0300, Reco wrote:
> 
> [...]
> 
> > PS Just a friendly reminder. Please check for the existence of that
> > LDOSUBSCRIBER value of X-Spam-Status e-mail header *before* replying to
> > e-mail.  Unless, of course, you intention is *not* to reply to OP but
> > have your reply visible to the list.
> 
> The non-existence of LDOSUBSCRIBER in a mails's headers says nothing
> definite about whether the poster is subscribed to the list or reads
> list mails.

You'll excuse me if I take your suggestion with a grain of salt.
Just on a basis of your past statements about SMTP protocol.

Reco