Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Wed, 2024-05-29 at 18:58 +0200, Andreas Metzler wrote: > Hello, > > That is false dichotomy. data-loss will occur when people use /tmp or > /var/tmp for persistent data-storage because "This has (for a couple > of > years) worked on Debian systems" not because "This has (for a couple > of > years) worked on *this* *specific* Debian system.". > > cu Andreas I think you might be missing the point that this is the *DEFAULT* behaviour. You're free to override it. If you personally have no precious data in tmp storage to worry about then after upgrade you can simply tweak the config to enable the new behaviour, as I have done. I'm using Sid and after doing a little reading up on the topic yesterday after the upgrade I believe all that needed doing was to delete the /etc/tmpfiles.d/tmp.conf file, which as I understand it contains a simple override of the new behaviour defined in /usr/lib/tmpfiles.d/tmp.conf. FWIW I think Luca made a perfectly sensible choice here.
Re: Disabling automatic upgrades on Sid by default?
On Tue, 2020-12-29 at 13:17 +0200, Adrian Bunk wrote: > No. > > If the person needs someone else to setup/maintain the machine the > requirements are clear. If you say so. > > If their machine is being used for daily work and it > > possibly becoming unusable for a day or so now and then would be a > > huge > > problem, then greater stability will obviously be a must and thus > > choosing rolling/testing/unstable for it would indeed be stupid. > > This > > will not always be the case though; not every linux family/friend > > machine we may manage needs such stability guarantees and in such > > cases > > they may prefer to take the risk for the benefit of getting big > > software upgrades sooner. > > The benefit would be negative. In many cases yes, but I would not agree that in every case it absolutely would. > Anything rolling/changing is nice for a geek toy, in most other > usecases > the best solution is to find a working setup once and avoid changes > after that. The level of stability offered by Debian stable is perfectly suited to things like servers. Similar stability can be very important also for work machines. However, although I can understand where you're coming from, I take issue with your suggestion that rolling/changing is no good for anything other than "toy" systems. Rolling/changing systems are not at all as unreliable in my experience as you perhaps consider them to be, but naturally when it comes to work environments the uncertainty can often be unacceptable. > For non-technical users it can even be a problem when a button moves > or > a menu item changes. Yes, in many such cases it certainly can. > My laptop would never run anything rolling since I must be able to > rely > on that things that worked for me a year ago will still work > immediately > if I have to do the same again tomorrow. Reliability is obviously important to myself also. My laptop becoming unusable is very a big deal to me, but yet I still choose to run unstable and have done so for some years now because in my experience significant problems on unstable have been very rare; the only notable issues that I recall experiencing are a couple of instances when a major gnome upgrade broke the ability to actually start gnome on boot, disrupting things for a day or so. And yes, I install upgrades multiple times a day. Minimal delays in major software upgrades can also be valuable to me, especially in cases where having use of the latest major versions can make a difference to some of the work that I do. Those rare big breakages are my only real issue with the unstable channel; are something I expect users of testing do not experience; and are something that I expect I too could avoid encountering under an alternate model offering a rolling channel, with problematic major gnome upgrades for instance hopefully being better tested first in a separate prep/test channel. (Obviously the gnome maintainers could already perhaps do more testing in experimental first, or I could manually hold back major gnome component upgrades for a few days when they become available in future, but a proper rolling channel setup would be better I feel). I have given occasional thought to moving away from Debian to a proper rolling distro, or perhaps Ubuntu to try to get away from those rare big problems, but have not yet done so. I'd prefer to be able to simply stick with Debian under a Debian rolling channel. > > You seem to have misinterpreted what I wrote. > > > > I was comparing the resource requirements of the current model to > > the > > alternative I described. I was suggesting that the burden upon > > debian > > resources (maintainer effort, etc) would surely be little different > > from what it is now, as opposed to the alternate concept of adding > > a > > whole new rolling release channel alongside what we already have. > > Where are the resources for implementing whatever changes you > envision > in your comparison? Deliberately not there. The weight of the perpetual burden of providing a rolling channel is obviously going to be the primary concern for many in any discussion of Debian offering one. Having brought up the concept I chose to pre-empt this particular concern by suggesting that there surely would not be any additional big burden on the workload of maintainers under a reorganised channel model such as I described, as opposed to just adding an additional channel. That was the sole purpose in what I wrote about it. I was not trying to give a comprehensive assessment of all costs. I would not expect though the cost of implementation to be particularly big (a change to mirror contents; a few trivial corresponding tweaks to things like d-i, live- build, the package building infrastructure, and web interfaces like packages.debian.org; some tweaks to package migration parameters; some documentation updates; etc). > This work would surely be a burden noone except you would do. I presume you wrote that
Re: Disabling automatic upgrades on Sid by default?
On Mon, 2020-12-28 at 14:09 +0200, Adrian Bunk wrote: > On Sun, Dec 27, 2020 at 10:58:10PM +0000, Lyndon Brown wrote: > > ... > > 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. > > Debian testing is not and cannot be a proper rolling distro. Yes, I did point out in an earlier reply to this thread that some were referring to it as being an actual rolling distro when it is not. I believe that many treat it as such though. > Every 2 years testing/unstable is frozen for half a year with > maintainers not permitted to upload new versions to unstable. ...except where exceptions are granted. > If such 6 months delay is not a problem for you, Ubuntu releases are > snapshots of Debian unstable taken every 6 months and security- > supported > for 9 months. > > > 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. > > There used to be a separate testing-security team that monitored > progression of security fixes from unstable to testing and did > separate > uploads to testing when necessary. > > It ceased existing 10 years ago for the usual reason, lack of people. > > > ... > > 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). > > Using Debian testing or any rolling release distribution for this > usecase would be stupid. > > This is a clear case where everything has to be stable and non- > changing. I don't agree. This rather depends upon the requirements of each person, no? If their machine is being used for daily work and it possibly becoming unusable for a day or so now and then would be a huge problem, then greater stability will obviously be a must and thus choosing rolling/testing/unstable for it would indeed be stupid. This will not always be the case though; not every linux family/friend machine we may manage needs such stability guarantees and in such cases they may prefer to take the risk for the benefit of getting big software upgrades sooner. Using something like Ubuntu may typically be a better choice though, I can agree on that. > > 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". > > The testing ground for maintainers is experimental, but all testing > and > QA happens between unstable and testing and any kind of breakage > might > by accident happen at any time in unstable. Yes, those of us on unstable must obviously accept that risk that breakage could happen at any time and thus must be prepared as best as we can to cope with it. But, it is appreciated if maintainers keep us in mind, doing their best to avoid causing us significant breakage, rather than just casually thinking that it won't really matter if their update breaks things on unstable, that only catching problems before it reaches testing matters. > > ... > > 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, > > ... > > The internet is full of people who "envision" things, and who claim > it > "would surely not be burdensome" if other people would do the actual > work for them. > > If you want this to happen, it is you who will have to implement and > maintain it. You seem to have misinterpreted what I wrote. I was comparing the resource requirements of the current model to the alternative I described. I was suggesting that the burden upon debian resources (maintainer effort, etc) would surely be little different from what it is now, as opposed to the alternate concept of adding a whole new rolling release channel alongside what we already have. > cu > Adrian
Re: Disabling automatic upgrades on Sid by default?
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.
Re: Disabling automatic upgrades on Sid by default?
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.
Re: Disabling automatic upgrades on Sid by default?
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: restarting systemd user services on upgrade
Try the `needrestart` package. On Mon, 2020-11-09 at 09:25 +0900, Norbert Preining wrote: > Hi > > (please cc, I am not subscribed) > > is there a way to restart service@ services after the > package > upgrade? > > Onedrive ships > /lib/systemd/system/onedrive@.service > and for example on my system root has started > onedrive@norbert > service (this is better than an actual user starting, since systemd > tears down the service after log out, which I don't want). > > Now it would be nice to *restart* these services if some of them are > running. One can find this information for example via > systemctl list-units --no-legend --type=service --state=running > 'onedrive@*' > > Are there any facilities to automatically restart these services, or > is > hand-written code in postinst necessary? > > (please cc, I am not subscribed) > > Best > > Norbert > > -- > PREINING Norbert > https://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian > Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C > DC13 >
Re: Pimp your shell - Debian developer tips?
Awesome :D. I took a look at liquidprompt and the article having just
seen the email I'm responding to. It'll take a little getting used to,
but I'm liking it. I've just been using plain defaults (gnome terminal,
bash/dash) here except one customisation of re-enabling the colour
prompt to better find it in large output. Thanks for bringing this to
my attention!
One issue though, the article suggests placing this:
```
# Ensure Gnome Terminal shows the prompt correctly
PROMPT_COMMAND='echo -ne "\033]2;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'
PROMPT_COMMAND="history -a; history -c; history -r;$PROMPT_COMMAND"
```
into the .bashrc file, but not where is best to place it (or why it's
supposedly needed). Placing it at the end of the file, this results in
a prompt like this for me:
"${debian_chroot:+($debian_chroot)}lyndon@laptop:~$"
which is clearly not right.
Placing it just before this block though:
```
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033>
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
```
it seems to avoid that bug, but I don't see an immediate difference to
not having it at all...
On Fri, 2020-09-25 at 21:15 +0300, Otto Kekäläinen wrote:
> Hello!
>
> ma 8. kesäk. 2020 klo 12.04 Arturo Borrero Gonzalez
> (art...@debian.org) kirjoitti:
> > On 5/27/20 9:06 PM, Otto Kekäläinen wrote:
> > > Hello!
> > >
> > > Do we have Debian devs here who have pimped their shell heavily
> > > with custom
> > > prompts, colors, command line fonts, shell window title hacks,
> > > perhaps using zsh
> > > etc? Have you written blogs about you experiences, can you share
> > > some good reads
> > > (with screenshots) of what you have done?
> > >
> > > I've read a bit on zsh and powerline and the like, but I am
> > > annoyed that all
> > > those blog posts are quite superficial and do not mention
> > > security,
> > > interoperability or performance aspects. Frankly any blog post
> > > that recommends
> > > cloning random repos or even worse, running wget | sh something
> > > gives me chills.
> ...
> > Take a look at liquidprompt(1).
> >
> > Is what I use everywhere!
>
> This turned out to be my favourite tip. I've written about my
> experiences and why I love it so much at
> https://linuxnatives.net/2020/liquid-prompt in case others are
> interested.
>
> And thanks to Arturo for packaging it and for recently uploading the
> latest version of it to Debian unstable!
>
> - Otto
>
