apt-get install refuses to installs older versions of dependencies

[Fabian peter Hammerle]

Dear Debian Users,

I set up an APT repository containing 2 packages: foo and bar

The repository contains 2 versions of foo: 1.0.0 and 2.0.0
and 2 versions of bar: 3.0.0 and 4.0.0

foo 1.0.0 depends on bar 3.0.0
foo 2.0.0 depends on bar 4.0.0

I can easily install the latest version of foo via
```
$ sudo apt-get install foo
[...]
The following NEW packages will be installed:
  foo bar
[...]
Setting up bar (4.0.0) ...
Setting up foo (2.0.0) ... ```

I get the same result when running `sudo apt-get install foo=2.0.0`

However, apt-get fails to install foo 1.0.0
```
$ sudo apt-get install foo=1.0.0
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:
 foo : Depends: bar (= 3.0.0) but 4.0.0 is to be installed
E: Unable to correct problems, you have held broken packages. ```

Currently, I workaround this issue by running `sudo apt-get install foo=1.0.0 
bar=3.0.0`.

How can I instruct apt-get to automatically install an older version of bar as 
required by foo?

Or in other words: How can I make `apt-get install foo=1.0.0` install both foo 
1.0.0 and bar 3.0.0 (dependency of foo 1.0.0).

Thanks,
Fabian

 

Re: Document removal of ecryptfs-utils from Buster

[Curt]

On 2019-06-30, Andrea Borgia  wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>> 
>>   Due to #765854 ecryptfs-utils has been removed from Buster.
>>   The kernel module (ecryptfs.ko) is still built but depending on the
>>   upgrade path users will be unable to mount their encrypted home
>>   directories (pam module, ecryptfs-mount-private missing).
>>   So they should probably be strongly advised to not upgrade.
>
> Should I count myself lucky that I have two systems running "testing" 
> with also "stable" sources? Perhaps it's time to mark the package as 
> "hold" :)
>
> I'd be interested to know if there is an alternative: not so much for my 
> desktop but my laptop really needs it. Thanks for the heads up, though.

I haven't yet investigated the alternatives. 

I guess I will be rolling back the encryption and purging the
incriminated software. I have nagging doubts about my encrypted swap and
whether I need to roll that back, too. I guess I will.

Another, less serious, gotcha for those inveterate upgraders and newbies
who don't read the release notes is that
'/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
mechanism for defining device names. This mechanism (automagically)
permitted users upgrading from Wheezy to Stretch (where the old-style
names were deprecated) to continue using their obsolete, legacy
interface names (eth0, anyone?).  

Me, I migrated to the new-fangled denominations as per the instructions
at the link below to obviate the eventual loss of network connectivity,
which is a bummer when you don't what you're doing and all the help
available is at the other end of the severed wire.

https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

The Wanderer and other recalcitrants allergic to progress (just kidding)
can still resort to the 'net.ifname=0 kernel' command line option for
relief.

> Regards,
> Andrea.
>
>

Re: Document removal of ecryptfs-utils from Buster

[Jonathan Dowland]

On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:

At this point, I'd call it a buster delaying bug.  That last is going to
cost too many that can't ignore it and don't have unencrypted backups.
Thats going to be a lot of very bad PR.


It's the release teams call, generally speaking, and one of the things
they might factor in is the size of the user-base for the troublesome
package. I'm surprised to find that it's extremely small according to
popcon data: less than 1% of reporters:
https://qa.debian.org/popcon.php?package=ecryptfs-utils

Compare just two alternatives:

encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Fwd: alternative Firmware for BMC's

[Stefan K]

Hello everybody,

So I don't get any answers from the debian-user-german mailinglist I ask you ;)

short question: when I read [1] (sorry just in german), it says that several 
vendors install their own BMC software up there. So I ask myself which one? 
OpenBMC doesn't really seem to work yet and I can't think of anything else. 
I've already written to the author (several times) but without reaction. :(
Do you have any idea what alternatives there are (ideally which ones work)?

[1] 
https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-rootkit-1901-138956.html

best regards
Stefan

--  Forwarded Message  --

Subject: alternative Firmware für BMC's
Date: Tuesday, June 25, 2019, 3:21:03 PM CEST
From: Stefan K 
To: debian-user-ger...@lists.debian.org

Hallo in die Runde,

