Re: Disabling automatic upgrades on Sid by default?

[Paul Wise]

M. Zhou wrote:

> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.

I have been automatically upgrading Debian testing 4 times daily using
the unattended-upgrades package for many years now, and automatically
pulling security upgrades from unstable (#725934). The QA processes
that Debian has for testing migration mean that it has mostly been
fine, apart from disruptive things like the Python transition, the
Firefox XUL to WebExtensions transition, GNOME shell API changes
breaking extensions or package removals due to RC bugs etc.

Fabrice BAUZAC wrote:

> I have read somewhere (where?) an advice for testing/unstable users that
> says to upgrade only when you know you will have some time to deal with
> an issue, should that occur.

I disable upgrades when traveling, this is definitely good advice.

M. Zhou wrote:

> So, do we have a consensus on whether automatic upgrades should be
> enabled by default?

I think Debian stable users should enable automatic upgrades (IIRC
that is the case now). Debian unstable/testing users should probably
only enable safe upgrades that don't remove packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Disabling automatic upgrades on Sid by default?

[Paul Sutton]

On 27/12/2020 08:11, Paul Wise wrote:

M. Zhou wrote:


I don't quite understand the meaning of automatic upgrades on a rolling
system such as Debian/Sid. According to my own experience, such
automatic upgrades could be dangerous.


I have been automatically upgrading Debian testing 4 times daily using
the unattended-upgrades package for many years now, and automatically
pulling security upgrades from unstable (#725934). The QA processes
that Debian has for testing migration mean that it has mostly been
fine, apart from disruptive things like the Python transition, the
Firefox XUL to WebExtensions transition, GNOME shell API changes
breaking extensions or package removals due to RC bugs etc.

Fabrice BAUZAC wrote:


I have read somewhere (where?) an advice for testing/unstable users that
says to upgrade only when you know you will have some time to deal with
an issue, should that occur.


I disable upgrades when traveling, this is definitely good advice.

M. Zhou wrote:


So, do we have a consensus on whether automatic upgrades should be
enabled by default?


I think Debian stable users should enable automatic upgrades (IIRC
that is the case now). Debian unstable/testing users should probably
only enable safe upgrades that don't remove packages.




If I can be asked if I want to take part in the usage monitoring thing 
during the install process,  could enabling auto updates be something I 
can be asked during the install process.


If Debian is about putting this power / choice in the hands of the user 
 by having things enabled by default you are removing that choice.


It also treats users like they are people who have the intelligence to 
do this,  rather than windows which seems more like 'I need to do things 
for you'


Paul

--
Paul Sutton
https://personaljournal.ca/paulsutton/
OpenPGP: 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Mini Debian Gaming Conference - 19-22 November 2020
https://mdco2.mini.debconf.org/



OpenPGP_signature
Description: OpenPGP digital signature

Fwd: Disabling automatic upgrades on Sid by default?

[Paul Sutton]

Sorry, just sending this to the list,  as I sent originally it to 
Leandro directly.



Regards

Paul


 Forwarded Message 
Subject: Re: Disabling automatic upgrades on Sid by default?
Date: Sun, 27 Dec 2020 08:17:18 +
From: Paul Sutton 
To: Leandro Cunha 



On 27/12/2020 06:13, Leandro Cunha wrote:
Em dom., 27 de dez. de 2020 às 03:02, M. Zhou > escreveu:


Hi folks,

I don't quite understand the meaning of automatic upgrades on a rolling
system such as Debian/Sid. According to my own experience, such
automatic upgrades could be dangerous.

Recently package ppp is pending for upgrade but it does not co-exist
with my currently installed network-manager. Today when I was shutting
down my machine, Gnome automatically checked the "install updates ..."
box for me before I realized its existence. As a result, the system
reboots and installed ppp by force, removing network-manager and break
my system for daily use as I need network-manager for wifi-access.

I've been a daily Sid user for at least 4 years. Automatic upgrades are
to blame for nearly all my system troubles. And I feel very
disappointed every time linux behaves like M$ windows.

So, do we have a consensus on whether automatic upgrades should be
enabled by default?



I am not an admin or very experienced user, despite using Linux for 
years, I think it should be up to users to run the actual update, 
however would a 'compromise' be some way of notifying a user that 
updates are available,  Mint for example does this, you just click on 
the shield icon and go to the update tool.


Find a balance to allow more experienced users / admins to have that 
control and new users to help them update when needed.  Make it clear 
why this is a feature to avoid problems.  People coming from the MS 
Windows world where this just 'happens' but will also be aware that just 
starting up / shutting down windows sometimes results in the updates 
delaying the process.




Regards

Paul


Hi,

Although you can disable this, I usually update and do most things via 
the command

terminal.
Using testing I run apt daily. I like to know what is being updated in 
the system.


--
Cheers,
Leandro Cunha
Debian Contributor and developer.


--
Paul Sutton
https://personaljournal.ca/paulsutton/
OpenPGP: 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Mini Debian Gaming Conference - 19-22 November 2020
https://mdco2.mini.debconf.org/





OpenPGP_signature
Description: OpenPGP digital signature

Bug#978420: ITP: confy -- Conference schedule viewer written in Python.

[Evangelos Ribeiro Tzaras]

Package: wnpp
Severity: wishlist
Owner: Evangelos Ribeiro Tzaras 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: confy
  Version : 0.4.1
  Upstream Author : fabrixxm 
* URL : https://confy.kirgroup.net/
* License : GPL3
  Programming Lang: Python
  Description : Conference schedule viewer written in Python.

Navigate conference schedules, mark favourite talks 
and get reminded when talks are coming up.
Works offline after initial data download and is usable
on mobile devices.

Re: Disabling automatic upgrades on Sid by default?

[Devops PK Carlisle LLC]

I would like to be able to selectively exclude-with-a-warning some
packages from automatic update as I choose, and to have the update
process remember those choices from one update instance to the next:

Chrome browser: Version a.b.c will be installed
Firefox: Version d.e.f will be installed
Kernel g.h.i is available (automatic update disabled by user)
Libre Office j.k.l will be installed
...

If I know that, for instance, a kernel update will break a wifi dongle
driver or NVIDIA driver, either I must not use automatic updates at all
and I must remember which packages I don't want to update and manually
exclude those packages every time OR I must have enough time to repair
what will break (and may update less often as a result).

Now I understand the potential for dependency issues if selective
disabling of updates is possible, but that's okay, that's Linux. Provide
a warning about dependencies if that's detected and leave it up to the
user to decide.


On 12/27/20 1:01 AM, M. Zhou wrote:
> Hi folks,
> 
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
> 
> Recently package ppp is pending for upgrade but it does not co-exist
> with my currently installed network-manager. Today when I was shutting
> down my machine, Gnome automatically checked the "install updates ..."
> box for me before I realized its existence. As a result, the system
> reboots and installed ppp by force, removing network-manager and break
> my system for daily use as I need network-manager for wifi-access.
> 
> I've been a daily Sid user for at least 4 years. Automatic upgrades are
> to blame for nearly all my system troubles. And I feel very
> disappointed every time linux behaves like M$ windows.
> 
> So, do we have a consensus on whether automatic upgrades should be
> enabled by default?
> 

Bug#978432: ITP: astroalign -- Astrometric registration of images when no WCS info is available

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-as...@lists.debian.org, 
debian-pyt...@lists.debian.org

* Package name : astroalign
  Version  : 2.3.1
  Upstream Author  : Martin Beroiz 
* URL  : http://astroalign.readthedocs.io/
* License  : Expat
  Programming lang : Python
  Upstream git : https://github.com/quatrope/astroalign
  Pypi URL : https://pypi.python.org/pypi/astroalign
  Description  : Astrometric registration of images

ASTROALIGN is a python module that will try to register (align) two stellar
astronomical images, especially when there is no WCS information available.

It does so by finding similar 3-point asterisms (triangles) in both images
and estimating the affine transformation between them.

This is a popular astropy affiliated package. It will be maintained under the
umbrella of the Debian Astro team. A salsa repo was created at

https://salsa.debian.org/debian-astro-team/astroalign

Best regards

Ole

Re: Disabling automatic upgrades on Sid by default?

[Gürkan Myczko]

Hi

On 27.12.2020 11:42, Devops PK Carlisle LLC wrote:

I would like to be able to selectively exclude-with-a-warning some
packages from automatic update as I choose, and to have the update
process remember those choices from one update instance to the next:


you could use aptitude-robot, which has lists of packages to not
upgrade automatically, but the rest it does.

Consult the manual page for details.

HTH,


Chrome browser: Version a.b.c will be installed
Firefox: Version d.e.f will be installed
Kernel g.h.i is available (automatic update disabled by user)
Libre Office j.k.l will be installed
...

If I know that, for instance, a kernel update will break a wifi dongle
driver or NVIDIA driver, either I must not use automatic updates at all
and I must remember which packages I don't want to update and manually
exclude those packages every time OR I must have enough time to repair
what will break (and may update less often as a result).

Now I understand the potential for dependency issues if selective
disabling of updates is possible, but that's okay, that's Linux. 
Provide

a warning about dependencies if that's detected and leave it up to the
user to decide.


On 12/27/20 1:01 AM, M. Zhou wrote:

Hi folks,

I don't quite understand the meaning of automatic upgrades on a 
rolling

system such as Debian/Sid. According to my own experience, such
automatic upgrades could be dangerous.

Recently package ppp is pending for upgrade but it does not co-exist
with my currently installed network-manager. Today when I was shutting
down my machine, Gnome automatically checked the "install updates ..."
box for me before I realized its existence. As a result, the system
reboots and installed ppp by force, removing network-manager and break
my system for daily use as I need network-manager for wifi-access.

I've been a daily Sid user for at least 4 years. Automatic upgrades 
are

to blame for nearly all my system troubles. And I feel very
disappointed every time linux behaves like M$ windows.

So, do we have a consensus on whether automatic upgrades should be
enabled by default?

Re: Disabling automatic upgrades on Sid by default?

[Simon McVittie]

On Sun, 27 Dec 2020 at 06:01:45 +, M. Zhou wrote:
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.

You're using a suite named "unstable". It does what the name suggests. I
use unstable myself, but I wouldn't recommend it to anyone not prepared
to use an interactive apt resolver like aptitude and check that it's
doing something reasonable before letting it go ahead.

Automatic upgrades make a lot more sense for testing than for unstable,
and if we want security updates to be installed automatically for
non-technical users of stable (which I think we do), we do need to
be able to test the code responsible for that before we let it into a
stable release.

However, because the packages in testing are literally the same as the
packages in unstable, I'm not sure how we would configure one and not
the other to be upgraded automatically - particularly if the upgrade is
done by something distribution-neutral (like GNOME Software or KDE's
equivalent, as opposed to apt and unattended-upgrades) which doesn't
know the finer points of how Debian suites relate to each other.

Ubuntu might have some good ideas here: if I understand correctly,
their inconsistent unstable-equivalent is not generally used (except by
buildds), while their internally-consistent testing-equivalent is updated
from their unstable-equivalent with a 0-day migration delay and *is*
used by early adopters.

In the world of non-Debian distributions that *only* produce a rolling
release, my understanding is that Arch Linux is a bit like Ubuntu in this
respect - new packages go into a suite that is not recommended for use,
get a bit of QA/testing by their developers, and *then* go into the
rolling release that users are advised to actually install.

smcv

Re: Disabling automatic upgrades on Sid by default?

[Adrian Bunk]

On Sun, Dec 27, 2020 at 12:16:22PM +, Simon McVittie wrote:
>...
> Ubuntu might have some good ideas here: if I understand correctly,
> their inconsistent unstable-equivalent is not generally used (except by
> buildds), while their internally-consistent testing-equivalent is updated
> from their unstable-equivalent with a 0-day migration delay and *is*
> used by early adopters.
> 
> In the world of non-Debian distributions that *only* produce a rolling
> release, my understanding is that Arch Linux is a bit like Ubuntu in this
> respect - new packages go into a suite that is not recommended for use,
> get a bit of QA/testing by their developers, and *then* go into the
> rolling release that users are advised to actually install.

I do see value in getting feedback from interactive users in unstable 
before migration to testing, this does prevent some regressions from
entering testing. Personally I would even like to see the default 2 day
migrations we have now reverted to the original 10 day default.

We've had surprisingly few of the "libc6 is broken and the system does 
not boot" or "postinst does 'rm -rf /${doesnotexist}'" kind of bugs in 
recent years, but users of unstable should know what they are doing and 
be prepared for any kind of breakage at any time when they use something
that is aptly named "unstable".

For many users a better solution might be to pin to testing with 
automated upgrades, and only manually "apt-get -t unstable" 
install/upgrade from unstable.

> smcv

cu
Adrian

Re: Disabling automatic upgrades on Sid by default?

[Kyle Robbertze]

Hi,

On 2020/12/27 08:01, M. Zhou wrote:
> Hi folks,
> 
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
> 
> Recently package ppp is pending for upgrade but it does not co-exist
> with my currently installed network-manager. Today when I was shutting
> down my machine, Gnome automatically checked the "install updates ..."
> box for me before I realized its existence. As a result, the system
> reboots and installed ppp by force, removing network-manager and break
> my system for daily use as I need network-manager for wifi-access.
> 
> I've been a daily Sid user for at least 4 years. Automatic upgrades are
> to blame for nearly all my system troubles. And I feel very
> disappointed every time linux behaves like M$ windows.

I run unstable as my daily driver and disable unattended upgrades every
time I install a new unstable box. I like to be able to curate the list
of packages I am upgrading and it allows me to ensure that I do not
upgrade during large transitions, etc before things settle down.

I don't think that running unstable is a good suggestion for all users
looking for a more rolling release, but it works for me.

Cheers

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#978472: ITP: b3sum -- Command line tool for the BLAKE3 hash

[karthek]

Package: wnpp
Severity: wishlist
Owner: karthek 
X-Debbugs-Cc: debian-devel@lists.debian.org, frustra...@karthek.com

* Package name: b3sum
  Version : 0.3.7
  Upstream Author : Jack O'Connor 
* URL : https://github.com/BLAKE3-team/BLAKE3
* License : CC0-1.0 or Apache-2.0
  Programming Lang: rust
  Description : Command line tool for the BLAKE3 hash

BLAKE3 is a cryptographic hash function that is much faster than MD5,
SHA-1, SHA-2, SHA-3, and BLAKE2 and
Secure, unlike MD5 and SHA-1. And secure against length extension.
Note, This package includes binary "b3sum" which is built from official 
multithreaded  implementation of BLAKE3 in rust.

I plan to maintain this package

Re: one more, i am still fed up

[Richard]

I for now do not deny or admit officially. Marc, are you someone with
authority? I will clarify myself later, pretty lease

On wo, 2020-12-23 at 20:08 +0100, Marc Haber wrote:

> On Wed, 23 Dec 2020 19:43:18 +0100, Richard 
> wrote:
> >I want to clarify I feel not up to seriously reading and thinking about
> >a response after a day of work, groceries and soms fastfood. But then I
> >saw master Geert responding in my topic. This I am glad to. I also want
> >to clarify, I amaware of both Humour and high level of intelect. I want
> >to learn from him and will follow that up another time. But I am sorry I
> >again start, I am still >: and feel being a target but that is a
> >outdated computer so there is something wrong with my first post too.
> 
> Still, nobody knows what your actual problem is.
> 
> Are you trolling?
> 

Re: Disabling automatic upgrades on Sid by default?

[Lyndon Brown]

On Sun, 2020-12-27 at 06:01 +, M. Zhou wrote:
> Hi folks,
> 
> I don't quite understand the meaning of automatic upgrades on a
> rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
> 
> Recently package ppp is pending for upgrade but it does not co-exist
> with my currently installed network-manager. Today when I was
> shutting
> down my machine, Gnome automatically checked the "install updates
> ..."
> box for me before I realized its existence. As a result, the system
> reboots and installed ppp by force, removing network-manager and
> break
> my system for daily use as I need network-manager for wifi-access.
> 
> I've been a daily Sid user for at least 4 years. Automatic upgrades
> are
> to blame for nearly all my system troubles. And I feel very
> disappointed every time linux behaves like M$ windows.
> 
> So, do we have a consensus on whether automatic upgrades should be
> enabled by default?
> 

This has not happened simply due to automatic upgrades, it has happened
because your system, automatically or otherwise, performed a dist-
upgrade/full-upgrade rather than a "normal"/"simple"/"basic" upgrade,
and so rather than holding back the ppp upgrade in the face of the
conflict, it proceeded with the conflict-resolution solution of
removing network-manager in order to upgrade ppp. You would not have
encountered the problem with just a "normal" upgrade.

This conflict arose of course due to the new ppp package being marked
as compatible only with a new network-manager version, and it being
published on unstable a day or so before the new and compatible
network-manager package was, which unfortunately is a type of situation
that occurs from time to time on sid, sometimes taking several days to
get sorted out.

Allowing your system to automatically perform a full/dist upgrade on
sid is a very unwise thing to do precisely because problems like this
are to be expected. (Apt/aptitude does not understand that the conflict
is just temporary, requiring a few days of patience waiting for further
updates to become available for other packages, and thus full/dist
upgrading suggests removing stuff to fix conflicts).

I use sid/unstable myself. I have unattended-upgrades installed though
I typically manually install upgrades anyway. When I performed a
"normal" upgrade the other day, the ppp package upgrade was correctly
blocked (held back), and only became unblocked once the compatible
updated network-manager package became available a day or so later.
Having noticed something was blocked though, since occasionally manual
action is required to fix an actual problem, I asked aptitude/apt-get
to try a full-upgrade such that I could see what was held back; this
showed me the conflict, and I wisely chose not to proceed with the
proposed solution of removing network-manager, understanding the
situation for what it was from past experience. I thus did not have the
unfortunate experience of loosing network-manager like you did.

You need to investigate why your system is running a dist/full upgrade
rather than a normal one and configure it not to do so. You will thus
have a better experience.

You might also have a better experience on 'testing' rather than sid,
however the problem with using 'testing' is that security upgrades can
sometimes be significantly delayed, which is why I personally avoid it.
Paul Wise mentioned a solution to this in his response which is
interesting, though I'm not certain I'm confident enough in its
reliability to make use of it myself.

Some people responding to this thread do not seem to understand that
sid/unstable is **not** an actual "rolling" distro. I would love Debian
to properly and officially offer an actual "rolling" distro alongside
the stable one, since many like myself use unstable as though it was
and love/trust Debian too much to move to something else, however
unstable/sid along with testing and experimental are all simply
different "staging" areas for the preparation of the next (major)
stable Debian release. Unstable & testing not being an actual "rolling"
distros means that we cannot expect to have quite the same expectations
as for an actual "rolling" distro.

Re: Disabling automatic upgrades on Sid by default?

[Lyndon Brown]

On Sun, 2020-12-27 at 05:42 -0500, Devops PK Carlisle LLC wrote:
> I would like to be able to selectively exclude-with-a-warning some
> packages from automatic update as I choose, and to have the update
> process remember those choices from one update instance to the next:
> 
> Chrome browser: Version a.b.c will be installed
> Firefox: Version d.e.f will be installed
> Kernel g.h.i is available (automatic update disabled by user)
> Libre Office j.k.l will be installed
> ...
> 
> If I know that, for instance, a kernel update will break a wifi
> dongle
> driver or NVIDIA driver, either I must not use automatic updates at
> all
> and I must remember which packages I don't want to update and
> manually
> exclude those packages every time OR I must have enough time to
> repair
> what will break (and may update less often as a result).
> 
> Now I understand the potential for dependency issues if selective
> disabling of updates is possible, but that's okay, that's Linux.
> Provide
> a warning about dependencies if that's detected and leave it up to
> the
> user to decide.

Such mechanisms for holding back upgrades already exist, just not with
the explicit 'automatic update disabled' text.

Look into `aptitude hold`/`aptitude unhold`, 'apt pinning', the
'blacklist' in unattended-upgrades.

Bug#978480: ITP: golang-github-muesli-termenv -- Advanced ANSI style & color support for your terminal applications

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-devel@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-muesli-termenv
  Version : 0.7.4
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/termenv
* License : Expat
  Programming Lang: Go
  Description : Advanced ANSI style & color support for your terminal 
applications

 Termenv lets you safely use advanced styling options on the terminal.
 It gathers information about the terminal environment in terms of its
 ANSI & color support and offers you convenient methods to colorize
 and style your output, without you having to deal with all kinds of
 weird ANSI escape sequences and color conversions.

 It is a dependency for github-cli.

Re: Disabling automatic upgrades on Sid by default?

[Lyndon Brown]

On Sun, 2020-12-27 at 15:33 +0200, Adrian Bunk wrote:
> On Sun, Dec 27, 2020 at 12:16:22PM +, Simon McVittie wrote:
> > ...
> > Ubuntu might have some good ideas here: if I understand correctly,
> > their inconsistent unstable-equivalent is not generally used
> > (except by
> > buildds), while their internally-consistent testing-equivalent is
> > updated
> > from their unstable-equivalent with a 0-day migration delay and
> > *is*
> > used by early adopters.
> > 
> > In the world of non-Debian distributions that *only* produce a
> > rolling
> > release, my understanding is that Arch Linux is a bit like Ubuntu
> > in this
> > respect - new packages go into a suite that is not recommended for
> > use,
> > get a bit of QA/testing by their developers, and *then* go into the
> > rolling release that users are advised to actually install.
> 
> I do see value in getting feedback from interactive users in unstable
> before migration to testing, this does prevent some regressions from
> entering testing. Personally I would even like to see the default 2
> day
> migrations we have now reverted to the original 10 day default.
> 
> We've had surprisingly few of the "libc6 is broken and the system
> does 
> not boot" or "postinst does 'rm -rf /${doesnotexist}'" kind of bugs
> in 
> recent years, but users of unstable should know what they are doing
> and 
> be prepared for any kind of breakage at any time when they use
> something
> that is aptly named "unstable".
> 
> For many users a better solution might be to pin to testing with 
> automated upgrades, and only manually "apt-get -t unstable" 
> install/upgrade from unstable.

The problem with using testing as a rolling distro is that the package
migration process often causes big delays that can block upgrades that
include security fixes, making use of testing alone thus a big security
risk. It is unfortunate that although sometimes upgrades with security
fixes are rushed into testing quickly to avoid this, I've seen too many
examples before of this not happening for me to be comfortable using
testing. It is for this reason alone that I personally choose to use
unstable, and I'm sure that I'm far from alone.

Using testing and manually pulling in select upgrades from unstable in
such situations addresses that issue in theory, but places a huge
burden on users to determine each day what unstable updates might
include a security update. I'm not sure there's a reliable enough
automated means of accomplishing this. We also have to consider not
only doing this for our own personal machines but also others which we
may manage, like those of family members (should we choose to give them
debian and not want to leave them with the "outdated" packages of
stable).

Given than many like myself use unstable for our personal daily-use
systems as though it were a proper rolling debian distro, it is thus
very problematic for package maintainers to treat unstable as a testing
ground to the extent of expecting that we must be "prepared for any
kind of breakage". I can tolerate minor bugs, but cannot-boot type
issues would be a big problem for me. Thankfully I've rarely
encountered such a big problem in my use of unstable thus far.

What would be best for most people like myself using testing/unstable
as though it were a real rolling distro, who for one reason or another
cannot or do not wish to move to a real "rolling" distro like arch,
would be for debian to actually offer a real rolling channel alongside
the stable one. Surely this would not be burdensome.

As I envision it, we could have "rolling" and maybe "rolling-unstable"
(or "rolling-testing") with continual upgrades typically going directly
into "rolling", or with a 0-day migration from "rolling-unstable", with
the purpose of "rolling-unstable" being (1) for preparing multi-package
upgrades like with ppp and network-manager as which kicked off this
discussion, to avoid the upgrade conflict that caused, and (2) for
testing of anything with greater than normal potential to cause serious
will-not-boot type breakage (which might thus be given an unusual
larger migration delay, or a non-automatic migration). We thus get the
best of both worlds of current testing & unstable without the worst.
When it gets to "freeze time" for prepping a new stable release, a
snapshot of "rolling" could be taken as the new "stable-prep", and
worked on for a couple months or so with selective (direct or from-
rolling) upgrades until ready for release as stable. The big problem
would be how best to migrate those on current testing/unstable
channels.

Bug#978482: ITP: rx-java -- Reactive Extensions for the JVM

[Olek Wojnar]

Package: wnpp
Severity: wishlist
Owner: Olek Wojnar 

* Package name: rx-java
  Version : 3.0.7
  Upstream Author : David Karnok 
* URL : https://github.com/ReactiveX/RxJava
* License : Apache 2
  Programming Lang: Java
  Description : Reactive Extensions for the JVM
 Java VM implementation of Reactive Extensions: a library for composing
 asynchronous and event-based programs by using observable sequences.
 .
 It extends the observer pattern to support sequences of data/events and adds
 operators that allow you to compose sequences together declaratively while
 abstracting away concerns about things like low-level threading,
 synchronization, thread-safety and concurrent data structures.

This is a dependency of newer versions of Bazel.

Re: Disabling automatic upgrades on Sid by default?

[Sean Whitton]

Hello,

On Sun 27 Dec 2020 at 08:11AM GMT, Paul Wise wrote:

> I think Debian stable users should enable automatic upgrades (IIRC
> that is the case now). Debian unstable/testing users should probably
> only enable safe upgrades that don't remove packages.

I'm pretty sure it's not default because the security team do not
consider unattended-upgrades sufficiently robust.  I'm sorry for not
going ahead and verifying but I thought it should be mentioned.

-- 
Sean Whitton


signature.asc
Description: PGP signature

/usr/bin/open now in use through the alternatives system.

[Charles Plessy]

[Please CC me, I am not subscribed]

Dear all,

I went ahead and uploaded to Sid mime-support version 3.68, which
provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
the alternatives system, at a priority of 30.  I welcome other
alternatives.

I also changed the behaviour of run-mailcap so that, when run as `open`,
it will not replace the file with a temporary copy when its name needs
to be escaped.  As a consequence, there is no redundancy between the
`see` and `open` commands.

At the moment the manual page of open is simply the one of run-mailcap,
but I plan to provide a specific one.  Given the lack of answer to my
previous email (quoted below), I have not implemented URL support in
/usr/bin/run-mailcap.

> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
> > 
> > May I ask you for extra information on how important is it to support
> > URLs, and if anything beyond file:/, http:// and https:// would need
> > to be supported ?
> ...
> > Also, can you give me a pointer to an explanation of what file:/ URLs
> > are useful for ?  I read RFC 8089, but still did not get the point.
> ...
> > Since `eog http://example.com/image.png` will open the image,
> > shouldn't an "open" program ask to the server what the media type of
> > the URL is, and pass it to the default program able to handle it,
> > instead of just visualising in the browser ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Disabling automatic upgrades on Sid by default?

[Paul Wise]

On Sun, 2020-12-27 at 16:04 -0700, Sean Whitton wrote:

> I'm pretty sure it's not default because the security team do not
> consider unattended-upgrades sufficiently robust.  I'm sorry for not
> going ahead and verifying but I thought it should be mentioned.

Looks like you are correct, it is installed but disabled by default:

https://sources.debian.org/src/pkgsel/stable/pre-pkgsel.d/20update-policy
https://sources.debian.org/src/pkgsel/stable/debian/pkgsel.templates#L54

I think it was the Debian cloud images that have automatic updates.

Not sure about Debian Live images and systems installed from them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: /usr/bin/open now in use through the alternatives system.

[Holger Levsen]

Dear Charles,

thanks for driving this.

On Mon, Dec 28, 2020 at 08:15:45AM +0900, Charles Plessy wrote:
> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
> the alternatives system, at a priority of 30.  I welcome other
> alternatives.

yay!

> I also changed the behaviour of run-mailcap so that, when run as `open`,
> it will not replace the file with a temporary copy when its name needs
> to be escaped.  As a consequence, there is no redundancy between the
> `see` and `open` commands.

yay!

> At the moment the manual page of open is simply the one of run-mailcap,
> but I plan to provide a specific one.  Given the lack of answer to my
> previous email (quoted below), I have not implemented URL support in
> /usr/bin/run-mailcap.

yay!

> > Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
> > > 
> > > May I ask you for extra information on how important is it to support
> > > URLs, and if anything beyond file:/, http:// and https:// would need
> > > to be supported ?
> > ...
> > > Also, can you give me a pointer to an explanation of what file:/ URLs
> > > are useful for ?  I read RFC 8089, but still did not get the point.
> > ...
> > > Since `eog http://example.com/image.png` will open the image,
> > > shouldn't an "open" program ask to the server what the media type of
> > > the URL is, and pass it to the default program able to handle it,
> > > instead of just visualising in the browser ?

I agree, an "open" program should ask to the server what the media type of the
URL is, and pass it to the default program able to handle it.
 
Thanks, again!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Re: Disabling automatic upgrades on Sid by default?

[Paul Wise]

On Sun, Dec 27, 2020 at 11:04 AM Devops PK Carlisle LLC wrote:

> If I know that, for instance, a kernel update will break a wifi dongle
> driver or NVIDIA driver, either I must not use automatic updates at all
> and I must remember which packages I don't want to update and manually
> exclude those packages every time OR I must have enough time to repair
> what will break (and may update less often as a result).

That sounds a bit like what apt-listbugs does, but it only queries
public bugs though. It can select by severity, tags or bug numbers but
not usertags.

It should be easy enough to drop in similar pinning files manually if
you want to prevent some packages from upgrading.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Disabling automatic upgrades on Sid by default?

[Paul Wise]

On Sun, Dec 27, 2020 at 10:58 PM Lyndon Brown wrote:

> The problem with using testing as a rolling distro

Your mail reminded me about Constantly Usable Testing:

https://cut.debian.net/

> Using testing and manually pulling in select upgrades from unstable in
> such situations addresses that issue in theory, but places a huge
> burden on users to determine each day what unstable updates might
> include a security update. I'm not sure there's a reliable enough
> automated means of accomplishing this.

The security team are already manually maintaining info about which
versions of packages in unstable/testing fix security issues known
about in the security tracker, based on package changelogs and other
sources of information. For the most part, automatically pulling in
those versions using debsecan output as input to apt pinning (#725934)
and unattended-upgrades for the actual upgrades works just fine,
except when transitions in unstable are taking longer than normal to
be resolved. I have been doing this for several years now and the
issues with u-u and pinning seem to be resolved now, so it is fairly
reliable. There are still situations u-u can't resolve that mean you
have to do occasional manual upgrades though.

--
bye,
pabs

https://wiki.debian.org/PaulWise