kurze Frage: wenn ich [1] lese, steht dort dass diverse Anbieter ihre eigene 
BMC-Software rauf klatschen. Da stellt sich mir die Frage welche denn? OpenBMC 
scheint noch nicht wirklich zu gehen und ansonsten fällt mir da nichts ein. Ich 
hab auch schon den Autor angeschrieben (mehrmals) jedoch ohne Reaktion. :(
Habt ihr denn dazu eine Idee was es da denn an Alternativen gibt (idealerweise 
welche die auch funktionieren)?

[1] 
https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-rootkit-1901-138956.html

MfG
Stefan


-

Re: apt-get install refuses to installs older versions of dependencies

[tomas]

On Mon, Jul 01, 2019 at 07:32:20AM +, Fabian peter Hammerle wrote:
> Dear Debian Users,
> 
> I set up an APT repository containing 2 packages: foo and bar
> 
> The repository contains 2 versions of foo: 1.0.0 and 2.0.0
> and 2 versions of bar: 3.0.0 and 4.0.0

[...]

> I get the same result when running `sudo apt-get install foo=2.0.0`
> 
> However, apt-get fails to install foo 1.0.0
> ```
> $ sudo apt-get install foo=1.0.0
> 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:
>  foo : Depends: bar (= 3.0.0) but 4.0.0 is to be installed
> E: Unable to correct problems, you have held broken packages. ```
> 
> Currently, I workaround this issue by running `sudo apt-get install foo=1.0.0 
> bar=3.0.0`.

That is most probably the only "clean" option there is...

[...]
> Or in other words: How can I make `apt-get install foo=1.0.0` install both 
> foo 1.0.0 and bar 3.0.0 (dependency of foo 1.0.0).

That said, there is an option (heh) to apt-get you might want to
try. From the man page:

  --allow-downgrades
  This is a dangerous option that will cause apt to continue
  without prompting if it is doing downgrades. It should not
  be used except in very special situations.  Using it can
  potentially destroy your system! Configuration Item:
  APT::Get::allow-downgrades. Introduced in APT 1.1.

The problem is that other packages might depend on your bar=4.0.0
package. Downgrading that might either break that other packages
or worse, send your Debian into a downgrade landslide (imagine
for a moment your 'bar' is, e.g. libc6...). This can get particularly
ugly, because downgrade paths aren't as well-tested as upgrade
paths (think config files, data files in new formats not understood
by older versions of your program, yadda, yadda).

So it makes a hell of a lot of sense to not do it by default.

Me, at least, having had my own share of "upgrade landslides" (yeah,
I asked for it: playing with FrankenDebians is the only way to
really learn things, at least for stubborn folks like me ;-)
I do understand the stern warning in the man page above.

Let us know how it went :-D

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: OT:hardware query

[Dan Ritter]

mick crane wrote: 
> On 2019-06-29 17:17, Dan Ritter wrote:
> > Martin Smith wrote:
> > > On 28/06/2019 17:11, mick crane wrote:
> > General advice:
> > 
> > - look for a generic PC, avoiding laptops and anything described
> >   as "mini".
> > 
> > - Don't obsess over CPUs. The last 8 years have only given
> >   incremental improvements.
> > 
> > - Look for PCIe slots on the motherboard instead of PCI.
> > 
> > - Look for 4 DIMM slots for RAM, either DDR3 or DDR4. DDR2 is
> >   too old to find in useful quantity.
> > 
> > - Assume that you're going to replace a spinning disk in the
> >   near future. As long as it has a sufficient number of SATA2 or
> >   SATA3 ports, you'll be fine. 4 is the minimum.
> > 
> > - Assume that you need to replace the graphics card in order to
> >   play games.
> > 
> > -dsr-
> 
> are you saying that there's not much noticeable difference between
> i3,i5,xeon E3,i7
> with the same graphics card ?

I'm saying that, among the range of CPUs you can purchase in
used machines for under 200 quid, there's not much difference.

It is *also* the case that for most games on Steam, the quality
of your graphics card (again in the used, low price range) will
make more difference in game playing than the CPU.

There are certainly combinations that will escape this
generalization.

> Would seem that a processor without integrated graphics might be better ?

It's irrelevant: hardly any Steam games will play acceptably
using integrated graphics. 

-dsr-

Re: Document removal of ecryptfs-utils from Buster

[Gene Heskett]

On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:

> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >At this point, I'd call it a buster delaying bug.  That last is going
> > to cost too many that can't ignore it and don't have unencrypted
> > backups. Thats going to be a lot of very bad PR.
>
> It's the release teams call, generally speaking, and one of the things
> they might factor in is the size of the user-base for the troublesome
> package. I'm surprised to find that it's extremely small according to
> popcon data: less than 1% of reporters:
> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>
> Compare just two alternatives:
>
> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup

That does put a better light on it.  From the comments so far, I was 
thinking I'm one of the few not using it. I've depended on dd-wrt 
between me and the internet for the last 16 years, and even before that 
I was on dialup and the dialup folks didn't have enough bandwidth to 
attract the black hats, so I've never been touched.

With all the publicity this thread has given the issue, I'll change my 
mind (as if it matters to the team :) and say adequate notice and 
mitigating paths seems to have been given. Those that are using it I'd 
call pretty advanced and are reading this list just for the notices 
given so they shouldn't be surprised. So I'll do an Andy Capp and 
shuddup.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

AW: apt-get install refuses to installs older versions of dependencies

[Fabian peter Hammerle]

Hi Tomás,

Thank you very much for suggesting `--allow-downgrades` and your additional 
explanations.

Unfortunately, I get the same error as before:
```
$ sudo apt-get install --allow-downgrades foo=1.0.0
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:
foo : Depends: bar (= 3.0.0) but 4.0.0 is to be installed
E: Unable to correct problems, you have held broken packages.
```

The package `bar` is not pre-installed.

Fabian

Debian Buster RC 2 wont start GUI on a Radeon HD 5750

[aprekates]

I used the installer with the firmware included.

I had to search it for an hour and the package
that was needed is: firmware-linux-nonfree

Alexandros

Re: Re: Please consider unblocking Chromium and linux packages for Buster

[Rodrigo Olmos]

> For security critical packages like web browsers I would always recommend 
> getting a newer version from unstable or from stable-security ASAP.

What would be the best procedure as of today to have v75 instead of
v73 on stretch? I tried pinning v75 from unstable but it suggests huge
changes (91 upgraded, 41 newly installed, 12 to remove) including core
system libraries

Thanks,

Rodrigo

Re: OT:hardware query

[mick crane]

On 2019-07-01 11:05, Dan Ritter wrote:

Would seem that a processor without integrated graphics might be 
better ?


It's irrelevant: hardly any Steam games will play acceptably
using integrated graphics.


what I meant was not much point having integrated graphics as chip 
without integrated graphics probably runs cooler ?

seems under 300 is more the target with a decent graphics card.

--
Key ID4BFEBB31

Re: Debian Buster RC 2 wont start GUI on a Radeon HD 5750

[basti]

Hello,
you need:

firmware-amd-graphics *and*
firmware-linux-nonfree

I had a similar Problem last week.

Best Regards,

On 01.07.19 12:19, aprekates wrote:
> I used the installer with the firmware included.
> 
> I had to search it for an hour and the package
> that was needed is: firmware-linux-nonfree
> 
> Alexandros
> 

Update Two Problems

[Stephen P. Molnar]

I found it necessary to reinstall Debian Stretch on my primary computer 
and encountered two problems.


The first problem was that the installer failed to verify updates at the 
uchicago mirror and commented out the applicable lines in the fstab.  I 
can live with that as I use the v-9-9-0 is fr the installation and the 
issuance of Buster is imminent.


More serious. however is the other error:

[Connecting to prod.debian.map.fastly.net (2a04:4e42:3e::204)]

I have goggled this and found some (very few, at least that I found) 
that address this problem and seem to give a solution for it.


Help will be much appreciated.

Thanks in advance.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
Foundation for ChemistryMultivariate and stochastic
http://www.Molecular-Modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: Update Two Problems

[Sven Hartge]

Stephen P. Molnar  wrote:

> More serious. however is the other error:

> [Connecting to prod.debian.map.fastly.net (2a04:4e42:3e::204)]

Your system thinks to have IPv6 connectivity while it has not.

Find out why this is the case and you solve this problem.

A different (unelegant) workaround would be to edit /etc/gai.conf and
activate the line that reads "precedence :::0:0/96  100" (line 54
in my file here).

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Replacing nvidia card, with Amd - can no longer boot.

[Sarunas Burdulis]

On 6/30/19 2:09 PM, Esteban L wrote:
> ...
> What I don't know is how to solve this issue had the nvidia card failed
> :-( i couldn't do much of anything.

Try booting from some live Linux media (CD, USB), with AMD card installed.

chroot to your system and do the same uninstall "trick".

-- 
Sarunas Burdulis
Systems Administrator, Dartmouth Mathematics
math.dartmouth.edu/~sarunas



signature.asc
Description: OpenPGP digital signature

Re: Update Two Problems

[Stephen P. Molnar]

On 07/01/2019 08:31 AM, Sven Hartge wrote:

Stephen P. Molnar  wrote:


More serious. however is the other error:
[Connecting to prod.debian.map.fastly.net (2a04:4e42:3e::204)]

Your system thinks to have IPv6 connectivity while it has not.

Find out why this is the case and you solve this problem.

A different (unelegant) workaround would be to edit /etc/gai.conf and
activate the line that reads "precedence :::0:0/96  100" (line 54
in my file here).

Gre,
Sven.



At this point in the  life cycle of Stretch, elegance is not an issue.

Your solution worked!

Many thanks.

--
Stephen P. Molnar, Ph.D.Life is a fuzzy set
Foundation for ChemistryMultivariate and stochastic
http://www.Molecular-Modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: Document removal of ecryptfs-utils from Buster

[Curt]

On 2019-07-01, Gene Heskett  wrote:
> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
>
>> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
>> >At this point, I'd call it a buster delaying bug.  That last is going
>> > to cost too many that can't ignore it and don't have unencrypted
>> > backups. Thats going to be a lot of very bad PR.
>>
>> It's the release teams call, generally speaking, and one of the things
>> they might factor in is the size of the user-base for the troublesome
>> package. I'm surprised to find that it's extremely small according to
>> popcon data: less than 1% of reporters:
>> https://qa.debian.org/popcon.php?package=ecryptfs-utils
>>
>> Compare just two alternatives:
>>
>> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
>> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
>
> That does put a better light on it.  From the comments so far, I was 

The light's not switching on for me, Gene. I'm trying to figure out
Popularity Contest and what all those statistics mean.

Let's compare encfs and ecryptfs-utils with a bit more granularity.

NAMENUMBER   %  RANK   NUMBER % RANK  ...

ecryptfs-utils  1651   0.85%10510  1066 0.58%   3632  ...
encfs   2231   1.14% 9233   630 0.34%   4574  ...

The second triad of NUMBER % RANK columns corresponds to the number of people
using the package regularly* and by that metric ecryptfs-utils beats encfs by a
relative long shot (1066 to 630, 0.58% to 0.34%). It's true cryptsetup appears
to be the clear winner of the three, though it's not entirely comparable to the
other two use-case/implementation-wise (block device level encryption as
compared to file system level encryption).

Maybe I'm getting this all wrong.

*whatever that may denote in this case, exactly

> thinking I'm one of the few not using it. I've depended on dd-wrt 
> between me and the internet for the last 16 years, and even before that 
> I was on dialup and the dialup folks didn't have enough bandwidth to 
> attract the black hats, so I've never been touched.

Re: apt-get install refuses to installs older versions of dependencies

[David Wright]

On Mon 01 Jul 2019 at 07:32:20 (+), Fabian peter Hammerle wrote:
> I set up an APT repository containing 2 packages: foo and bar
> 
> The repository contains 2 versions of foo: 1.0.0 and 2.0.0
> and 2 versions of bar: 3.0.0 and 4.0.0
> 
> foo 1.0.0 depends on bar 3.0.0
> foo 2.0.0 depends on bar 4.0.0
> 
> I can easily install the latest version of foo via
> ```
> $ sudo apt-get install foo
> [...]
> The following NEW packages will be installed:
>   foo bar
> [...]
> Setting up bar (4.0.0) ...
> Setting up foo (2.0.0) ... ```
> 
> I get the same result when running `sudo apt-get install foo=2.0.0`
> 
> However, apt-get fails to install foo 1.0.0
> ```
> $ sudo apt-get install foo=1.0.0
> 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:
>  foo : Depends: bar (= 3.0.0) but 4.0.0 is to be installed
> E: Unable to correct problems, you have held broken packages. ```
> 
> Currently, I workaround this issue by running `sudo apt-get install foo=1.0.0 
> bar=3.0.0`.
> 
> How can I instruct apt-get to automatically install an older version of bar 
> as required by foo?

Presumably by employing the same method that linux-image uses:
by moving/copying the version number into the packages' names,
foo-1 and foo-2.

> Or in other words: How can I make `apt-get install foo=1.0.0` install both 
> foo 1.0.0 and bar 3.0.0 (dependency of foo 1.0.0).

Cheers,
David.

Re: Document removal of ecryptfs-utils from Buster

[David Wright]

On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > >At this point, I'd call it a buster delaying bug.  That last is going
> > > to cost too many that can't ignore it and don't have unencrypted
> > > backups. Thats going to be a lot of very bad PR.
> >
> > It's the release teams call, generally speaking, and one of the things
> > they might factor in is the size of the user-base for the troublesome
> > package. I'm surprised to find that it's extremely small according to
> > popcon data: less than 1% of reporters:
> > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> >
> > Compare just two alternatives:
> >
> > encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> > cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
> 
> That does put a better light on it.  From the comments so far, I was 
> thinking I'm one of the few not using it. I've depended on dd-wrt 
> between me and the internet for the last 16 years, and even before that 
> I was on dialup and the dialup folks didn't have enough bandwidth to 
> attract the black hats, so I've never been touched.

I was under the impression that these two forms of security, firewalls
and encryption, are completely orthogonal. Once you've unlocked, say,
an encrypted partition, you're now reliant on the firewall to keep
strangers out of your files. OTOH a perfect firewall is of no benefit
when your laptop is stolen.

> With all the publicity this thread has given the issue, I'll change my 
> mind (as if it matters to the team :) and say adequate notice and 
> mitigating paths seems to have been given. Those that are using it I'd 
> call pretty advanced and are reading this list just for the notices 
> given so they shouldn't be surprised. So I'll do an Andy Capp and 
> shuddup.

The grey area is for me is the relative benefit of encrypting file by
file compared with the whole partition. Assuming that there's just one
passphrase involved in each scenario, is more protection given by the
former method? After all, once a partition is unlocked, all users on
the system are able to read all the files, subject to the normal unix
permissions, ACLs, etc.

Cheers,
David.

Re: Document removal of ecryptfs-utils from Buster

[Jonathan Dowland]

On Mon, Jul 01, 2019 at 08:33:35AM -0500, David Wright wrote:

The grey area is for me is the relative benefit of encrypting file by
file compared with the whole partition. Assuming that there's just one
passphrase involved in each scenario, is more protection given by the
former method? After all, once a partition is unlocked, all users on
the system are able to read all the files, subject to the normal unix
permissions, ACLs, etc.


One fairly attractive feature of the file (or filesystem) level encryption is
it can be layered on top of an existing partition/install relatively easily, no
need to resort to repartitioning. I think this was one reason that it was a
recommended approach in Ubuntu, at least, integrated to some extent with their
installer (Although I think no longer). It never reached that level of support
in Debian, which offers block-level encryption in the installer instead.

Two drawbacks:

it does not protect you from accidentally writing sensitive information to a
file outside of that area (/tmp, or /var/tmp, or inside an email in exim's
spool directory under /var, or in paged-out virtual memory written to an
unencrypted swap space, or who knows where else).

the implementations are quirky (layered filesystems have always been, and
continue to be, awkward, with some semantic corner-cases still misbehaving
today with overlay2 and container work loads)


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

AW: apt-get install refuses to installs older versions of dependencies

[Fabian peter Hammerle]

Hi David,

> Presumably by employing the same method that linux-image uses:
> by moving/copying the version number into the packages' names,
> foo-1 and foo-2.

Thanks for your suggestion

We are using CI/CD pipelines that deploy multiple versions / debian packages 
per day.

So appending version suffixes to packages names would make our package lists 
hard to read.

```
$ apt search ^foo
foo-1.0.0
foo-1.0.1
foo-1.0.2
foo-1.1.0
...
foo-1.999.0
```

Fabian

Re: Document removal of ecryptfs-utils from Buster

[Jonathan Dowland]

On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:

The second triad of NUMBER % RANK columns corresponds to the number of people
using the package regularly* and by that metric ecryptfs-utils beats encfs by a
relative long shot (1066 to 630, 0.58% to 0.34%).


"relative" to what? That's what the percentage (as oppose to absolute numbers)
gives you, the relative comparison with all packages. The difference in that
frame of reference is virtually noise.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Fwd: alternative Firmware for BMC's

[rhkramer]

I don't know how many people are aware of what the BMC is / does -- after a 
little googling, my tentative understanding is that this is the "extra" 
miroprocessor that is now included in some (Intel and maybe AMD?) CPUs?

What are you trying to do with it?

If you're setting up a computer that happens to have one of those, can you 
just ignore it, or must it do something to allow the main CPU to run?

On Monday, July 01, 2019 04:27:48 AM Stefan K wrote:
> Hello everybody,
> 
> So I don't get any answers from the debian-user-german mailinglist I ask
> you ;)
> 
> short question: when I read [1] (sorry just in german), it says that
> several vendors install their own BMC software up there. So I ask myself
> which one? OpenBMC doesn't really seem to work yet and I can't think of
> anything else. I've already written to the author (several times) but
> without reaction. :( Do you have any idea what alternatives there are
> (ideally which ones work)?
> 
> [1]
> https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-
> rootkit-1901-138956.html
> 
> best regards
> Stefan
> 
> --  Forwarded Message  --
> 
> Subject: alternative Firmware für BMC's
> Date: Tuesday, June 25, 2019, 3:21:03 PM CEST
> From: Stefan K 
> To: debian-user-ger...@lists.debian.org
> 
> Hallo in die Runde,
> 
> kurze Frage: wenn ich [1] lese, steht dort dass diverse Anbieter ihre
> eigene BMC-Software rauf klatschen. Da stellt sich mir die Frage welche
> denn? OpenBMC scheint noch nicht wirklich zu gehen und ansonsten fällt mir
> da nichts ein. Ich hab auch schon den Autor angeschrieben (mehrmals)
> jedoch ohne Reaktion. :( Habt ihr denn dazu eine Idee was es da denn an
> Alternativen gibt (idealerweise welche die auch funktionieren)?
> 
> [1]
> https://www.golem.de/news/pantsdown-fehler-in-server-firmware-ermoeglicht-
> rootkit-1901-138956.html
> 
> MfG
> Stefan
> 
> 
> -

Re: Document removal of ecryptfs-utils from Buster

[Curt]

On 2019-07-01, Jonathan Dowland  wrote:
> On Mon, Jul 01, 2019 at 01:14:07PM -, Curt wrote:
>>The second triad of NUMBER % RANK columns corresponds to the number of people
>>using the package regularly* and by that metric ecryptfs-utils beats encfs by 
>>a
>>relative long shot (1066 to 630, 0.58% to 0.34%).
>
> "relative" to what? That's what the percentage (as oppose to absolute
> numbers)

I understood those statistics to mean that 1066 people use
ecryptfs-utils regularly and 630 use encfs regularly (giving
ecryptfs-utils more regular users than encfs by a relatively large
margin---nearly the double). The 1.14%/>1% metric you mentioned to
illustrate your point seemed to me therefore to be a little misleading.


> gives you, the relative comparison with all packages. The difference in that
> frame of reference is virtually noise.
>


-- 
“Decisions are never really made – at best they manage to emerge, from a chaos
of peeves, whims, hallucinations and all around assholery.” – Thomas Pynchon

Re: Document removal of ecryptfs-utils from Buster

[Greg Wooledge]

On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and newbies
> who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names.

For whatever it's worth, when I upgraded this machine from stretch to
buster a couple months ago, it continued using eth0 as the interface
name without any immediately obvious issues.  I did the conversion to
"predictable interface names" anyway, just in case there might be some
subtle problem that I wasn't yet seeing.

Re: Fwd: alternative Firmware for BMC's

[Reco]

Hi.

On Mon, Jul 01, 2019 at 09:48:50AM -0400, rhkra...@gmail.com wrote:
> I don't know how many people are aware of what the BMC is / does -- after a 
> little googling, my tentative understanding is that this is the "extra" 
> miroprocessor that is now included in some (Intel and maybe AMD?) CPUs?

It's an extra *card* (PCI-X based usually) that provides the means of
server's remote control and monitoring via dedicated NIC. Even in the
case if the server's OS is inoperable. Especially in that case,
actually, and that makes it invaluable.

Intel ME and its' AMD PSP provide similar functions, but they're
CPU-based and do not have a dedicated NIC. Both are typical for desktops
and laptops, and are redundant for servers. Also considered evil because
'they are spying on us via ME/PSP'.

AFAIK you cannot replace Intel ME/AMD PSP with your custom OS without
bricking a motherboard/CPU. You can disable it in some cases (requires
physical reflash of BIOS chip), but that's it.

But apparently you can replace BMC's 'firmware' with your own, something
that OpenBMC tries to achieve. Main problem is - there are many
BMC/ILOM/ILO, and OpenBMC targets a few of them. I'd give my hand for a
sensible replacement of Sun's ILOM 'firmware', but I'm not aware of any.

Reco

Re: Document removal of ecryptfs-utils from Buster

[Curt]

On 2019-07-01, Greg Wooledge  wrote:
> On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
>> Another, less serious, gotcha for those inveterate upgraders and newbies
>> who don't read the release notes is that
>> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
>> mechanism for defining device names.
>
> For whatever it's worth, when I upgraded this machine from stretch to
> buster a couple months ago, it continued using eth0 as the interface
> name without any immediately obvious issues.  I did the conversion to
> "predictable interface names" anyway, just in case there might be some
> subtle problem that I wasn't yet seeing.
>
>

And you had that device name defined (as I did) in
'/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

[OT] USB stick failure is bizarre

[David Wright]

I have an 8GB USB stick that seems to have suffered a "brain
transplant" and I wondered if the symptoms are as bizarre as
they seem. When inserted, udev fills out the usual symlinks
for by-id and by-path, but any attempt to use the stick
results in "No medium found".

The output from /run/udev/data/b8:16 looks really bizarre when
compared with the original data (when it worked).

Now:

$ cat /run/udev/data/b8:16
S:disk/by-path/pci-:00:14.0-usb-0:4:1.0-scsi-0:0:0:0
S:disk/by-id/usb-Silicon_Motion_Inc._USB_MEMORY_BAR-0:0
W:21
I:4318771640
E:ID_VENDOR=Silicon_Motion_Inc.
E:ID_VENDOR_ENC=Silicon\x20Motion\x2cInc.\x20
E:ID_VENDOR_ID=090c
E:ID_MODEL=USB_MEMORY_BAR
E:ID_MODEL_ENC=USB\x20MEMORY\x20BAR\x20\x20
E:ID_MODEL_ID=3000
E:ID_REVISION=1000
E:ID_SERIAL=Silicon_Motion_Inc._USB_MEMORY_BAR-0:0
E:ID_TYPE=disk
E:ID_INSTANCE=0:0
E:ID_BUS=usb
E:ID_USB_INTERFACES=:080650:
E:ID_USB_INTERFACE_NUM=00
E:ID_USB_DRIVER=usb-storage
E:ID_PATH=pci-:00:14.0-usb-0:4:1.0-scsi-0:0:0:0
E:ID_PATH_TAG=pci-_00_14_0-usb-0_4_1_0-scsi-0_0_0_0
G:systemd
$ 

When working, it resembled its colleagues:

N:sdb
S:disk/by-id/usb-SMI_USB_DISK-0:0
S:disk/by-path/pci-:00:1d.7-usb-0:5:1.0-scsi-0:0:0:0
W:51
I:12420828601
E:ID_BUS=usb
E:ID_INSTANCE=0:0
E:ID_MODEL=USB_DISK
E:ID_MODEL_ENC=USB\x20DISK\x20\x20\x20\x20\x20\x20\x20\x20
E:ID_MODEL_ID=1000
E:ID_PART_TABLE_TYPE=dos
E:ID_PATH=pci-:00:1d.7-usb-0:5:1.0-scsi-0:0:0:0
E:ID_PATH_TAG=pci-_00_1d_7-usb-0_5_1_0-scsi-0_0_0_0
E:ID_REVISION=1100
E:ID_SERIAL=SMI_USB_DISK-0:0
E:ID_TYPE=disk
E:ID_USB_DRIVER=usb-storage
E:ID_USB_INTERFACES=:080650:
E:ID_USB_INTERFACE_NUM=00
E:ID_VENDOR=SMI
E:ID_VENDOR_ENC=SMI\x20\x20\x20\x20\x20
E:ID_VENDOR_ID=090c
E:UDISKS_PARTITION_TABLE=1
E:UDISKS_PARTITION_TABLE_COUNT=1
E:UDISKS_PARTITION_TABLE_SCHEME=mbr
E:UDISKS_PRESENTATION_NOPOLICY=0

So the vendor and model information are present but different;
or are these values an artifact? Is this mode of failure
typical or odd?

Cheers,
David.

Re: Re: Please consider unblocking Chromium and linux packages for Buster

[Greg Wooledge]

On Mon, Jul 01, 2019 at 12:13:00PM +0200, Rodrigo Olmos wrote:
> > For security critical packages like web browsers I would always recommend 
> > getting a newer version from unstable or from stable-security ASAP.
> 
> What would be the best procedure as of today to have v75 instead of
> v73 on stretch? I tried pinning v75 from unstable but [...]

Installing binary packages from unstable or testing onto a stable release
is a BAD move.  Never do this.

If you feel that you absolutely positively HAVE to have a higher-numbered
version of a web browser than what is available in Debian, just use
upstream's binaries.  Download an appropriate upstream chromium binary
release tarball and unpack it in /opt/chromium or whatever upstream
suggests, and run it from there.

Re: Document removal of ecryptfs-utils from Buster

[Greg Wooledge]

On Mon, Jul 01, 2019 at 02:15:50PM -, Curt wrote:
> On 2019-07-01, Greg Wooledge  wrote:
> > On Mon, Jul 01, 2019 at 07:47:35AM -, Curt wrote:
> >> Another, less serious, gotcha for those inveterate upgraders and newbies
> >> who don't read the release notes is that
> >> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> >> mechanism for defining device names.
> >
> > For whatever it's worth, when I upgraded this machine from stretch to
> > buster a couple months ago, it continued using eth0 as the interface
> > name without any immediately obvious issues.  I did the conversion to
> > "predictable interface names" anyway, just in case there might be some
> > subtle problem that I wasn't yet seeing.
> >
> >
> 
> And you had that device name defined (as I did) in
> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

Yes.  In fact it's still there, but I commented it out by hand after
the buster upgrade.

wooledg:~$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x15b7 (e1000e)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
KERNEL=="eth*", NAME="eth0"

Re: apt-get install refuses to installs older versions of dependencies

[David Wright]

On Mon 01 Jul 2019 at 13:45:30 (+), Fabian peter Hammerle wrote:
> > Presumably by employing the same method that linux-image uses:
> > by moving/copying the version number into the packages' names,
> > foo-1 and foo-2.
> 
> Thanks for your suggestion
> 
> We are using CI/CD pipelines that deploy multiple versions / debian packages 
> per day.
> 
> So appending version suffixes to packages names would make our package lists 
> hard to read.
> 
> ```
> $ apt search ^foo
> foo-1.0.0
> foo-1.0.1
> foo-1.0.2
> foo-1.1.0
> ...
> foo-1.999.0

If these versions of foo have to be paired up with corresponding
versions of bar, then I think you have to delve into the business
of Breaks:, Conflicts: and Replaces: as well as just Depends:, so
that you get the correct one installed, upgraded, or removed under
the appropriate circumstances.

Cheers,
David.

Re: Fwd: alternative Firmware for BMC's

[Thomas Schmitt]

Hi,

> short question: when I read [1] (sorry just in german), it says that several
> vendors install their own BMC software up there. So I ask myself which one?

I guess you will have to find a place where big iron is more on topic.

For us small iron owners there is still AMT if we want it scary:
  https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/
(Rumor has it that my main board's ethernet ports don't support AMT.
 But i would not bet on that.)


Have a nice day :)

Thomas

Re: OT:hardware query

[Dan Ritter]

mick crane wrote: 
> On 2019-07-01 11:05, Dan Ritter wrote:
> 
> > > Would seem that a processor without integrated graphics might be
> > > better ?
> > 
> > It's irrelevant: hardly any Steam games will play acceptably
> > using integrated graphics.
> 
> what I meant was not much point having integrated graphics as chip without
> integrated graphics probably runs cooler ?

If you aren't using the integrated graphics, it won't contribute
to any significant degree of heating.

-dsr-

Re: Fwd: alternative Firmware for BMC's

[Dan Ritter]

rhkra...@gmail.com wrote: 
> I don't know how many people are aware of what the BMC is / does -- after a 
> little googling, my tentative understanding is that this is the "extra" 
> miroprocessor that is now included in some (Intel and maybe AMD?) CPUs?
> 
> What are you trying to do with it?
> 
> If you're setting up a computer that happens to have one of those, can you 
> just ignore it, or must it do something to allow the main CPU to run?

If you've got a motherboard-integrated BMC, it controls the
power-on and -off functions of the main computer, and has its
own network stack and can function as a console for the main
computer.

If you're lucky, it has a separate NIC port and you can either
isolate that to a private network or keep it unplugged.

If you're unlucky, it implements a local switch to hijack
another motherboard NIC port and you need to take affirmative
control of it, including allocating it an IP address and using
a firewall to prevent access to it.

-dsr-

Re: [OT] USB stick failure is bizarre

[Reco]

Hi.

On Mon, Jul 01, 2019 at 09:36:49AM -0500, David Wright wrote:
> I have an 8GB USB stick that seems to have suffered a "brain
> transplant" and I wondered if the symptoms are as bizarre as
> they seem. When inserted, udev fills out the usual symlinks
> for by-id and by-path, but any attempt to use the stick
> results in "No medium found".
> 
> The output from /run/udev/data/b8:16 looks really bizarre when
> compared with the original data (when it worked).
> 
> Now:
> 
...
> E:ID_MODEL=USB_MEMORY_BAR

Maybe it's [1]?
If it is, you need a proprietary, Windoze only program to do USB stick
controller reflash.

[1] 
https://unix.stackexchange.com/questions/34121/how-to-salvage-an-unreadable-usb-flash-drive

Reco

[fixed] Re: Numeric keypad not working on Gnome lock screen

[Steven Post]

(Please keep me in CC, as I'm not subscribed to the mailing list)

On Tue, 2019-06-25 at 14:56 +0200, Steven Post wrote:
> On Mon, 2019-06-24 at 22:15 +0200, Steven Post wrote:
> > (Please keep me in CC, as I'm not subscribed to the mailing list)
> > 
> > On Sun, 2019-06-23 at 19:16 +0300, andreimpope...@gmail.com wrote:
> > > On Lu, 13 mai 19, 11:29:10, Steven Post wrote:
> > > > 
> > > > Recently the numeric keypad stopped working on the Gnome lock
> > > > screen.
> > > 
> > > More information would be necessary here, e.g. what Debian
> > > version
> > > you 
> > > are running, if you upgraded any packages recently, etc.
> > 
> > I'm running Debian 9 (stable), up-to-date.
> > 
> > > 
> > > > When booting, the numlock is in the 'off' state and I can
> > > > simply
> > > > turn
> > > > it on by pressing the numlock key'. When I lock the screen
> > > > (Super+L),
> > > > the numlock light is still on, but pressing a number activates
> > > > the
> > > > second function (arrow, pg up, etc.), I can get numbers by
> > > > holding the
> > > > 'shift' key, but not by setting the numlock in either ON of
> > > > OFF.
> > > 
> > > Is your keypad working correctly everywhere outside the lock
> > > screen?
> > 
> > Yes, although it is off by default, except after logging into
> > Gnome.
> > The problem only exists with the lock screen, it works normally on
> > the login
> > screen (gdm3).
> 
> Update, I noticed that it shows the same issue when entering a wi-fi
> password, or root password.

The issue disappeared after removing 'zoom' (a meeting application) and
its dependency ibus.

> 
> > 
> > > 
> > > Kind regards,
> > > Andrei
> > 
> > Regards,
> > Steven

signature.asc
Description: This is a digitally signed message part

Re: Document removal of ecryptfs-utils from Buster

[Curt]

On 2019-07-01, Greg Wooledge  wrote:
>> >
>> > For whatever it's worth, when I upgraded this machine from stretch to
>> > buster a couple months ago, it continued using eth0 as the interface
>> > name without any immediately obvious issues.  I did the conversion to
>> > "predictable interface names" anyway, just in case there might be some
>> > subtle problem that I wasn't yet seeing.
>> 
>> And you had that device name defined (as I did) in
>> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?
>
> Yes.  In fact it's still there, but I commented it out by hand after
> the buster upgrade.
>
> wooledg:~$ cat /etc/udev/rules.d/70-persistent-net.rules
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
>
> # PCI device 0x8086:0x15b7 (e1000e)
> # SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> KERNEL=="eth*", NAME="eth0"
>
>

Assuming the name was not also defined elsewhere, I'm at a loss to know
why the release notes for Buster state 

 ...you should be aware that udev in buster no
 longer supports the mechanism of defining their names via
 /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of your
 machine losing networking after the upgrade to buster, it is recommended
 that you migrate in advance to the new naming scheme...

Well, I'm enp6s0 anyway now and somehow feel better about it.

Debian Perl or Brew Perl for production application?

[Didar Hossain]

Hi,

I am developing a perl application to be deployed on a production Debian Stable
VM. So far, my approach has been to use the debian perl packages (perl modules) 
and
stay within those facilities. I am the sole system operator and wannabe
developer, there are no teams of sysadmins or developers.

Do you guys who run production debian stable servers use the debian perl
packages or use something like PerlBrew? I asked this question on #perl IRC and
they answered "PerlBrew/plenv/perl-build" - I want some experienced opinions
from the debian community as well.

Regards,
Didar

-- 
All international orders must be accompanied by payment in U. S. funds.

Re: Debian Perl or Brew Perl for production application?

[tomas]

On Mon, Jul 01, 2019 at 09:52:18PM +0530, Didar Hossain wrote:
> Hi,
> 
> I am developing a perl application to be deployed on a production Debian 
> Stable
> VM. So far, my approach has been to use the debian perl packages (perl 
> modules) and
> stay within those facilities. I am the sole system operator and wannabe
> developer, there are no teams of sysadmins or developers.
> 
> Do you guys who run production debian stable servers use the debian perl
> packages or use something like PerlBrew? I asked this question on #perl IRC 
> and
> they answered "PerlBrew/plenv/perl-build" - I want some experienced opinions
> from the debian community as well.

I tend to stick to Debian packages as my primary choice, resorting
to off-distribution packages when needed (e.g. not packaged for
Debian, or I /need/ a newer version). Of course it takes some foresight
to guess in advance whether you expect such a situation in the
future.

Rationale: they mesh better with the flow of system updates/upgrades.

I've found Perl packaging in Debian outstanding. The Debian Perl
packaging team does a damn good job indeed.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Debian Buster RC 2 wont start GUI on a Radeon HD 5750

[aprekates]

Is that sth that can be corrected , or is
happening due to legal issues ?

But in the installer there is the option to use
non-free packages. So shouldnt that be reported
as an issue?

Alexandros

On 1/7/19 1:41 μ.μ., basti wrote:

Hello,
you need:

firmware-amd-graphics *and*
firmware-linux-nonfree

I had a similar Problem last week.

Best Regards,

On 01.07.19 12:19, aprekates wrote:

I used the installer with the firmware included.

I had to search it for an hour and the package
that was needed is: firmware-linux-nonfree

Alexandros

Re: Debian Perl or Brew Perl for production application?

[Jonas Smedegaard]

Hi Didar,

Quoting Didar Hossain (2019-07-01 18:22:18)
> I am developing a perl application to be deployed on a production 
> Debian Stable VM. So far, my approach has been to use the debian perl 
> packages (perl modules) and stay within those facilities. I am the 
> sole system operator and wannabe developer, there are no teams of 
> sysadmins or developers.
> 
> Do you guys who run production debian stable servers use the debian 
> perl packages or use something like PerlBrew? I asked this question on 
> #perl IRC and they answered "PerlBrew/plenv/perl-build" - I want some 
> experienced opinions from the debian community as well.

I do a bit of perl programming (am JONASS on CPAN) and am a Debian 
developer as well.

I use cpanm occationally on my developer laptop, but on production 
servers I only use Debian packages.  I might "cheat" and install 
backported packages or even unofficial .deb packages, but never 
"side-installed" code on production servers.  Reason is that I want a 
single place to keep track of all code installed on the system: APT.

You might consider ask your question at the debian-perl mailinglist, as 
you are more likely to reach Perl folks there, I guess.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian Perl or Brew Perl for production application?

[Nicholas Geovanis]

I have worked in a couple places that prefer ActiveState perl.
https://www.activestate.com/products/activeperl/

On Mon, Jul 1, 2019, 11:37 AM Jonas Smedegaard  wrote:

> Hi Didar,
>
> Quoting Didar Hossain (2019-07-01 18:22:18)
> > I am developing a perl application to be deployed on a production
> > Debian Stable VM. So far, my approach has been to use the debian perl
> > packages (perl modules) and stay within those facilities. I am the
> > sole system operator and wannabe developer, there are no teams of
> > sysadmins or developers.
> >
> > Do you guys who run production debian stable servers use the debian
> > perl packages or use something like PerlBrew? I asked this question on
> > #perl IRC and they answered "PerlBrew/plenv/perl-build" - I want some
> > experienced opinions from the debian community as well.
>
> I do a bit of perl programming (am JONASS on CPAN) and am a Debian
> developer as well.
>
> I use cpanm occationally on my developer laptop, but on production
> servers I only use Debian packages.  I might "cheat" and install
> backported packages or even unofficial .deb packages, but never
> "side-installed" code on production servers.  Reason is that I want a
> single place to keep track of all code installed on the system: APT.
>
> You might consider ask your question at the debian-perl mailinglist, as
> you are more likely to reach Perl folks there, I guess.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 6/30/19 12:12 PM, Richard Owlett wrote:
> On 06/30/2019 10:44 AM, Linux-Fan wrote:
>> Matthew Crews writes:
>>> Are you asking what virtual machine hosts are available on Debian?
> 
> *explicitly*

So clearly I struck a nerve, and I apologize. The way you asked your
question was somewhat unclear to me at first. It is clear now.

I do not know the entire list of software that is found on the different
DVDs, but you can find out by looking on the official DVD lists. Each
DVD has a corresponding .list.gz you can browse, all the way up to DVD 14.

https://cdimage.debian.org/cdimage/release/current/i386/list-dvd/

At a cursory glance, it does NOT appear that DVD-1 contains any VM Host
software, other than perhaps nspawn (which is part of Systemd).

Hope this helps.

-Matt



signature.asc
Description: OpenPGP digital signature

How Buster release may affect Unstable?

[Default User]

Hi.

Easy question, maybe hard to answer . . .

Is someone has an existing conventional Unstable setup (nothing exotic in
hardware or software), what if any special actions should be taken before,
during, or after the impending release of the new Stable?

(inb4:
1 - RTFM
2 - RTF release notes)

Re: Choice of VMs under i386 Stretch?

[Curt]

On 2019-07-01, Matthew Crews  wrote:
>
> At a cursory glance, it does NOT appear that DVD-1 contains any VM Host
> software, other than perhaps nspawn (which is part of Systemd).

Isn't nspawn a chroot container?

> Hope this helps.
>

Re: How Buster release may affect Unstable?

[Brian]

On Mon 01 Jul 2019 at 13:24:48 -0400, Default User wrote:

> Hi.
> 
> Easy question, maybe hard to answer . . .
> 
> Is someone has an existing conventional Unstable setup (nothing exotic in
> hardware or software), what if any special actions should be taken before,
> during, or after the impending release of the new Stable?
> 
> (inb4:
> 1 - RTFM
> 2 - RTF release notes)

The question doesn't really make sense. The situation is that packages
in buster came from unstable. That is, unstable affects and determines
buster, not the other way round. Any use of unstable obliges a user to
keep on top of changes there.

-- 
Brian.

Re: Re: Please consider unblocking Chromium and linux packages for Buster

[Cindy Sue Causey]

On 7/1/19, Greg Wooledge  wrote:
> On Mon, Jul 01, 2019 at 12:13:00PM +0200, Rodrigo Olmos wrote:
>> > For security critical packages like web browsers I would always
>> > recommend getting a newer version from unstable or from stable-security
>> > ASAP.
>>
>> What would be the best procedure as of today to have v75 instead of
>> v73 on stretch? I tried pinning v75 from unstable but it suggests huge
>> changes (91 upgraded, 41 newly installed, 12 to remove) including core
>> system libraries
>
> Installing binary packages from unstable or testing onto a stable release
> is a BAD move.  Never do this.


I added those last numbers back in to show just how bad an idea it can
be. Every one of those opens the door for all kinds of incompatibility
issues that eventually lead to a potentially permanent crash-and-burn.

For newbies peeking in, every single one of those 91 incoming
*upgraded* packages is OVERWRITING... OBLITERATING.. the otherwise
stable packages that Developers manually tweaked especially for one's
currently installed Debian release. That's why there's always someone
to say, *NO, DON'T DO IT THAT WAY!* Some number of us have been
there, done that and thus know firsthand just how painfully bad an
idea it is to do.


> If you feel that you absolutely positively HAVE to have a higher-numbered
> version of a web browser than what is available in Debian, just use
> upstream's binaries.  Download an appropriate upstream chromium binary
> release tarball and unpack it in /opt/chromium or whatever upstream
> suggests, and run it from there.


That's what I was thinking earlier when I saw the first post. I step
out on that limb enough here that I held back this time.

It's just... safer than those 91 packages about to get overwritten.
Your system becomes "not so Debian pure"... but sometimes you have to
make that executive decision based on personal computing needs at any
given second in time. For me as a semi-reclusive type, pulling in
those outside browser packages is most often about the ability versus
inability to simply pay bills online to help keep #Life moving
forward.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Choice of VMs under i386 Stretch?

[Linux-Fan]

Richard Owlett writes:

[...]


On 06/30/2019 10:44 AM, Linux-Fan wrote:

Matthew Crews writes:


On 6/30/19 5:34 AM, Richard Owlett wrote:
> I'm considering using a VM for some experiments.
> Although my web searches have turned up articles about particular
> aspects of particular VMs, I've found no inventory of what VMs are
> available in Debian.
>
> My firm requirement is that all required software be in set of install
> DVDs for i386 Debian 9.8.
>
> What are my options?

Are you asking what virtual machine hosts are available on Debian?


*explicitly*


Good :)

[...]


Did I *NOT* say:

...all required software be in set of install DVDs for i386 Debian 9.8.


I know you wrote that and I attempted to respond to that by the following by
giving a shortcut to a very likely working solution ( :) ):


> If the DVDs contain all of the

`main`
repository, then these packages can be used to start with a
Libvirt/Virt-Manager/KVM setup (this is what I install on my systems):

virt-manager qemu qemu-kvm libvirt-clients libvirt0 libvirt-daemon 
libvirt-daemon-system

The frontend `virt-manager` can then be run to graphically manage VMs.
`virsh` can be used to manage them at the commandline.


I do not understand.


It was an attempt to give you a list of packages that may allow you to start
using VMs without further checks because they are likely to be on the DVDs
(I am still confident that they are and I still have not and will not check
it). If you are interested in finding out that/if all packages are on the
DVDs, use the search engine:

https://cdimage-search.debian.org/

By this I found out that `virt-manager` is on DVD2. So part of my assumption
is right... it's probably easiest if you just try to install the packages?

If it is something else that is not understood in the paragraph I can try to
write it differently if wanted?


Btw. when reading what "VMs are available in Debian" I first thought the
question was about prebuilt images for virtual machines? ...


My *explicit* question is:
What 32 bit VMs which DO NOT depend on non-FOSS components are available for
32-bit Debian?


Not so explicit for me as non-native English speaker due to ambigous use of
word `VM`. `VM` is virtual machine but there are multiple things to
associate with it in this context:

* A `VM` as I commonly understand it on my local system is a hard disk
  image and some metadata allowing it to be run by means of a hypervisor.
  Prebuilt images can be downloaded separately and are not in Debian DVDs.
  This is not an issue for you since you have the DVDs and can ``create''
  your own VMs by using the installer inside an ``empty/new'' VM which most
  management softwares can create easily.

* As an alternative notion, a `VM` is just another server that happens to
  run on a hypervisor and I as the user do not care about what image it
  comes from...

* From the line with `*explicitly*` above I gather that you are asking
  for a software to manage VMs. It is rarely called a `VM` here although
  the linux kernel's hypervisor is called `KVM` for Kernel Virtual Machine.
  All the necessary software is probably available on Debian DVDs.
  If unsure, consult above mentioned URL and list of packages...

* (Other uses of the word may exist...)

HTH
Linux-Fan


pgpGUXOxBXuUl.pgp
Description: PGP signature

Re: Choice of VMs under i386 Stretch?

[Matthew Crews]

On 7/1/19 10:35 AM, Curt wrote:
> On 2019-07-01, Matthew Crews  wrote:
>>
>> At a cursory glance, it does NOT appear that DVD-1 contains any VM Host
>> software, other than perhaps nspawn (which is part of Systemd).
> 
> Isn't nspawn a chroot container?
> 

Indeed, but depending on the needs, it might work.

Re: How Buster release may affect Unstable?

[Default User]

On Mon, Jul 1, 2019, 13:51 Brian  wrote:

> On Mon 01 Jul 2019 at 13:24:48 -0400, Default User wrote:
>
> > Hi.
> >
> > Easy question, maybe hard to answer . . .
> >
> > Is someone has an existing conventional Unstable setup (nothing exotic in
> > hardware or software), what if any special actions should be taken
> before,
> > during, or after the impending release of the new Stable?
> >
> > (inb4:
> > 1 - RTFM
> > 2 - RTF release notes)
>
> The question doesn't really make sense. The situation is that packages
> in buster came from unstable. That is, unstable affects and determines
> buster, not the other way round. Any use of unstable obliges a user to
> keep on top of changes there.
>
> --
> Brian.
>



Well, a recent thread about encrypted file systems got me to thinking.

What if a new Stable release introduces a major change to the existing
distribution technology or methodology?

For example, a new default filesystem is introduced.  Or something like
systemd infects the distribution or its rate of metastasis accelerates,
etc.  Or an important package management system or communication protocol
is superseded or falls into disuse, or is simply abandoned by its
developers or maintainers.

I was wondering if an existing Unstable setup could diverge so far from
Stable that major surgery would be necessary, or even complete replacement
with Stable, followed by conversion to contemporaneous Unstable.

Update Stretch to Buster sources.list file

[Paul Sutton]

Hi

When updating from Stretch to Buster I know that I need to change
references in the sources.list file

Mine is below

# deb cdrom:[Debian GNU/Linux 9.5.0 _Stretch_ - Official amd64 DVD
Binary-1 20180714-10:25]/ stretch contrib main non-free

# deb cdrom:[Debian GNU/Linux 9.5.0 _Stretch_ - Official amd64 DVD
Binary-1 20180714-10:25]/ stretch contrib main non-free

deb http://mirror.bytemark.co.uk/debian/ stretch main contrib non-free
deb-src http://mirror.bytemark.co.uk/debian/ stretch main contrib non-free

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

# stretch-updates, previously known as 'volatile'
deb http://mirror.bytemark.co.uk/debian/ stretch-updates main contrib
non-free
deb-src http://mirror.bytemark.co.uk/debian/ stretch-updates main
contrib non-free

#add repository for weechat (latest)
deb https://weechat.org/debian/ stretch main

#add repository for 0ad
# deb http://http.debian.net/debian/ stretch-backports main

# add dvd codec playback support libdvdcss
deb http://download.videolan.org/pub/debian/stable/ /
# deb https://cloud.r-project.org/bin/linux/debian/ stretch-cran35/
# deb-src https://cloud.r-project.org/bin/linux/debian/ stretch-cran35/
deb-src http://download.videolan.org/pub/debian/stable/ /

# Backports repository
#available after stretch release
# deb http://deb.debian.org/debian/ stretch-backports non-free contrib main
#available after buster release
# deb http://deb.debian.org/debian/ stretch-backports-sloppy non-free
contrib main


What is the best way to edit the above anything from the 0ad reference
and below, or should I comment these out and once buster is out add in
the correct lines from the various source websites (e.g for 0ad the
website will have the instructions).


The last time I did this I used a fresh install of 9.x and then changed
sources.list to reference buster so the other 3rd party software wasn't
referenced.


Thanks

Paul


-- 
Paul Sutton
http://www.zleap.net
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D

https://fediverse.party/ - zl...@social.isurf.ca
Hi

Re: Document removal of ecryptfs-utils from Buster

[Gene Heskett]

On Monday 01 July 2019 09:14:07 Curt wrote:

> On 2019-07-01, Gene Heskett  wrote:
> > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> >> On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> >> >At this point, I'd call it a buster delaying bug.  That last is
> >> > going to cost too many that can't ignore it and don't have
> >> > unencrypted backups. Thats going to be a lot of very bad PR.
> >>
> >> It's the release teams call, generally speaking, and one of the
> >> things they might factor in is the size of the user-base for the
> >> troublesome package. I'm surprised to find that it's extremely
> >> small according to popcon data: less than 1% of reporters:
> >> https://qa.debian.org/popcon.php?package=ecryptfs-utils
> >>
> >> Compare just two alternatives:
> >>
> >> encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> >> cryptsetup: 15% https://qa.debian.org/popcon.php?package=cryptsetup
> >
> > That does put a better light on it.  From the comments so far, I was
>
> The light's not switching on for me, Gene. I'm trying to figure out
> Popularity Contest and what all those statistics mean.
>
> Let's compare encfs and ecryptfs-utils with a bit more granularity.
>
> NAMENUMBER   %  RANK   NUMBER %
> RANK  ...
> __
>__ ecryptfs-utils  1651   0.85%10510  1066
> 0.58%   3632  ... encfs   2231   1.14% 9233   630 
>0.34%   4574  ...
>
> The second triad of NUMBER % RANK columns corresponds to the number of
> people using the package regularly* and by that metric ecryptfs-utils
> beats encfs by a relative long shot (1066 to 630, 0.58% to 0.34%).
> It's true cryptsetup appears to be the clear winner of the three,
> though it's not entirely comparable to the other two
> use-case/implementation-wise (block device level encryption as
> compared to file system level encryption).
>
I'm not sure I understand all the numbers either. OTOH, paranoia that 
makes a few use it does seem to be related to the hand of a beerholder.

> Maybe I'm getting this all wrong.

Its entirely possible we're both wrong, and that caldrons of hot tar and 
old pillows will materialize in this space. I personally have never felt 
the need to use it, so I haven't. To me, its something else that guy 
Murphy can break, at the most inopportune time of course.  He drinks my 
last beer just often enough to remind me he's about the place. :)

> *whatever that may denote in this case, exactly
>
> > thinking I'm one of the few not using it. I've depended on dd-wrt
> > between me and the internet for the last 16 years, and even before
> > that I was on dialup and the dialup folks didn't have enough
> > bandwidth to attract the black hats, so I've never been touched.


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Document removal of ecryptfs-utils from Buster

[Gene Heskett]

On Monday 01 July 2019 09:33:35 David Wright wrote:

> On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > > >At this point, I'd call it a buster delaying bug.  That last is
> > > > going to cost too many that can't ignore it and don't have
> > > > unencrypted backups. Thats going to be a lot of very bad PR.
> > >
> > > It's the release teams call, generally speaking, and one of the
> > > things they might factor in is the size of the user-base for the
> > > troublesome package. I'm surprised to find that it's extremely
> > > small according to popcon data: less than 1% of reporters:
> > > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> > >
> > > Compare just two alternatives:
> > >
> > > encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> > > cryptsetup: 15%
> > > https://qa.debian.org/popcon.php?package=cryptsetup
> >
> > That does put a better light on it.  From the comments so far, I was
> > thinking I'm one of the few not using it. I've depended on dd-wrt
> > between me and the internet for the last 16 years, and even before
> > that I was on dialup and the dialup folks didn't have enough
> > bandwidth to attract the black hats, so I've never been touched.
>
> I was under the impression that these two forms of security, firewalls
> and encryption, are completely orthogonal. Once you've unlocked, say,
> an encrypted partition, you're now reliant on the firewall to keep
> strangers out of your files. OTOH a perfect firewall is of no benefit
> when your laptop is stolen.
>
> > With all the publicity this thread has given the issue, I'll change
> > my mind (as if it matters to the team :) and say adequate notice and
> > mitigating paths seems to have been given. Those that are using it
> > I'd call pretty advanced and are reading this list just for the
> > notices given so they shouldn't be surprised. So I'll do an Andy
> > Capp and shuddup.
>
> The grey area is for me is the relative benefit of encrypting file by
> file compared with the whole partition. Assuming that there's just one
> passphrase involved in each scenario, is more protection given by the
> former method? After all, once a partition is unlocked, all users on
> the system are able to read all the files, subject to the normal unix
> permissions, ACLs, etc.
>
> Cheers,
> David.

Whole filesystem encryption would be a total non-starter for me.  File by 
file with different passwd's according to whats in the file would make 
far more sense to me. Thats my $0.02.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Re: Please consider unblocking Chromium and linux packages for Buster

[Carl Fink]

On Mon, Jul 01, 2019 at 02:17:45PM -0400, Cindy Sue Causey wrote:

> For newbies peeking in, every single one of those 91 incoming
> *upgraded* packages is OVERWRITING... OBLITERATING.. the otherwise
> stable packages that Developers manually tweaked especially for one's
> currently installed Debian release. That's why there's always someone
> to say, *NO, DON'T DO IT THAT WAY!* Some number of us have been
> there, done that and thus know firsthand just how painfully bad an
> idea it is to do.

This is what VMs are for. Or chroot.
-- 
Carl Fink   nitpick...@nitpicking.com 

Read John Grant's book, Corrupted Science: http://a.co/9UsUoGu 
Dedicated to ... Carl Fink!

Re: Choice of VMs under i386 Stretch?

[Curt]

On 2019-07-01, Matthew Crews  wrote:
> On 7/1/19 10:35 AM, Curt wrote:
>> On 2019-07-01, Matthew Crews  wrote:
>>>
>>> At a cursory glance, it does NOT appear that DVD-1 contains any VM Host
>>> software, other than perhaps nspawn (which is part of Systemd).
>> 
>> Isn't nspawn a chroot container?
>> 
>
> Indeed, but depending on the needs, it might work.
>

Well, now, Mr. Owlett's a real stickler for disallowing any deviation
whatsoever in the answers proposed from the precise terms of the
question as formulated by Mr. Owlett himself, so I fear you are now
venturing upon very, very dangerous ground.

Re: How Buster release may affect Unstable?

[Dan Ritter]

Default User wrote: 
> On Mon, Jul 1, 2019, 13:51 Brian  wrote:
> 
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  Or something like
> systemd infects the distribution or its rate of metastasis accelerates,
> etc.  Or an important package management system or communication protocol
> is superseded or falls into disuse, or is simply abandoned by its
> developers or maintainers.
> 
> I was wondering if an existing Unstable setup could diverge so far from
> Stable that major surgery would be necessary, or even complete replacement
> with Stable, followed by conversion to contemporaneous Unstable.

Debian basically holds to two promises: it will be possible to upgrade
in-place from one stable major version to the next stable major version;
and, inside a stable major version, changes are made for security and
bug fixing but not for the sake of new features.

Let's look at the scenarios you presented, through three fairy-tales
of complete fiction which bear no resemblance to any form of reality
whatsoever:

1. Oracle implodes into a corporate black hole, leaving behind a
bankruptcy administrator who sells the rights to ZFS and all related
technologies and patents to the Free Software Foundation for $20 and
a stick of fruit-flavored gum. Everyone decides that ZFS should be the
new default filesystem.

In this case, the Debian Installer would soon gain support for creating
zpools and zfs, and new installs would use it by default. Existing
installs would not be affected.

2. Lennart Poettering is anointed of heaven and a voice from the
sky booms "All shall use systemd, pulseaudio and avahi!". No
problem, all those packages are in Debian already.

3. Debian maintains the .deb format itself, so it can't be superseded
(though it can be improved, and there's a versioning scheme.) Let's say
that all of the OpenBSD hackers simultaneously upload themselves into
cyberspace and stop supporting OpenSSH. There are other folks who can
do that job, and the license is permissive, so it's legal. I imagine we
probably get three competing SSH implementations, which isn't actually
bad, since they aren't SSH if they can't interoperate.

Now, an individual machine can, certainly, fall into an unstable trap
where something majorish is both installed and can't be upgraded out
of. At that point, I would strongly consider my previous life choices,
and also write down the config, backup the data, and start again with
a new machine.

-dsr-

Re: Document removal of ecryptfs-utils from Buster

[Jonathan Dowland]

On Mon, Jul 01, 2019 at 03:56:14PM -0400, Gene Heskett wrote:

Whole filesystem encryption would be a total non-starter for me.  File by
file with different passwd's according to whats in the file would make
far more sense to me. Thats my $0.02.


In which case none of cryptsetup/luks/dm-crypt, ecryptfs or encfs are of
use to you. GnuPG could do what you describe there, amongst other things.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: How Buster release may affect Unstable?

[Joe]

On Mon, 1 Jul 2019 15:34:55 -0400
Default User  wrote:


> 
> Well, a recent thread about encrypted file systems got me to thinking.
> 
> What if a new Stable release introduces a major change to the existing
> distribution technology or methodology?
> 
> For example, a new default filesystem is introduced.  

That's happened a couple of times in my experience. Nothing changes on
an upgraded system, you are just offered the new one as a default on a
new installation. The old default will not be dropped for at least one
more release cycle, usually much longer with something as fundamental as
a filesystem.

> Or something
> like systemd infects the distribution or its rate of metastasis
> accelerates, etc.  Or an important package management system or
> communication protocol is superseded or falls into disuse, or is
> simply abandoned by its developers or maintainers.

Presumably, apt-get will be dropped one day, but apt is already the
preferred system, with more functionality than apt-get.

> 
> I was wondering if an existing Unstable setup could diverge so far
> from Stable that major surgery would be necessary, or even complete
> replacement with Stable, followed by conversion to contemporaneous
> Unstable.

Debian's main selling point is that a Stable can *always* be upgraded
in place to the next version, so that kind of incompatibility does not
arise. You may need to use a new configuration file for some
applications: keeping the old one often works, but not always. You
can't rely on an upgrade going perfectly on a first try, it's always
worth trying it on a spare machine if at all possible, but there's
always a way of doing it.

Some packages are dropped (i.e. not just a new version introduced) but
the obsolete package will not be removed without explicit permission. It
just wouldn't be available to a new installation.

Certainly, Unstable moves away from a new Stable until it is pretty
much the next Stable, which usually involves major changes. But the
old way of doing things can usually be used for a while. Do expect
rapid and large changes in Unstable and Testing when a new Stable is
born, there's always a backlog of new packages that are *not*
compatible with the former Testing. This also happens when Testing is
frozen.

-- 
Joe

Re: How Buster release may affect Unstable?

[Greg Wooledge]

On Mon, Jul 01, 2019 at 09:25:17PM +0100, Joe wrote:
> Presumably, apt-get will be dropped one day, but apt is already the
> preferred system, with more functionality than apt-get.

For GNU's sake, _dselect_ is still packaged!

I can't imagine apt-get going anywhere, so long as Debian lives.  Not in
my lifetime at least.

Re: Update Stretch to Buster sources.list file

[bw]

In-Reply-To: <7f9ebbad-9966-ab81-ca75-8b6fb5154...@disroot.org>


>What is the best way to edit the above anything from the 0ad reference
>and below, or should I comment these out and once buster is out add in
>the correct lines from the various source websites (e.g for 0ad the
>website will have the instructions).
>
>The last time I did this I used a fresh install of 9.x and then changed
>sources.list to reference buster so the other 3rd party software wasn't
>referenced.
[...]

I don't understand the question?  The "best way to edit" means you have 
some third party stuff and you want to know how to handle it before the 
upgrade?  That is usually in the release notes, probably still being 
written but I have seen a few links to the current ver for buster, have 
you read it?

I don't understand you saying, "...I used a fresh install of 9.x and then 
changed sources.list to reference buster..." because that is a definite 
negative.  There is no reason (at this point) to install stretch and then 
upgrade to buster.  So go back and don't do that.

If you are saying you have been running a mixed (stretch/buster)system and 
want to upgrade that mixed system, then my advice is GOOD LUCK.

All in all, a poor description of the problem, but I'm sure people will 
chime in anyway.

Good Luck,
bw

Re: How Buster release may affect Unstable?

[deloptes]

Joe wrote:

> Presumably, apt-get will be dropped one day, but apt is already the
> preferred system, with more functionality than apt-get.

AFAIK apt is frontend to apt-get, or I am wrong?

Re: How Buster release may affect Unstable?

[Greg Wooledge]

On Mon, Jul 01, 2019 at 11:18:18PM +0200, deloptes wrote:
> Joe wrote:
> 
> > Presumably, apt-get will be dropped one day, but apt is already the
> > preferred system, with more functionality than apt-get.
> 
> AFAIK apt is frontend to apt-get, or I am wrong?

They're both front-ends to the APT libraries that do the actual work.

apt-get is older, and has now been declared to be the stable CLI for
writing scripts.

apt is newer, and has been declared the preferred interactive command,
with evolving features.

Of course, if you don't like some of the evolving features, you can still
use apt-get interactively.

Re: How Buster release may affect Unstable?

[Ansgar]

Default User  writes:
> Or something like
> systemd infects the distribution or its rate of metastasis accelerates,

I think we should make systemd mandatory; it would help make Debian a
more welcoming distribution by making toxic people hopefully finally go
away.

Ansgar

Re: How Buster release may affect Unstable?

[Matthew Crews]

On 7/1/19 10:24 AM, Default User wrote:
> Hi.
> 
> Easy question, maybe hard to answer . . . 
> 
> Is someone has an existing conventional Unstable setup (nothing exotic
> in hardware or software), what if any special actions should be taken
> before, during, or after the impending release of the new Stable?

Be ready for Unstable to become...well, unstable again.

Right now Unstable is mostly frozen due to the imminent release of
Buster. Shortly (immediately?) after Buster is released, Unstable will
be unfrozen, and the good 'ol Debian Sid everyone knows and loves will
be back.

Remember: the purpose of Debian Unstable is to be a development platform
to develop the NEXT Stable. Breakage can, and will, occur on occasion,
and system stability is not guaranteed.



signature.asc
Description: OpenPGP digital signature

Buster RC2 , KDE , icons's untuitive interactions.

[aprekates]

KDE Plasma 5.14.5

I drag and drop a menu entry (e.g: firefox) on
the desktop and i choose a copy to be made.
I notice that the icon will have a (!) on it until
i execute it first. ( why is the '!' needed?)

So :

$ cd Desktop
$ ls
-rw-r--r--  1 chomwitt chomwitt 5,0K Μαΐ   2  2018 org.kde.kcalc.desktop

Desktop->Right click on new KCalc icon->Settings->(General tab)->change 
the text field KCalc to KCalc2 and click Ok.


The icon name on the desktop will remain KCalc.

$ ls -al
-rwxr--r--  1 chomwitt chomwitt 9260 Ιουλ  2 02:13 KCalc2.desktop

Now if again :
Desktop->Right click KCalc icon->Settings->(General tab)-> We see that
the field has the KCalc value.

So from the result is as if that field was used to change the filename 
of the Icon but not either the name of the icon or the name of the 
Settings/General/(appname?) field.


So all that interaction (which was the same in debian 9) seems to me 
without logic. Cant we do sthn to change it please???


Alexandros


ps: /usr/share/applications/org.kde.kcalc.desktop is the system-wide file
and links will point to that. Meaning you wont be able to change icon's 
settings.. (isnt that strange too?)

Re: Document removal of ecryptfs-utils from Buster

[David Wright]

On Mon 01 Jul 2019 at 15:56:14 (-0400), Gene Heskett wrote:
> On Monday 01 July 2019 09:33:35 David Wright wrote:
> > On Mon 01 Jul 2019 at 06:05:52 (-0400), Gene Heskett wrote:
> > > On Monday 01 July 2019 03:52:55 Jonathan Dowland wrote:
> > > > On Sun, Jun 30, 2019 at 12:45:57PM -0400, Gene Heskett wrote:
> > > > >At this point, I'd call it a buster delaying bug.  That last is
> > > > > going to cost too many that can't ignore it and don't have
> > > > > unencrypted backups. Thats going to be a lot of very bad PR.
> > > >
> > > > It's the release teams call, generally speaking, and one of the
> > > > things they might factor in is the size of the user-base for the
> > > > troublesome package. I'm surprised to find that it's extremely
> > > > small according to popcon data: less than 1% of reporters:
> > > > https://qa.debian.org/popcon.php?package=ecryptfs-utils
> > > >
> > > > Compare just two alternatives:
> > > >
> > > > encfs: 1.14% https://qa.debian.org/popcon.php?package=encfs
> > > > cryptsetup: 15%
> > > > https://qa.debian.org/popcon.php?package=cryptsetup
> > >
> > > That does put a better light on it.  From the comments so far, I was
> > > thinking I'm one of the few not using it. I've depended on dd-wrt
> > > between me and the internet for the last 16 years, and even before
> > > that I was on dialup and the dialup folks didn't have enough
> > > bandwidth to attract the black hats, so I've never been touched.
> >
> > I was under the impression that these two forms of security, firewalls
> > and encryption, are completely orthogonal. Once you've unlocked, say,
> > an encrypted partition, you're now reliant on the firewall to keep
> > strangers out of your files. OTOH a perfect firewall is of no benefit
> > when your laptop is stolen.
> >
> > > With all the publicity this thread has given the issue, I'll change
> > > my mind (as if it matters to the team :) and say adequate notice and
> > > mitigating paths seems to have been given. Those that are using it
> > > I'd call pretty advanced and are reading this list just for the
> > > notices given so they shouldn't be surprised. So I'll do an Andy
> > > Capp and shuddup.
> >
> > The grey area is for me is the relative benefit of encrypting file by
> > file compared with the whole partition. Assuming that there's just one
> > passphrase involved in each scenario, is more protection given by the
> > former method? After all, once a partition is unlocked, all users on
> > the system are able to read all the files, subject to the normal unix
> > permissions, ACLs, etc.
> 
> Whole filesystem encryption would be a total non-starter for me.

Fair enough. Could you reveal why, or are your reasons cryptic too?

> File by 
> file with different passwd's according to whats in the file would make 
> far more sense to me. Thats my $0.02.

I can't see how anyone would cope with a scheme like that. How would
you remember all those passwords?

OTOH I can see that each file must have an individual encryption key,
but the encryption scheme looks after generating those. Otherwise
you would have a large sample of encrypted but known-cleartext files
available for cracking attempts. (Remember that the filenames are not
encrypted, and many files on a system will have entirely predictable
contents, eg much of /usr, your Debian package cache, and so on.

Cheers,
David.

Re: [fixed] Re: Numeric keypad not working on Gnome lock screen

[andreimpopescu]

On Lu, 01 iul 19, 17:23:41, Steven Post wrote:
> 
> The issue disappeared after removing 'zoom' (a meeting application) and
> its dependency ibus.

This would be worth a bug report against ibus.

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


signature.asc
Description: PGP signature