Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-21 19:06, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 11:45:23AM -0400, Boruch Baum wrote:
> > On 2017-07-22 00:23, Ralph Ronnquist wrote:
> > > Boruch Baum wrote on 21/07/17 23:50:
> > > > Where else should I be looking?
> > >
> > > Perhaps you've set "APT::Default-Release "jessie";" ?
> > >
> > > Without that, you'll get the more balanced pinning of 500 and 100.
> > > I think I saw some Debian bug report (on apt?) for this.
> >
> > Thanks, Ralph!
> >
> > That's good news and solved the immediate mystery, but isn't yet an
> > entire solution.

Ok, Ralph, your fix was key, but I had to follow it up with a few
other steps. After some testing, here's some information for the
benefit of the list and other devuan users, about what seems to be
working for me.

1] First some background, The useful command for this scenario is
'apt-cache policy', which displays all the available versions of a
package, each's pin value, which is installed, and which apt would
currently want to install (labeled the "candidate").

1.1] If you are pulling in the translation sections of debian
repositories so that you can benefit from being able to locally read
long package descriptions in 'apt-cache show', you'll find that the
additional entries make it a bit more difficult to read the output of
'apt-cache policy'. For convenience, you can just temporarily comment
out those lines in you /etc/apt/sources.list while evaluating
'apt-cache policy' output, and uncomment the lines afterwards.

2] The only entry in my /etc/apt/apt.conf file was the one Ralph
pointed out was trouble. I eventually deleted the file.

3] Likewise, there were two files in /etc/apt/preferences.d,
'discourage-testing' and 'discourage-backports' that didn't suit my
use case. After testing, I deleted them and incorporated my
alternative into file '/etc/apt/preferences', below.

3.3] My use case is a Jessie install, with occasional needs or
desires for more up-to-date packages, so I need to be able to sanely
pull in and manage packages from backports and testing. I also want
allowance to be able to pull in packages from unstable for when debian
declares a package freeze, which can lock out packages from entering
testing for months (usually there's just a ten day lag for packages to
auto-migrate from unstable to testing).

4] My current file "/etc/apt/preferences" looks like this, and seems
to do the trick. It meets the criteria of my use case, it makes no
wild demands insisting that I do close to the equivalent of a
dist-upgrade to ceres, and it seems to properly decide when to upgrade
packages that had been previously installed with the default devuan
pins of 990 and 500.

4.1] To give you a practical measure of the effect of this solution,
without it 'apt-get upgrade' wanted to install 1,248 packages, and
with this config, just three.


  #+BEGIN_SRC conf
  # Apt will also pull in pinning instructions from any readable file in
  # '/etc/apt/preferences.d', so check there when maintaining this
  # function.

  Package: *
  Pin: release o=Devuan,n=jessie
  Pin-Priority: 800

  Package: *
  Pin: release o=Devuan,a=jessie-backports
  Pin-Priority: 750

  Package: *
  Pin: release o=Devuan,a=ascii
  Pin-Priority: 400

  Package: *
  Pin: release o=Devuan,a=ascii-backports
  Pin-Priority: 350

  Package: *
  Pin: release o=Devuan,n=ceres
  Pin-Priority: 200
  #+END_SRC

5] That's it! If anyone is tempted to duplicate this, I recommend
waiting as long as you can bear and contacting me off-list for an
update.

> I am very glad you solved your problem, in the end.

Thanks for the (pre-mature) verdict. I solved the problem this afternoon
ago, and included a report above for the benefit of others.

> For the future, please try to be more considerate before rushing to
> report the "incompetent" behaviour of something of somebody else :)

Funny, Why is it that I only get that kind of response from people who
only make useless unconstructive and unhelpful comments? It doesn't
sound that you have been following this thread too closely. The source
of the problem was a line of code pushed by devuan into my
/etc/apt/apt.conf file at some point. My guess, and its only a guess, is
that the issue hasn't been widespread because most user re-installed
from scratch in the transition from beta.

> WithLove

XOXO

> P.S.: Concerning the one thousand-two hundred-and-counting packages to
> upgrade, it looks like your system has remained stuck somewhere close
> to late 2015 or early 2016, so it's normal to have that many packages
> to be upgraded in 18 months, especially if you enable -backports,
> -updates, and -security.

No. Totally off-the-mark. See above.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-22 00:23, Ralph Ronnquist wrote:
> Boruch Baum wrote on 21/07/17 23:50:
> > Where else should I be looking?
>
> Perhaps you've set "APT::Default-Release "jessie";" ?
>
> Without that, you'll get the more balanced pinning of 500 and 100.
> I think I saw some Debian bug report (on apt?) for this.

Thanks, Ralph!

That's good news and solved the immediate mystery, but isn't yet an
entire solution.

The good news is that, indeed, that was the only line in my
/etc/apt/apt.conf file, and upon being commented out, running apt-cache
policy on a package such as reportbug did report all 990 pinnings gone.

The bad news is that if this is the only step I take, "apt-get" will
want to upgrade 1248 packages (it looks more impressive when I write it
out . . One Thousand, Two Hundred and Forty Eight packages) with a
download size of 608 Mb.

The over-riding news is that it's getting too close to Shabbat to be
starting to mess with this kind of thing, so continuing this will have
to wait until Saturday night or Sunday.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-21 14:14, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 08:39:50AM -0400, Boruch Baum wrote:
>
> Just to clarify, and since you are talking about "default" pin levels:
> the default pin level of standard Devuan repositories is 500. The
> default for backports and experimental is 100. So I can't explain
> where does your "default" 990 come from, except for an obvious
> mangling with pins on your side.
>
> Devuan is far from being perfect, and has several glitches, but please
> let's try to be honest and do not attribute our own glitches to Devuan
> as well: it would just be totally unfair :)

I've just now looked AGAIN manually and using grep, and haven't found
anywhere in /etc/apt or its sub-directories any explicit pin for
anything 990.

Where else should I be looking?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-21 14:01, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 08:46:27AM -0400, Boruch Baum wrote:
> > On 2017-07-21 13:24, KatolaZ wrote:
> > > Please check this first, since dozens of people are using reportbug
> > > from jessie, and their bugs are correctly reported to bugs.devuan.org.
> >
> > Enzo, I should add that though I manually submitted THREE bug reports to
> > devuan this morning, I have received neither confirmation nor email
> > bounce from any, nor does a search at http://bugs.devuan.org/ show
> > record of reciept of any of my emails. Attached is a copy of one of the
> > three emailed bug reports.
>
> You should exercise some patience, please :) The bug reports are
> processed in batches. Your emails arrived on the server aroun 11:40,
> 11:50, 12:30 UTC time, and have been processed. You should have
> received confirmation emails by now. Also, the pages on
> bugs.devuan.org are not updated immediately, so your bugs will appear
> there soon.

Just got confirmation, now. My expectation was based upon the debian
operational method, which is immediate. Since most of your target
"audience" are debian "defectors" with that expectation, maybe add a
comment message in reportbug and the website saying what you just wrote
me.

Thanks.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-21 13:57, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 08:39:50AM -0400, Boruch Baum wrote:
> > Thanks for a quick response.
> >
> >
> > On 2017-07-21 13:24, KatolaZ wrote:
> > > Which version of reportbug are you using?
> >
> > The offending version was 6.6.6~bpo8+1, and the upgraded (current)
> > version is 7.1.6+devuan2.1.
>
> So it was not Devuan's incompetence, for once :)

Well, that's a bit premature. And possibly over-sensitive . . .

> >
> > > jessie has 6.6.3+devuan1.3,
> >
> > That version does show up on my apt-cache policy output, pinned to the
> > default 990 from http://auto.mirrors.devuan.org/merged jessie/main.
> >
> > However, version 6.6.6~bpo8+1 was likewise pinned to the default 990
> > from http://auto.mirrors.devuan.org/merged jessie-backports/main
>
> So it's not installed because you have pinned a repo manually, which
> again is not Devuan's fault

1] Not so, sherlock. Better to ask me: Did you Boruch pin that manually?
   No, Enzo, I did no such thing.

1.1] But Boruch, did you double-check? Yes, Enzo, I did, and there is
   something curious, in that I don't see anywhere in /etc/apt anything
   being pinned explicitly to value 990. Where else should I look?

2] Isn't it a legitimate devuan package from a legitimate currently
   supported devuan repository?

3] Isn't it doing something quite unacceptable that it should never have
   been doing in the first place?

4] Sholdn't it be fixed, or removed, and / or have users pointed to an
   upgrade path?


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

On 2017-07-21 13:24, KatolaZ wrote:
> Please check this first, since dozens of people are using reportbug
> from jessie, and their bugs are correctly reported to bugs.devuan.org.

Enzo, I should add that though I manually submitted THREE bug reports to
devuan this morning, I have received neither confirmation nor email
bounce from any, nor does a search at http://bugs.devuan.org/ show
record of reciept of any of my emails. Attached is a copy of one of the
three emailed bug reports.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
From: Boruch Baum <boruch_b...@gmx.com>
To: Devuan Bug Tracking System <sub...@bugs.devuan.org>
Subject: mutt: Install missing required dependencies (libxapian30)
Message-ID: <20170721122023.udbzgvx3zvocf...@e15-2016.optimum.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: NeoMutt/20170113 (1.7.2)
Status: RO

Subject: mutt: Install missing required dependencies (libxapian30)
Package: mutt
Version: 1.7.2-1
Severity: serious

Dear Maintainer,

Upon upgrading `mutt' from the stable to testing repositories, mutt
ceased to function, offering the following error message:

   #+BEGIN_SRC conf
   mutt: symbol lookup error:  /usr/lib/x86_64-linux-gnu/libnotmuch.so.4:
   undefined symbol:
_ZN6Xapian9Compactor26resolve_duplicate_metadataERKNSt7__cxx1112basic_strin=
gIcSt11char_traitsIcESaIcEEEmPS7_
   #+End_SRC

Performing the following fixed the problem for me:

   #+BEGIN_SRC conf
   apt-get install libxapian30

   The following packages will be upgraded:
 libxapian-dev libxapian30 xapian-tools
   #+END_SRC


-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-2-grsec-amd64 (x86_64)
libidn: 1.29 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=3Dgcc
COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion=3D'Debian 6.3.0-2' -=
-with-bugurl=3Dfile:///usr/share/doc/gcc-6/README.Bugs --enable-languages=
=3Dc,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=3D/usr --program-suffi=
x=3D-6 --program-prefix=3Dx86_64-linux-gnu- --enable-shared --enable-linker=
-build-id --libexecdir=3D/usr/lib --without-included-gettext --enable-threa=
ds=3Dposix --libdir=3D/usr/lib --enable-nls --with-sysroot=3D/ --enable-clo=
cale=3Dgnu --enable-libstdcxx-debug --enable-libstdcxx-time=3Dyes --with-de=
fault-libstdcxx-abi=3Dnew --enable-gnu-unique-object --disable-vtable-verif=
y --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib -=
-disable-browser-plugin --enable-java-awt=3Dgtk --enable-gtk-cairo --with-j=
ava-home=3D/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --wit=
h-jvm-root-dir=3D/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=3D/=
usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=3Damd64 --=
with-ecj-jar=3D/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --=
enable-objc-gc=3Dauto --enable-multiarch --with-arch-32=3Di686 --with-abi=
=3Dm64 --with-multilib-list=3Dm32,m64,mx32 --enable-multilib --with-tune=3D=
generic --enable-checking=3Drelease --build=3Dx86_64-linux-gnu --host=3Dx86=
_64-linux-gnu --target=3Dx86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20161229 (Debian 6.3.0-2)

Configure options: '--build=3Dx86_64-linux-gnu' '--prefix=3D/usr' '--includ=
edir=3D\${prefix}/include' '--mandir=3D\${prefix}/share/man' '--infodir=3D\=
${prefix}/share/info' '--sysconfdir=3D/etc' '--localstatedir=3D/var' '--dis=
able-silent-rules' '--libdir=3D\${prefix}/lib/x86_64-linux-gnu' '--libexecd=
ir=3D\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disabl=
e-dependency-tracking' '--with-mailpath=3D/var/mail' '--enable-compressed' =
'--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--ena=
ble-imap' '--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-nntp'=
 '--enable-notmuch' '--disable-fmemopen' '--with-curses' '--with-gnutls' '-=
-with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '=
--without-bdb' '--without-qdbm' '--with-tokyocabinet' 'build_alias=3Dx86_64=
-linux-gnu' 'CFLAGS=3D-g -O2 -fdebug-prefix-map=3D/build/mutt-K2ak0h/mutt-1=
=2E7.2=3D. -fstack-protector-strong -Wformat -Werror=3Dformat-security' 'LD=
FLAGS=3D-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=3D-Wdate-time -D_FORTIFY_SOURCE=
=3D2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 -fdebug-prefix-ma=
p=3D/build/mutt-K2ak0h/mutt-1.7.2=3D. -fstack-protector-strong -Wformat -We=
rror=3Dformat-security -fno-delete-null-pointer-checks

Compile options:
+C

Re: [DNG] reportbug is the stable repository

[Boruch Baum]

Thanks for a quick response.


On 2017-07-21 13:24, KatolaZ wrote:
> Which version of reportbug are you using?

The offending version was 6.6.6~bpo8+1, and the upgraded (current)
version is 7.1.6+devuan2.1.

> jessie has 6.6.3+devuan1.3,

That version does show up on my apt-cache policy output, pinned to the
default 990 from http://auto.mirrors.devuan.org/merged jessie/main.

However, version 6.6.6~bpo8+1 was likewise pinned to the default 990
from http://auto.mirrors.devuan.org/merged jessie-backports/main

> which knows about bugs.devuan.org and correctly uses it, unless you
> have any other reportbug custom configuration (which is honoured by
> reportbug and overrides the defaults).

I just now double-checked both my ~/reportbugrc and the version at /etc.
No relevant customization.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] reportbug is the stable repository

[Boruch Baum]

Earlier today, I filed a bug report against the devuan testing version
of 'mutt', but because I was using the stable version of devuan, and the
stable version of reportbug, the report went to debian.

Now, that was incompetent. Was it incompetent of me or of devuan or
both?

Updating a recipient email address in a package isn't some major effort
that requires new testing repository dependencies - it's probably just a
debian quilt patch, and a trivial one at that.

The results are:

1] wasteful and unnecessary period of confusion and correspondence to
   clear up the situation;

2] increased negative reputation for the project in that it's not
   playing nicely with its parent project;

3] increased wariness of reporting bugs;

4] increased wariness of depending on the distribution for anything
   critical.

4.1] What an observer to the project can expect to see is a community
   expending much time and effort engaging in all kinds of very lengthy
   off-topic discussions, with an *extremely* low signal-noise-ratio,
   while certificates are left to expire multiple times, where scheduled
   outages are only announced to the "campfire" list, not the "announce"
   or "developer" list, and where bugs for the stable release are sent
   (only) to another distribution.

Was this constructive?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] WARNING! DO NOT APT-GET UPDATE/UPGRADE ON ASCII

[Boruch Baum]

Hello all,

I'd like to get a few comments in to the devuan developers before a
"fix" is decided upon. I'll also share the anecdote of how a separate
problem in the devuan infrastructure indirectly saved me from falling
victim to this incident:

1] IMO, the issue isn't really that devuan wasn't prepared for
   debian's naming change; it's that devuan decided to redirect users
   to repositories of another project.

2] That decision is guaranteed to be a source of future problems, even
   as it saves the devuan project bandwidth and hosting costs.

3] Now might be a good time to review the cost-savings of that
   decision against:

3.1] The overhead costs of maintaining the complexities of redirecting
 to outside repositories and maintaining the merged devuan
 repository.

3.2] The replacement of one point of failure (a theoretical complete
 devuan repository) with three points (the redirect mechanism, the
 devuan merged repository, the debian infrastructure).

3.3] The consequences to devuan's reputation from being reliant on
 the whims, fortunes, and circumstances of an outside project.

3.3.1] There might be a chicken-and-egg issue here in that potential
   enterprise sponsors of the project might be hesitant to support
   devuan because of how it has decided to manage its
   infrastructure, while the devuan project might be hesitant to
   invest in 100% in-huose infrastructure without enterprise
   sponsorship.

Personally, I have only a single devuan install, for non-commercial
use, based upon a combination of `stable' and `testing', and it was
saved because I had earlier noticed that the devuan infrastructure
wasn't supporting "translation" repositories. I noticed this when
`apt-cache show' wasn't displaying extended package descriptions for
non-installed packages. The best `fix' I came up with for this was a
`kludge' of reading debian's translation files directly from their
repositories. However, because this was my own 'kludge', I felt
uncomfortable enough with it that I began staging software upgrades
with `apt-get -s upgrade' and double-checking which repository and
which version were being used. Because I'm a persistently careful guy,
I continued doing this for weeks, so when the ascii/buster issue
arose, I noticed a problem immediately, but thought it was somehow due
to my personal 'kludge', and manually postponed upgrading those
particular files until I had time to investigate.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan Jessie 1.0.0 stable LTS]

[Boruch Baum]

Congratulations!

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to report?

[Boruch Baum]

Thank you, ma'am.

On 2017-03-15 19:39, goli...@dyne.org wrote:
> On 2017-03-15 19:18, Boruch Baum wrote:
> >
> >3] For EVERYONE on the list, not just Hendrick: Would SOMEONE *PLEASE*
> >just answer the only question ( and what I thought was a simple and
> >straightforward one) that I posted to this list in my original
> >message:
> >
> >   Where in devuan web-space should I cross-post the report and its fix?
> >
>
> I suggest you put it here:
> https://git.devuan.org/groups/devuan-packages/issues  You will need a
> git.devuan.org account.
>
> Once you've posted it will also appear here:
> https://dev1galaxy.org/viewforum.php?id=19
>
> You can read about that new crossover feature here:
> https://dev1galaxy.org/viewtopic.php?id=500

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to report?

[Boruch Baum]

Hi Hendrick,

1] As has happened in the past, I'm not sure I understand what you
wrote.

2] Your comment about the issue being about a ''devuan package' did
send me into a panic, so I double-checked, and it seems that the
package is the unmodified debian 'dnscrypt-proxy_1.9.4-1_amd64.deb'
downloaded from a debian repository, as forwarded by the devuan
server. Just in case I have this wrong somehow, because it is
important, what led you to think it was a package modified by devuan,
and how did you check? I don't see any dns - related package
whatsoever at, for instance:

   http://us.mirror.devuan.org/devuan/pool/main/d/

3] For EVERYONE on the list, not just Hendrick: Would SOMEONE *PLEASE*
just answer the only question ( and what I thought was a simple and
straightforward one) that I posted to this list in my original
message:

   Where in devuan web-space should I cross-post the report and its fix?

4] Why is it that anytime I ask how or where I can contribute to the
project, I get either complete silence or non-answer answers?

5] @Adam Borowski: Thanks for the assessment. My decision is to leave
the debian issue in the hands of the Eric, the debian package
maintainer, who as of yet has not commented on the report. Possibly
complicating matters is that Adrian wasn't satisified with just
altering the report's severity and title - he also merged the report
into an unrelated one, so my report is not clearly listed on the
packages bug summary page.


On 2017-03-15 18:56, Hendrik Boom wrote:
> On Wed, Mar 15, 2017 at 04:17:23PM -0400, Boruch Baum wrote:
> > Hello all,
> >
> > I recently submitted what I considered a 'grave' bugreport to
> > debian[1], which had its severity downgraded to 'wishlist' and its
> > title changed, all because of systemd, which I suspect is irrelevant
> > to my report. Where in devuan web-space should I cross-post the report
> > and its fix?
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322
>
> what strikes me about the bug report discussion is:
>
> ___
>
> > -- System Information:
> > Distributor ID: Devuan
> > Description:Devuan GNU/Linux 1.0 (jessie)
> > Release:1.0
> > Codename:   jessie
> > Architecture: x86_64
>
> Also, why are you reporting a bug against Debian for a Devuan package?
>
> ___
>
> This is probably a red flag to the debian cln.  They aren't to happy
> about getting ubuntu bugs either, unless they have been shown to be
> debian bugs as well.
>
> Does it indeed fail on Debian without sysv-init, whch is, technically,
> still a real thing?
>
> -- hendrik

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Where to report?

[Boruch Baum]

Hello all,

I recently submitted what I considered a 'grave' bugreport to
debian[1], which had its severity downgraded to 'wishlist' and its
title changed, all because of systemd, which I suspect is irrelevant
to my report. Where in devuan web-space should I cross-post the report
and its fix?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322

PS. Strictly ad hominem, the fellow who acted against my report
(Adrian Glaubitz) turned out to be quite the emotionally-charged
[expletive] in an off-board email exchange that I initiated as a
good-natured courtesy.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] [OT] gnuplot advocacy / debian packaging deficiencies

[Boruch Baum]

This is addressed primarily to anyone on this list who is a math
educator or a sysadmin in an educational instution, but may be of
interest to others with an interest in improving the debian standards
for packaging software.

I recently reported the following to debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842305

Because sometimes debian will be more responsive if a bug report
reflects more than a single user's experience and frustration, I
invite anyone on the list who has experienced this issue to add their
comment there.

Likewise, I invite any debian sysadmin for whom this type of issue is
a frustration to decide whether that venue is appropriate for
commenting and advancing how debian packages software.

Two caveats:

1] There's always a judgement call in these type of bug reports of
whether the issue should be fobbed off to upstream. This bug report
includes five components, some clearly only for debian, and others
ideally for upstream ... if upstream is a responsive actor.

2] It's not my intent for this bug report to be some excuse to
`pile-on' about the more general issue of packaging standards. There
needs to be a discussion about that, in a more general forum, and
that's legitimately part of the bug report, but turning the bug report
into a procy for the more general issue might just end up kill any
aciton on the specific package, which is the principal point of the
bug report.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evince

[Boruch Baum]

..
On 2016-05-24 12:50, Jaromil wrote:
> ...
> I agree with Robert the multi-lang support is very important and very
> well implemented in Emacs. Since many years all my work depends from
> Emacs. I've had the chance to offer a dinner to RMS for my gratitude
> for Emacs and I'll do that with any other Emacs developer I'll meet in
> my life.

The bidi algorithm does have serious problems in org-mode for
rendering paragraphs in documents with both normal right-to-left
languages of and the fashionable left-to-right ones. For example, a
Hebrew paragraph in an English org mode document renders in reverse
line order, ie. a three line paragraph will display text in the
correct direction but it will display:

   line 3
   line 2
   line 1



--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Emacs as PID1

[Boruch Baum]

> On Mon, 23 May 2016, Irrwahn wrote:
>> ...
>> Maybe if someone could add some system init code and process
>> supervision functionality to it ...

For process supervision, try 'M-x proced', a "mode for displaying
system processes and sending signals to them".

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..booting an old Sid->Ceres past runlevel 1... no login joy

[Boruch Baum]

On 2016-05-18 21:27, Arnt Karlsen wrote:
> On Wed, 18 May 2016 13:05:31 -0400, Boruch wrote in message
> > Sounds to me like an issue with 'pam', and that you're fix will be in
> > /etc/pam.d.
> > ...
> 
> ..thanks, I'll try this next if the pam diagnosis fails.

Glad to be of help. Let us know how it worked out.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..booting an old Sid->Ceres past runlevel 1... no login joy

[Boruch Baum]

On 2016-05-18 18:24, Arnt Karlsen wrote:
> DNG, I'm still left with runlevel 1, the damned thin will only
> accept root's passwd on the console, I can start and run ssh and X
> etc all day, and it works all nice except I have my password
> rejected once I try a login.

Sounds to me like an issue with 'pam', and that you're fix will be in
/etc/pam.d.

> ..exactly how is a Devuan boot supposed to work these days?
> And what systemd crud could could my logins?

systemd-logind

> And what logs do I check these days?

/var/log/auth.log

As a helpful hint, if you know a general time for which a logging
event might have occurred, use gre to help you find logs with entries
for that general time. For example:

  grep -rl "^May 16 06:5" /var/log

For the most recently modified log, sorted by time:

  ls -Rlt /var/log | less

> ..last time I had this laptop this bogged down, I simply wiped
> /etc/rc2.d/ clean and made it lean, does anyone have a lean
> Devuan machine so I can see /etc/rcS.d/ and /etc/rc2.d/ listings?

The list has been recently discussing a minimal livecd build of devuan that
might be useful for you for this. It's a ~250Mb dowloaded from

  http://devuan.kalos.mine.nu/

Read the web page for how to use it, and for how to run it in qemu.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Brief OpenRC/Jessie Discussion on the linux-elitists lists

[Boruch Baum]

On 2016-05-18 12:11, Svante Signell wrote:
> > ...
> I'm listed as a co-maintainer of openrc (as well as ifupdown). However, due to
> the hostile environment in Debian I'm reluctant to do any serious work on 
> these
> packages, except contributing to RC bugs being solved, to keep them in 
> testing.
> > ...
> In my opinion the usage of init-system-helpers is wrong, why not use the 
> package
> update system already available: update-alternatives? See also dpkg-divert.

+1
Reference:
> From boruch_b...@gmx.com Mon May  2 21:43:59 2016
> Subject: Re: [DNG] OpenRC and Devuan
>
> ...
> The idea could be developed further, to use debian's proven
> 'update-alternatives' method for switching amongst init-systems.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] devuan-minimal brief review notes

[Boruch Baum]

@KatolaZ (and everyone else): I just took the 2016-05-17 iteration of
devuan-minimal for a short spin, and here are my notes. In summary, it
seems to be a nicely prepared iso, with features that I've found
overlooked in much larger distros that make attempts to be minimal.
Nice work!

devuan-minimal.org-emacs  -*- mode: org; mode:visual-line; -*-
#+TITLE: devuan-minimal.org-emacs
* devuan-minimal.org-emacs
** 2016-05-17
*** qemu on E15
+ default boot option failed
  + frame buffer related. Message is:
#+BEGIN_SRC
fb: switching to bochsdrmfb from simple
#+END_SRC
+ Question: so how is it so many others claim success?
  + when invoking qemu with an additional option '-vga vmware', the
frame buffer boot option succeeds, and the frame buffer feature
works, as described below.
+ successful boot with nofb option
*** usb on E14
+ default boots to login
  + boot process does not auto-recognize screen
+ prompts for resolution selection, with a timeout.
+ selected option 'y'
+ possible solution: in file /etc/default/grub, comment out
  parameter 'GRUB_GFX_MODE'. That should make grub default to
  'auto'. However, I'm not really certain if that's necessary,
  because I don't see a /boot/grub/grub.cfg, so it seems that the
  iso is booting using isolinux. (true?/false?)
+ libcap2-bin not installed
  + required to query or set capabilities.
  + fbterm requires the following to be performed ONCE.
#+BEGIN_SRC
sudo setcap 'cap_sys_tty_config+ep' /usr/bin/fbterm
sudo chmod u+s /usr/bin/fbterm
#+END_SRC
+ for a livecd environment, neither command is easily possible,
  because the root filesystem is not writable. (not tested)
  + solution #1: perform the commands before burning the iso
  + solution #2: mount an aufs partition over the root partition
and apply the changes on the overlay. (not tested)
+ frame buffer works!
  + fbi renders images!
#+BEGIN_SRC
fbi /usr/share/doc/syslinux-common/examples/syslinux_splash.jpg
#+END_SRC
+ AND it's a nice picture ...
  + fbgs render pdfs!
+ tip: Review the options on the man page before use. By default,
  the program pre-renders the entire document, which can take a
  while, and the default resolution isn't low so, for example, if
  you have a large document and know you are interested in only
  pages 250-260:
  #+BEGIN_SRC
  fbgs -fp 250 -lp 260 -r 300 your-file.pdf
  #+END_SRC
+ thanks for the following features, which I have found that other
  'minimal' distros skimp on:
  + man pages
  + locate, with updatedb pre-run
+ grub
  + why is there no /boot/grub/grub.cfg?
+ missing
  + everyone will have something to chime in here about, I would
prefer to be able to list things to remove.
  + ncdu - ncurses answer to 'baobab', with more features and without
gnome-bloat.
  + htop - not *really* necessary, since 'top' is installed.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] but I lose it once I log in

[Boruch Baum]

@'Hendrik Bloom':
I no longer have SliM installed on my Devuan machine, but I remember
that the background image was set in a file named something like
'/etc/slim.conf' or '/etc/slim/slim.conf' or
'/usr/share/slim/slim.conf'

@'Go Linux':
Why not just tell Hendrik how to change the background himself? It's a
trivial change to a text config file. I no longer have the package
installed and don't remember the file name.


On 2016-05-13 15:20, Go Linux wrote:
> 
> 
> On Fri, 5/13/16, Hendrik Boom  wrote:
> 
>  Subject: [DNG] but I lose it once I log in
>  To: dng@lists.dyne.org
>  Date: Friday, May 13, 2016, 9:37 AM
>  
> On Thu, May 12, 2016 at 09:40:04PM -0400, Steve Litt wrote:
> >> Hi all,
> >>
> >> I just installed the beta, in a VM, using the x64 DVD iso.
> >>
> >> In my opinion, the user interface was very pleasing. The faded purple
> >> is very relaxing. The fonts are all crisp and clear, even in a tiny VM.
> >> And I **LOVE** the fact that the titlebar of the focused window is an
> >> extremely different color than those without focus. I'm a production
> >> man, and appreciate knowing at the quickest glance which window has
> >> focus.
> >>
> >> Great job on the UI.
> >>
> >> SteveT
> >
> > Yes that's a nice colour I see at start-up.  I wouldn't mind having
> > it after I log in.
> > 
> > But once things are going -- I use xfce -- I have a brighgt
> > yellow-green screen.   I seem to have nno way t change it.  I can
> > use Applicatinos Menu -> settings to change the settings, and they'rre
> > still there the next time I adjust settings, but the seem to have no
> > effect on the actual screen.
> > 
> > I can use geeqie to set a background image, but I have to do that every
> > time I start up.
> > 
> > -- hendrik
> > 
> 
> Unfortunately the slim login is still leafy color.  Once you get to the 
> desktop, you should have the purpy wallpaper but with the unintended blue 
> icons and incorrect adwaita pointer.  All that should have been fixed by now 
> but there have been more important issues than cosmetics.  It really is on 
> the todo list.  At least the boot screen is getting there . . .
> 
> golinux
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] booting old system on a different partition

[Boruch Baum]

On 2016-05-09 00:18, Peter Olson wrote:
> So, I installed the Devuan beta a few days ago and it is great, rather it 
> almost
> mostly works.  I probably need an audio driver installed.  I want to see what
> the old system had installed.
> 
> So I cleared out another partition and moved the backup of my Debian 8.3 onto
> it.  Ran update-grub, which found the backup in its new location.
> 
> But, when I try to boot it grub is confused and is pinned to the old UUID of 
> the
> root filesystem.  (I have already updated /etc/fstab in the restored backup, 
> but
> it is not even getting that far.)  It just dumps me into busybox saying it 
> can't
> find the root fs.  Gotta love grub, which is useful only when nothing is wrong
> :-)
> 
> Any advice about how to proceed?
> 
> Peter Olson

And, just a reminder of this last step:

code:
  update-grub # again

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] booting old system on a different partition

[Boruch Baum]

On 2016-05-09 00:18, Peter Olson wrote:
> So, I installed the Devuan beta a few days ago and it is great, rather it 
> almost
> mostly works.  I probably need an audio driver installed.  I want to see what
> the old system had installed.
> 
> So I cleared out another partition and moved the backup of my Debian 8.3 onto
> it.  Ran update-grub, which found the backup in its new location.
> 
> But, when I try to boot it grub is confused and is pinned to the old UUID of 
> the
> root filesystem.  (I have already updated /etc/fstab in the restored backup, 
> but
> it is not even getting that far.)  It just dumps me into busybox saying it 
> can't
> find the root fs.  Gotta love grub, which is useful only when nothing is wrong
> :-)
> 
> Any advice about how to proceed?
> 
> Peter Olson

Have you verified that you have a new UUID for that old backed-up
partitiion. IIRC, when one backs up a partition using 'dd
if=/dev/sd{n}{x}', the old UUID is part of the data backed up.

code:
  ls -l /dev/disk/by-uuid

If my guess is correct, for a hypothetical partition sdz9, your fix
should be something like:

code:
  tune2fs /dev/sdz9 -U $(uuidgen)


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Unofficial Devuan live images

[Boruch Baum]

FWIW, +1 for lightdm. I switched in order to get keyboard and mouse
navigation to the greeter options. For integration with xfce, I did
need to perform a few extra steps. From memory, the 'switch user'
feature needed to be altered to use 'dm-tool' instead of
'gdmflexiserver', I ended up totally removing xfce4-power-manager and
its panel applet in favor acpid-only and the xfce battery applet, and
probably other stuff that I just don't remember.

The newer versions of Lightdm (I think its available in the testing
repo) allows for a webkit-based greeter for more eye-candy if that's
of interest to you, and also offers a gui configuration tool that's
pretty neat.

There's a 'light-locker' screen locking program that installs along
with lightdm, which includes a protection feature against X-M-Fn
switching. A complaint I have against it is that it doesn't seem to
offer anything other than a blank screen (no screensaver visual
feedback or eye-candy), and it doesn't switch to a greeter screen
until a delay after one begins typing, so one can easily misinterpret
the screen lock as some form of BSOD (blank screen of death).

On 2016-05-08 10:14, fsmithred wrote:
> On 05/08/2016 08:24 AM, Hendrik Boom wrote:
> > 
> > So I google etc/slim.conf to fid out what it is, and on the first
> > link I find Warning: The SliM project has been abandoned (the
> > project homepage is down, leaving a github mirror),
> > 
> > That's on the archwiki
> > 
> > https://wiki.archlinux.org/index.php/SLiM
> > 
> > They also warn that it's incompatible with systemd.
> > 
> > I hope that's an arch-specific abandonment.
> > The gentoo page doesn't have this warning.
> > 
> > -- hendrik
> > 
> > 
> 
> 
> The github mirror has a readme that says: "Note: This repository was
> used as backup source and is no longer maintained."
> 
> 
> I'm using lightdm here. Didn't have to do anything special to get it
> to work without systemd. Don't even have libsystemd0 installed on
> this box.
> 
> -fsr

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Unofficial Devuan live images

[Boruch Baum]

FWIW, +1 for lightdm. I switched in order to get keyboard and mouse
navigation to the greeter options. For integration with xfce, I did
need to perform a few extra steps. From memory, the 'switch user'
feature needed to be altered to use 'dm-tool' instead of
'gdmflexiserver', I ended up totally removing xfce4-power-manager and
its panel applet in favor acpid-only and the xfce battery applet, and
probably other stuff that I just don't remember.

The newer versions of Lightdm (I think its available in the testing
repo) allows for a webkit-based greeter for more eye-candy if that's
of interest to you, and also offers a gui configuration tool that's
pretty neat.

There's a 'light-locker' screen locking program that installs along
with lightdm, which includes a protection feature against X-M-Fn
switching. A complaint I have against it is that it doesn't seem to
offer anything other than a blank screen (no screensaver visual
feedback or eye-candy), and it doesn't switch to a greeter screen
until a delay after one begins typing, so one can easily misinterpret
the screen lock as some form of BSOD (blank screen of death).

On 2016-05-08 10:14, fsmithred wrote:
> On 05/08/2016 08:24 AM, Hendrik Boom wrote:
> > 
> > So I google etc/slim.conf to fid out what it is, and on the first
> > link I find Warning: The SliM project has been abandoned (the
> > project homepage is down, leaving a github mirror),
> > 
> > That's on the archwiki
> > 
> > https://wiki.archlinux.org/index.php/SLiM
> > 
> > They also warn that it's incompatible with systemd.
> > 
> > I hope that's an arch-specific abandonment.
> > The gentoo page doesn't have this warning.
> > 
> > -- hendrik
> > 
> > 
> 
> 
> The github mirror has a readme that says: "Note: This repository was
> used as backup source and is no longer maintained."
> 
> 
> I'm using lightdm here. Didn't have to do anything special to get it
> to work without systemd. Don't even have libsystemd0 installed on
> this box.
> 
> -fsr

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[Boruch Baum]

On 2016-05-02 08:12, fsmithred wrote:
> No support for file system labels at this time. If someone can tell me a
> reliable way for unprivileged user to get the labels, I'll add it. Feel
> free to use these scripts as they are or as motivation to create something
> better.
Are you looking for?:

  ls -l /dev/disk/by-label

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Boruch Baum]

On 2016-05-03 01:19, parazyd wrote:
> The current init system is old. Ancient. We should all agree on it.
> Devuan is looking for a new init system that is not systemd and my
> personal choice for this task from now on is Gentoo's OpenRC.
> ...
I use a version of Manjaro linux built for openRC, and am happy
with it. However, it strikes me as misguided at this point for
any of devuan's limited development energy to focus on adopting
an openRC option instead of on resolving all outstanding systemd
issues and on establishing a solid release 1.0. Don't get me
wrong - I don't mean to be discouraging. I just don't think this
is appropriate timing.

What might be nice is some form of 'init-system-sentry' to keep
cruft of unused / unwanted init-systems out of the way. On a
Manjaro OpenRC system, there exists cruft from both sysvinit and
from systemd, if only because of the n>>1 packages that a user
will install at some point post-distro-iinstallation that include
scripts for those init systems. The presence of the cruft can
confuse one into making unnecessary changes in wrong places that
have no effect.

Instead of an openRC effort at this point, I'd rather see a hook
for apt-get / aptitude / etc, to move all files specific to init
systems not being used to their own file hierarchies, eg.

  /var/cache/init-systems
/sysvinit
  /etc
  /lib
  /usr
/openrc
  /etc
  /lib
  /usr
/systemd
  /etc
  /lib
  /usr

With something like this, devuan could remain true to init-system
freedom, keep cruft out of the way, and make it easy for
sysadmins to switch amongst init systems.

The idea could be developed further, to use debian's proven
'update-alternatives' method for switching amongst init-systems.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] simple-netaid-gtk3

[Boruch Baum]

On 04/16/2016 01:22 PM, aitor_czr wrote:
> I'm advancing with simple-netaid-gtk3. You can download the following
> video:
> 
> wget http://gnuinos.org/simple-netaid-gtk3/snetaid
I'd be game to try it.

1] What are its design goals, and what deficiency in other options (eg
package 'wi-cd') is it trying to address?

2] Is there a packaged version? Is it expecting an entry in sources.list
other than the devuan default?

3] In terms of building from sources, what I see is a zip download of a
git repo at:

  https://git.devuan.org/aitor_czr/simple-netaid-gtk/tree/master

which is identified as a "Graphical interface in Gtk3 for the backend of
'simple-netaid'".

Is the backend none other than your own 'netman' at:

  https://git.devuan.org/aitor_czr/netman

or the 'simple-netaid' at:

  https://git.devuan.org/devuan-packages/simple-netaid

or Edward Bartolo's 'simple-netaid' at:

  https://git.devuan.org/edbarx/netman


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] file system auto-check interval

[Boruch Baum]

When the devuan installer created the filesystem for my / mountpoint
ext4 file system, it set the parameters 'max-mount-counts' to -1 and
'interval-between-checks' to 0, meaning that the root filesystem would
only be checked by manual sysadmin intervention.

From the 'tune2fs' man page:

"It is strongly recommended that either -c (mount-count-dependent) or -i
(time-dependent) checking be enabled to force periodic full e2fsck(8)
checking of the filesystem."

To see your particular status:

tune2fs -l $(sed -n '/ \/ /s/ .*//p' /etc/mtab) |grep -e "Maximum mount
count" -e "Check interval"

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] icedove/thunderbird including calendar by default

[Boruch Baum]

I had posted earlier here how icedove was installing google-calendar and
iceowl, due to a 'recommends'. The issue turns out to have been a bug
reported to debian, that went to archive without any action. If anyone
here wants to comment there, see: 820...@bugs.debian.org

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] removing unwanted bluetooth

[Boruch Baum]

On 04/14/2016 06:45 AM, Rainer H. Rauschenberg wrote:
> On Thu, 14 Apr 2016, Boruch Baum wrote:
> 
>> 1] The devuan installer shouldn't include bluetooth as a default kernel
>> module.
> 
> IMHO the devuan installer only should deviate from the debian installer 
> where absolutely necessary (i.e. necessary to avoid systemd). Alle these 
> various ideas of what to change (compared to debian) only lead to more 
> work, more problems, lessen the probability of a really existing and 
> usable devuan distribution.

I agree. The significance to the report is how difficult it was to
remove the components over what I remember to be debian's pre-systemd
method (blacklisting modules by entries in text files or parameters in
the grub command line). If I'm correct in attributing the added
difficulty to systemd, then devuan would need to account for that. A
next question would be whether even debian, in its pre-systemd
existence, had been including those modules by default (I would have to
do a fresh install of an old debian to find out, but maybe others know).

I introduced the posting poorly. I'm sufficiently unsure of what went
on, that I didn't want to lay the blame for my trouble on systemd, so
instead I laid out the steps I took, so others could find any mistake I
might have made.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Slim GUI greeter with devuan theme

[Boruch Baum]

Earlier I posted how to change the slim greeter theme to make it more
consistent with other devuan elements that I had found already in the
install. I did a little more tweaking of it, and here is a link to the
current screenshot, actual files to copy, and place to comment:

  https://git.devuan.org/hellekin/slim/issues/1

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/12/2016 08:44 PM, Simon Walter wrote:
> 
> On 2016/04/13 3:03, Jaromil wrote:
>> Now if you like this project to thrive then please lower the
>> aggression you also recognize as disruptive in other projects. Let go,
>> ignore what is not interesting. Noone here needs an expert to give an
>> opinion on every topic, even if mistakes are made. Even a completely
>> selfish behavior would be tolerable (then why bother if others aren't
>> as expert as you are?) but really not aggressions. 
> 
> Yes, I was actually quite surprised at the level of emotion on this
> list. Then I realized that perhaps a lot of you have toiled in the fight
> to keep Debian full of options. I appreciate that struggle that you all
> have been through. I am actually amused most of the time.
> 
> We need to make sure that we portray ourselves in a way that others see
> we will not harm the community nor the project. Once someone starts
> expressing themselves in a way that makes it difficult for others to
> take seriously, that's unhealthy for the community. I don't mean that we
> have to be PC about everything, but we need to respect each other. Then
> we can challenge each other in honesty and seriousness. Otherwise it
> becomes personal. On this list, we are about Devuan, not about ourselves.

I didn't absolutely need to use the word 'yenta' in order to get my
basic point across in my original comment, so in view of the response to
my using it, I apologize to the list - I had no bad intent in using the
term. (OT: the term doesn't carry any baggage of bad intent to it, in
the sense that I've never heard of anyone picking a fight or starting
one over calling someone or someone's mom a yenta).

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] removing unwanted bluetooth

[Boruch Baum]

Though my hardware does include bluetooth capability, I had never
explicitly asked for any form of bluetooth to be installed on my system,
and was surprised (puzzled, alarmed, annoyed) to see among my scrolling
boot messages, a warning that a bluetooth patch was failing to load.
Looking at 'dmesg' output further showed that the kernel was
initializing bluetooth components.

1] The devuan installer shouldn't include bluetooth as a default kernel
module. They can be loaded later, if ever required (My biases against
bluetooth by default are that its a security fright and a needless and
continual power drain).

2] For the default devuan desktop, the reason for bluetooth in my case
seems to have traced back to the 'gnome-orca' screen reader (the process
of removing bluetooth was much more involved than I expected, so I
hadn't been taking notes at that early point).

3] It was insufficient (but possibly necessary?):

3.1] create a file /etc/modprobe.d/bluetooth.conf
  #+BEGIN_SRC
  blacklist bluetooth
  blacklist bnep
  blacklist btusb
  #+END_SRC

3.2] rmmod -f for each of 'bluetooth', 'bnep', 'btusb', 'l2cap', sco'

3.3] create a file /etc/default/bluetooth
  #+BEGIN_SRC
  BLUETOOTH_ENABLED=0
  #+END_SRC

3.4] Modify file /etc/default/grub so that the DEFAULT_CMD_LINE includes
"bluetooth.blacklist=yes". Then run 'update-grub'.

3.5] update-initramfs -u -k $(uname -r) -v

4] What was sufficient (but hopefully unnecessary) to remove the
bluetooth patch message

4.1] manually delete the kernel modules folder
/lib/modules/3.16.0-4-amd64/kernel/drivers/bluetooth. I didn't REALLY
delete it, just moved it to /root/kernel-modules/drivers/.

4.2] lsmod still lists bluetooth

4.3] it was only at this point that it was possible to: modprobe
--first-time -v -r -f bluetooth

5] What was additionally sufficient (but again, hopefully unnecessary)
to permanently remove the modules:

5.1] manually delete (ie move to a backup location) the folders
  /lib/modules/3.16.0-4-amd64/kernel/net/bluetooth
  /lib/modules/3.16.0-4-amd64/kernel/net/ieee802154

5.2] update-initramfs -u -k $(uname -r) -v

6] This isn't a GOOD solution; it's a barbaric hack that probably won't
survive a system update of kernel modules, unless one 'chmod 000' the
three folders mentioned instead of moving them.

6.1] What I had been expecting to be able to do was simply to blacklist
the modules and update-initramfs. I don't understand why that no longer
works.

6.2] Part of my brain is yelling that this is related to some
requirement or expectation of systemd.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/12/2016 08:41 AM, Mitt Green wrote:
> Boruch Baum wrote:
>> No improvement.
> 
> ‎This requires, certainly, consolekit to be installed
Check. But see below, final paragraph.

> and. xinitrc with "startxfce4 --with-ck-launch"
Hmm. I've got "exec ck-launch-session dbus-launch startxfce4". Between
your version, the man page and /etc/xdg/xfce4/xinitrc, you've given me a
bunch of ideas to play with, more opportunities to bang my head against
the wall. Thanks, I think.

> I don't have an opportunity to try myself, as I dumped Xfce a
> quarter ago in favour of Openbox and then dwm,
I don't blame you. I'm an i3wm user by preference, but if I'm going to
evaluate devuan, this is what I should be doing for that.

BTW, if you're coming to dwm from openbox, check this out:

https://github.com/Boruch-Baum/morc_menu

> but the shenanigans I'm sending were sent by me earlier in the list 
> and thus were tested. I didn't incorporate the use of any kind of 
> display manager though, neither then, nor do now.
Yup, there is indication in the file /etc/xdg/xfce4/xinitrc that the
ck-launch option "is only required for starting from a console, not a
login manager". Since I'm doing this as an evaluation, I'm still using
devuan's default Slim login manager. So, more to play with. This looks
promising in that it invites a reason for the trouble: I had originally
installed devuan as cli-only, so there was no display manager installed.
When I later added the 'task' for the default desktop, which does
include a DM (doh!), the devuan config may not have performed all the
steps that the devuan installer would have. But, at this point that's a
few jumps to conclusion.

> Cheers, Mitt ___
Regards,

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

No improvement.

On 04/12/2016 01:32 AM, Mitt Green wrote:
> Boruch Baum wrote:‎
> 
>> I don't yet have a working solution for 'switch-users',
>> 'shutdown', or 'restart'.
> 
> Try these:
> create /etc/polkit-1/localauthority/50-local.d/‎consolekit.pkla and with the 
> content: 
> 
> --
> 
> [restart]
> Identity=unix-user:* 
> Action=org.freedesktop.consolekit.system.restart 
> ResultAny=yes 
> 
> [stop] 
> Identity=unix-user:* 
> Action=org.freedesktop.consolekit.system.stop 
> ResultAny=yes
> 
> --

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/12/2016 01:32 AM, Mitt Green wrote:
> Boruch Baum wrote:‎
> 
>> I don't yet have a working solution for 'switch-users',
>> 'shutdown', or 'restart'.
> 
> Try these:
Thanks, Mitt. I had tried those earlier (along with the parallel actions
ending with "-multiple-users", to no avail. However, I put them all in
the same file as the org.freedesktop.upower.hibernate and .suspend
actions. I'll try them in their own file now, though I'm dubious that
should make a difference.

> create /etc/polkit-1/localauthority/50-local.d/‎consolekit.pkla and with the 
> content: 
> 
> --
> 
> [restart]
> Identity=unix-user:* 
> Action=org.freedesktop.consolekit.system.restart 
> ResultAny=yes 
> 
> [stop] 
> Identity=unix-user:* 
> Action=org.freedesktop.consolekit.system.stop 
> ResultAny=yes
> 
> --

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/12/2016 01:36 AM, Go Linux wrote:
> On Mon, 4/11/16, Boruch Baum <boruch_b...@gmx.com> wrote:
>  On 04/11/2016 09:40 PM, Go Linux wrote:
>>>> On Mon, 4/11/16, Boruch Baum <boruch_b...@gmx.com> wrote:
>>>> Upon adding a GUI on top of a pre-existing cli-only install of
>>>> devuan-alpha-4, the functionality of suspend, hibernate, switch-users,
>>>> shutdown and restart were unavailable to the desktop user.
>>>>
> 
> [snip]
> 
>>>>
>>>> I don't yet have a working solution for 'switch-users', 'shutdown', or
>>>> 'restart'.
>>>
>>> 
>>>
>>> Installing upower and libupower-glib1 from the devuan repos got the
>>> whole shebang working for me from the xfce panel and/or main menu. I
>>> suspect that xfce4-power-manager also has something to do with it.
>>
>>
>> My installed versions for upower, libupower-glib1:amd64, and
>> libupower-glib1:amd64 are all 1:0.9.23-2+devuan1.2
>>
>> The polkit actions:
>> org.freedesktop.consolekit.system.stop
>> org.freedesktop.consolekit.system.restart
>>   org.freedesktop.consolekit.stop-multiple-users
>>   org.freedesktop.consolekit.system.restart-multiple-users
>> seem to be those that would control the remaining issues, and the
>> installed version of consolekit is 0.4.6-5, from:
>> us.mirror.devuan.org_merged_dists_jessie_main_binary-amd64_Packages
>>
>> Do you get any ouput from running?:
>> find /etc/polkit-1/localauthority -type f -print -exec cat '{}' \;
>>
>> If so, could you post it?
>>
> 
> That command didn't spit out a thing.  Note that I am on 32 bit devuan if 
> that might make a difference.
I'm assuming that when you installed devuan, you asked the installer to
install a desktop environment. If so, your result tells me that my
tweaks to the polkit configuration are unnecessary and not the way
devuan is enabling those features. That's important for a few reasons:

1] You didn't get an error message, which tells me devuan installed
polkit on your system. The next question is why.

1.1] Could you look at the result of running the following:

  head -qn1 /var/log/dpkg.log*
  grep -hm1 polkit /var/log/dpkg.log*

The first should tell us when you installed devuan, and the date of the
second's output is a proxy for telling whether the installer did the
deed itself, or whether whether apt/gdebi/etc did it later.

2] There shouldn't be more than one authorization agent operating. At
best, it's confusing to administer, and at worst could freeze a system.

3] The tweaks I performed are the way the polkit developers want the
system to work, and it did work for me, so what else is going on in
parallel in devuan?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/12/2016 02:27 AM, Jaromil wrote:
> 
> I have created an issue to keep track of the ongoing research
> 
> https://git.devuan.org/devuan-packages/policykit-1/issues/5
> 
> thanks!
You're welcome. GoLinux's response may indicate that my problem is NOT
due to polkit. I'll explain in my response to him after I finish writing
this.

> please consider contributing this sort of issues to gitlab issues as
> it really helps organizing tasks for developers. Debating in email is
> fine, but then someone needs to roundup the conclusions in an issue to
> make sure its not lost in the mailinglist archive.
> 

I haven't been posting here to debate; I've been posting here because
the git issues arena has been in the past so lonely and unresponsive, it
seems that people only read this list.

OK. I'll make a 'deal' with the other members on the list. If in the
next week at least ten people other than hellenkin, Jaromil and Daniel
Reurich each add two real issues or solve two real issues, I will
manually go back through all my past postings since I joined the list,
and re-enter them as issues on github.

I'll sweeten the deal: If the list doesn't match the challenge, I'll
still do it if the 'usual' yentas on the list (you know who you are) can
keep a lid on their OT posts / trolls / rants / 'news' items for just
one month.

> ciao
aloha (better weather...)

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend

[Boruch Baum]

On 04/11/2016 09:40 PM, Go Linux wrote:
> On Mon, 4/11/16, Boruch Baum <boruch_b...@gmx.com> wrote:
>> Upon adding a GUI on top of a pre-existing cli-only install of
>> devuan-alpha-4, the functionality of suspend, hibernate, switch-users,
>> shutdown and restart were unavailable to the desktop user.
>> 
>> The easy solution for suspend and hibernate is to create a pkla file in
>> folder /etc/polkit-1/localauthority/50-local.d with contents:
>> 
>> [Allow locally logged in members of group 'power' to put the hardware in
>> suspend mode]
>> Identity=unix-user:*
>> Action=org.freedesktop.upower.suspend
>> ResultAny=no
>> ResultInactive=yes
>> ResultActive=yes
>> 
>> [Allow locally logged in members of group 'power' to put the hardware in
>> hibernate mode]
>> Identity=unix-user:*
>> Action=org.freedesktop.upower.hibernate
>> ResultAny=no
>> ResultInactive=yes
>> ResultActive=yes
>> 
>> The more complex solution is to create a group 'power', add desktop
>> users to that group, and then create the above file, but replacing
>> 'unix-user:*' with unix-group:power'.
>> 
>> I don't yet have a working solution for 'switch-users', 'shutdown', or
>> 'restart'.
> 
> 
> 
> Installing upower and libupower-glib1 from the devuan repos got the
> whole shebang working for me from the xfce panel and/or main menu. I
> suspect that xfce4-power-manager also has something to do with it.

My installed versions for upower, libupower-glib1:amd64, and
libupower-glib1:amd64 are all 1:0.9.23-2+devuan1.2

The polkit actions:
  org.freedesktop.consolekit.system.stop
  org.freedesktop.consolekit.system.restart
  org.freedesktop.consolekit.stop-multiple-users
  org.freedesktop.consolekit.system.restart-multiple-users
seem to be those that would control the remaining issues, and the
installed version of consolekit is 0.4.6-5, from:
us.mirror.devuan.org_merged_dists_jessie_main_binary-amd64_Packages

Do you get any ouput from running?:
find /etc/polkit-1/localauthority -type f -print -exec cat '{}' \;

If so, could you post it?

IMPORTANT: There is, across the internet, mention of a different policy
file, /usr/share/polkit-1/actions/org.freedesktop.login1.policy instead
of org.freedesktop.consolekit.policy. According to the ArchWIki, it is
package systemd-logind that stands behind this alternative.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] suspend

[Boruch Baum]

Upon adding a GUI on top of a pre-existing cli-only install of
devuan-alpha-4, the functionality of suspend, hibernate, switch-users,
shutdown and restart were unavailable to the desktop user.

The easy solution for suspend and hibernate is to create a pkla file in
folder /etc/polkit-1/localauthority/50-local.d with contents:

[Allow locally logged in members of group 'power' to put the hardware in
suspend mode]
Identity=unix-user:*
Action=org.freedesktop.upower.suspend
ResultAny=no
ResultInactive=yes
ResultActive=yes

[Allow locally logged in members of group 'power' to put the hardware in
hibernate mode]
Identity=unix-user:*
Action=org.freedesktop.upower.hibernate
ResultAny=no
ResultInactive=yes
ResultActive=yes

The more complex solution is to create a group 'power', add desktop
users to that group, and then create the above file, but replacing
'unix-user:*' with unix-group:power'.

I don't yet have a working solution for 'switch-users', 'shutdown', or
'restart'.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] slim gui greeter and slimlock screen locker

[Boruch Baum]

When I originally installed devuan-alpha for evaluation, I did so only
for the basic cli-only system, and only recently added a GUI.

1] The slim greeter theme is inconsistent with the rest of the devuan
theme, even though all the files are in place to make it consistent.

1.1] How to do it on your own:

# aa="/usr/share/slim/themes/devuan-boruch" ; mkdir $aa; cd $aa
# cp ../devuan/slim.theme ./
# cp /usr/share/images/desktop-base/your-way_purpy-wide-small.png \
 ./background.png
# cp background.png panel.png

In the file 'slim.theme', change background_style to 'stretch'. You'll
probably then want to adjust the locations that different things print
out, eg. 'input_name_x 121', 'input_name_y 150', 'username_x 121'
'username_y 120', 'password_x 121', 'password_y 120'. I also changed all
the colors to #22 (its a free country, that way).

2] The slimlock configuration file was not present.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Devuan grub files

[Boruch Baum]

On 03/22/2016 06:04 AM, Jaromil wrote:
> On Mon, 21 Mar 2016, Boruch Baum wrote:
>
>> On that note, I'll chime in and say that I hate the red greeter
>> screen of the installer.
>
> CenturionDan also reported that the theme is causing problems to the
> cd-installer so we'll likely drop it for a good old text terminal.
>
> thanks for your insights

1] I've recently added X11 etc on top of a cli-only devuan, and I think
I'm now seeing what you said CenturionDan may have reported, which is
that upon a reboot of a target (not the liveCD) on which package
'desktop-base' has been installed, the grub settings are modified over
those of the cli-only setup. This modification seems to have confused
'grub theming' and 'grub customization' but, Jaromil, there's no need to
"drop it for a good old text terminal" if by that you mean drop the red
greeter screen of the installer for a black background.

1.1] What works better for me is to tweak the file
/etc/grub.d/05_debian_theme:

At the beginning of its execution (the code starts with several function
definitions), insert:

echo "set menu_color_normal=black/black"
echo "set menu_color_highlight=yellow/black"
if [ -f "/usr/share/desktop-base/grub-themes/devuan/background.png" ] ; then
  echo "background_image
/usr/share/desktop-base/grub-themes/devuan/background.png"
  exit 0
fi

2] Devuan should have the same grub presentation regardless of whether a
GUI is installed.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Boruch Baum]

On 04/07/2016 01:05 PM, Rainer Weikusat wrote:
> "Jack L. Frost" <f...@fleshless.org> writes:
>> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
>>> Please consider setting the default /etc/fstab to include:
>>> 
>>> proc/proc   procdefaults,hidepid=2
>>> 
>>> This has the effect of keeping the specific activities, process
>>> ids, command lines and parameters of a user from other users.
>> 
>> I've been using hidepid=2 as a default in my toy distro and haven't
>> found a usecase where that would be a bad default. So unless there
>> are common enough usecases where users need to see others'
>> processes, I agree.
> 
> Since this is an argument for changing the default behaviour, there 
> ought to be some "common enough" use cases where that would be 
> beneficial. Eg, why should daemon processes running on a machine used
> by a single person, say, the proverbial "clueless newbie", be
> forcibly hidden from the owner of the computer unless he happens to
> be running as root?
Nothing in Linux is done by 'force', Ranier. The sysadmin always has
choice. The issue is whether basic security issues should be opt-in or
opt-out. If the sysadmin of your example is so much a "clueless newbie",
to not know how to use root (or even sudo), then no admin task
whatsoever will be possible on the system.

> The 'common use case' where the default behaviour is useful would
> still be a system with one physical user running processes supposed
> to be various useful tasks using a variety of different user IDs. Eg,
> the web server I'm using to get files onto iOS devices runs as
> www-data, the DNS resolver as bind, the program getting my e-mails as
> fetchmail, the timekeeping daemon as ntp, the line printer daemon as
> daemon and all kernel threads runs as root. In case something "seems
> wrong", eg, the system starts to behave sluggishly, I can do a quick
> check of the status of everything without doing an uid change first.
> I can check if I started the mail downloader at all with a mere ps
> faux or pgrep fetchmail. Kernel threads using enormous amounts of CPU
> time are visible to me without running top as root. etc

Do you realize that you're basically repeating the talking points used
by Microsoft when it originally released Windows OS?

I think I'm beginning to get where you're coming from when you make your
recommendations, and that's important to know in order to respond to
you. If I do have you figured out, your issue is that you're not
thinking outside your box ("box" also in the sense of your hardware).

Linux / Unix / Solaris / etc are meant to be multi-user operating
systems. Please remember that: multi-user. In the 1980's, Microsoft
Windows decided to adopt your approach, and they have been back-pedaling
ever since. The single-user use-case is not Linux's design-goal. Those
particular Linux projects with that design goal, such as Puppy, do
address your complaint. They do so by running as root by default.

Likewise, Linux's design goal has never been to be a clone of your
personal iOS devices. Its world is a lot bigger than single-user
mobile-devices.

It might be useful to review Debian's design goal, to be "the universal
OS". Debian is meant to be used in environments that scale up past 10^4,
10^5, 10^6 + users. Their developers aren't basement hobbyists. Their
decisions are scrutinized by, and have input from, the largest of
corporations. Devuan is meant to be debian without systemd. If your
world and perspective doesn't extend past your single-user mobile
device, Debian can -also- be useful for you. It is, after all, "the
universal OS". It can be customized and tailored to your
needs. Google did so with Android; Apple based iOS on BSD. I don't
remember the others.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] TLS / files.do

[Boruch Baum]

On 04/07/2016 07:40 AM, hellekin wrote:
> In case you didn't notice, all servers are now using proper TLS
> certificates from Let's Encrypt, except one host: files.devuan.org, that
> mysteriously failed to acquire some.  So this one is using a free
> certificate from Startcom.
> 
> If you encounter any issue with TLS, please report to
> https://git.devuan.org/devuan-infrastructure/todo/issues
> 
Didn't notice (yet). Thank you!

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Subject: Re: useradd defaults

[Boruch Baum]

On 04/05/2016 01:33 AM, Robert Storey wrote:
>>> I'm getting a bit uncomfortable about starting this thread, because upon
>>> reflection, it seems that one consequence of setting the system-wide may
>>> be that the 027 umask will end up having some system account creating a
>>> file that should be world-readable or world-executable, but because of
>>> the umask, it now would not be, and so would break stuff. My intent was
>>> to protect data of one user from other users, which could be done by
>>> making the change in .profile or even in the default .bashrc.
>>>
>>
>> I was actually waiting for somebody to realise this before answering
>> your email. In a "Universal OS" there is much more than the
>> preferences of single specific users, or specific applications, or
>> specific environments. There is the necessity to accommodate a huge
>> number of different scenarios and use cases. In short, that's why you
>> have the umask set by default to 022. Any user can change this
>> behaviour to a more restrictive one, if they need so.
> 
> Yes indeed - permission errors are among the most common difficulties that
> inexperienced users encounter when they first start with Linux. Long ago, I
> tried setting my own umask to 077, thinking that it would enhance my
> security. Didn't occur to me until later that it broke all the web pages I
> created and uploaded to my site, since no one but me could read them. Once
> I realized it, I was able to fix the problem with chmod, but it was easy
> enough to forget to do that when creating a new page, and I eventually
> decided the only sane solution was to go back to umask 022, which was the
> default.
> 
> I ran into the above problem after I'd been using Linux for about five
> years, and I understood the cause once somebody complained to me that he
> couldn't read my site even though I still could. However, had I run into
> this difficulty earlier in my Linux career, I probably would not have been
> able to figure out the cause, and would have concluded that "Linux is no
> good." So I favor keeping the default umask at 022, and let users tweak
> their own .bashrc and .profile if they want more restrictive security.
> 
> cheers,
> Robert
You and others on the list misunderstood my comment. I stand by my
original proposal to change the /etc/profile to either 027 or 077, for
the benefit of user accounts. My reservations arose when someone else on
the list 'corrected' me and suggesting applying that to pam_session
which I understand would apply it to system accounts also. On a
multi-user system like in real life your 'stuff' should be private until
you decide to make it public.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Boruch Baum]

On 04/04/2016 11:22 AM, Rainer Weikusat wrote:
> Boruch Baum <boruch_b...@gmx.com> writes:
>> Please consider setting the default /etc/fstab to include:
>> 
>> proc/proc   procdefaults,hidepid=2
>> 
>> This has the effect of keeping the specific activities, process
>> ids, command lines and parameters of a user from other users.
> 
> If you think that's useful to you, why don't you just use it.
I do.

> It's not useful to me[*] and - IMHO - generally useless on any system
> where more than one user with privileged access works on a
> cooperative projects.
My understanding is that the intention of the design of the UNIX
architecture in such cases is to have members of a 'project' be assigned
a similar 'group' to allow mutual 'group' access.

> [*] "Everyday real-world example": One of the things I'm dealing with
> is a proprietary racoon fork part of a VPN product for mobiles
> (hefty simplification). I usually don't work on code as root but in
> case I need to run a debugging session, I have to run the debugger as
> root as it will need to be able to control a privileged process,
> namely, the IKE daemon. Being prevented from seeing my own processes
> via ps because they happen to be running with elevated privileges
> would at least be a nuisance.
You're trying to make a case for lowering system security using an
example of a project meant to raise system security. It seems to me, as
an outsider to your case, that you would be compromising your ipsec
efforts with the large and elementary security hole you're willing to
make - to allow any one / any process to see every other.

Another approach I've seen in some linux distributions intended for
security / forensic research and testing is to expect the user to always
be running as root (Kali linux comes to mind in that regard).

As a security-conscious person, you seem to be advocating a default of
lack-of-security, where the universal set of devuan users would have to
a] be aware of the vulnerability, and b] take a positive action to
opt-in to be secure.

My position is that this is a basic security precaution that should be
opt-out, not opt-in. Most users won't notice, except possibly for lack
of clutter in their htop / ps -aux output. More sophisticated users with
a specific need like yours can make the judgment call, as masters of
their own destiny, to drop the feature (or set up some other access
control regimen),

Finally, in the case you mentioned, I'm not certain I understand what
you mean when you say you would be "prevented from seeing my own
processes via ps because they happen to be running with elevated
privileges" - you said earlier that you run the debugger as root, and as
root you would be seeing ALL processes. If you're not running as root,
you would still be seeing all the other processes of your shared group.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ...and when trolling went too far

[Boruch Baum]

I'm NOT specifically ranting against either Simon or Trond below. I'm
addressing the wider issue, that I think is pretty obvious to anyone
following this list for any amount of time.

On 04/04/2016 09:00 AM, Simon Walter wrote:
> On 2016/04/04 17:39, Trond Arild Ydersbond wrote:
>> Den Mandag, 4. april 2016 8.09 skrev Mitt Green :
>> https://en.wikipedia.org/w/index.php?title=Lennart_Poettering=703955376
>>
>>
>>
>> Representing him as an ass and bloatware generator is definitely not
>> in the interest of those challenging his actions as a developer. Why
>> the heck give that guy any martyr cards to play?
Sorry to ruin the party, but I'll object to it because its just not a
nice thing to do, and its an awful thing to mess up content on the fine
site that is wikipedia.

> There is obviously enough demand for systemd. So challenging his actions
> on a technical level would be difficult. What is strange is how ditros
> other than RH have jumped on the bandwagon - especially Debian.
> 
> "Never attribute to malice that which is adequately explained by
> stupidity..." or laziness. It is one or a mixture of the three: malice,
> laziness, and or stupidity.
> 
> I am daily amazed by stupidity. It might be the TV or something in the
> food, but it's getting worse.
What daily amazes me is how easy it is for people on this list to get
distracted from doing something positive, ie contributing to the
progress of devuan, and opt instead for the negative - being
disrespectful to people, or projects. You're not my grandkids, so you're
not going to get a 'talk' from me, but all of you on the list, please
just get a grip.

You know what. How about this. Think of systemd as that girlfriend you
broke up with. You've decided to dump systemd, so be done with it. Leave
it behind and move on. It's over. If you can't forget about her, its not
over, and frankly, something in your head is messed up.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] useradd defaults

[Boruch Baum]

On 04/04/2016 06:17 AM, tilt! wrote:
> Am 04.04.2016 um 04:54 schrieb fsmithred:
>>session optional pam_umask.so umask=0022"
> 
> Add such customization to
> 
>/etc/pam.d/common-session
> 
> instead. The statement should appear after the end of the block that is
> automatically updated by "pam-auth-update", i.e. it should follow the line
> 
># end of pam-auth-update config
> 
> I tested the statement
> 
>session optional pam_umask.so umask=0027
> 
> and it gives me the expected result.
> 
> See /etc/pam.d/common-session and pam-auth-update(8) for more details

I'm getting a bit uncomfortable about starting this thread, because upon
reflection, it seems that one consequence of setting the system-wide may
be that the 027 umask will end up having some system account creating a
file that should be world-readable or world-executable, but because of
the umask, it now would not be, and so would break stuff. My intent was
to protect data of one user from other users, which could be done by
making the change in .profile or even in the default .bashrc.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] icedove install-recommends

[Boruch Baum]

The default install for icedove also installs packages
'calendar-google-overview' and 'iceowl-extension'. I don't remember such
in any other install of icedove or thunderbird.

Personally, I'm in the camp of opposing the integration of mail and
calendar, kind of out of the same sensibility that has me opposing systemd.

One can over-ride the default by using --no-install-recommends, but
devuan, should it choose to do so, can take a stand by including icedove
in the default install without the two packages.

My vote is obvious. Please consider.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Another multi-user issue

[Boruch Baum]

Please consider setting the default /etc/fstab to include:

proc/proc   procdefaults,hidepid=2

This has the effect of keeping the specific activities, process ids,
command lines and parameters of a user from other users.

If you're not familiar with this, even if you don't have a second user
set up, you can observe the significance, by doing the following:

$ ps -aux  # Lookee! I can see everything that user 'root' is doing!

# mount -o remount,defaults,hidepid=2 /proc

$ ps -aux  # Forced to mind one's own business

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] xscreensaver issues (including hardcoded DEBIAN!)

[Boruch Baum]

On 04/01/2016 08:55 PM, Robert Storey wrote:
>> Adam Borowski wrote:
>>
>>  On Fri, Apr 01, 2016 at 12:58:23PM -0400, Boruch Baum wrote:
>>> Just looking at issues with the devuan default desktop's screensave, and
>>> its config file:  ~/.xscreensaver file, posted here for the attention of
>>> the maintainers and the interest of members of the list.
>>>
>>> 1] Obnoxious nag messages - All logins to the devuan default desktop
>>> begin with not one but two separate nag messages from xscreensaver. The
>>> first "warns" the user that the version is out of date. The second
>>> "warns" the user that the sysadmin is doing a dis-service by keeping it
>>> out of date.
>>>
>>> 2] forced config screen - after the two obnoxious nag messages, one is
>>> forced to be confronted with the xscreensaver customization screen
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
>>
>> It's a time bomb by xscreensaver's upstream author.  And like micq before,
>> it looks like xscreensaver needs to be replaced or forked.  Obviously,
> using
>> gnome-screensaver is not an option as that pulls in a good part of Gnome3
>> including systemd.
> 
> I'd just like to mention that Xscreensaver is one of those obnoxious
> "convenience features" that I'm always trying to disable. So at least from
> my point of view, if it's not installed by default, I'm fine with that. But
> I realize that others may want it.

+1

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] xscreensaver issues (including hardcoded DEBIAN!)

[Boruch Baum]

On 04/01/2016 03:18 PM, Daniel Reurich wrote:
> On 02/04/16 07:58, Boruch Baum wrote:
>> On 04/01/2016 02:31 PM, Adam Borowski wrote:
>>> On Fri, Apr 01, 2016 at 12:58:23PM -0400, Boruch Baum wrote:
>>>> Just looking at issues with the devuan default desktop's screensave, and
>>>> its config file:  ~/.xscreensaver file, posted here for the attention of
>>>> the maintainers and the interest of members of the list.
>>>>
>>>> 1] Obnoxious nag messages - All logins to the devuan default desktop
>>>> begin with not one but two separate nag messages from xscreensaver. The
>>>> first "warns" the user that the version is out of date. The second
>>>> "warns" the user that the sysadmin is doing a dis-service by keeping it
>>>> out of date.
>>>>
>>>> 2] forced config screen - after the two obnoxious nag messages, one is
>>>> forced to be confronted with the xscreensaver customization screen
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
>>>
>>> It's a time bomb by xscreensaver's upstream author.  And like micq before,
>>> it looks like xscreensaver needs to be replaced or forked.  Obviously, using
>>> gnome-screensaver is not an option as that pulls in a good part of Gnome3
>>> including systemd.
>>>
>>
>> I'm not one to jump to that kind of conclusion before looking at some
>> alternatives first. It's possible that the solution has already been
>> provided by the author - I haven't checked the packages MAKEFILE for
>> possible build-time config options, or other compile-time options.
>> Lacking that, its also possible and may be appropriate to use debian's
>> 'quilt' system to patch the upstream. It's also possible that just
>> contacting the author and making a request will effect a change.
>>
> gnome-screensaver depends on libsystemd0 directly as well as on
> gnome-session-bin which also depends on libsystemd0
> 
> Are you volunteering to repackage them?
> 
> With regards to packaging core gnome packages, I have a current issue
> with tracking all the from debian in our preferred git workflow because
> it uses subversion for just the /debian folder of each package.
> 
> This means importing to git in a way that we are able to track both the
> upstream source and debians vcs is hard.  I have almost sorted the plan
> for doing that so we can have a good process that will be easier to work
> with in the long term and we will retain at our fingertips the full
> development history from both upstream and debian.
> 
> 
> regards,
>   Daniel
> 
The link Adam provided to the debian bug report discussion indicates
debian is moving to deal with the nag screen issue.

As for the hard-coded debian URL, I have another idea that's a kludge,
but it'll probably work, and its real simple: place a default version of
'.xscreensaver' in /etc/skel. Let me stress though that I haven't looked
at the package's MAKEFILE, or the current debian 'quilt' entries, and my
sense is that one of those is the culprit.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] xscreensaver issues (including hardcoded DEBIAN!)

[Boruch Baum]

SORRY ADAM!

I didn't read your link till after I hit send! Everything is in your
link. Thanks for providing it.

On 04/01/2016 02:31 PM, Adam Borowski wrote:
> On Fri, Apr 01, 2016 at 12:58:23PM -0400, Boruch Baum wrote:
>> Just looking at issues with the devuan default desktop's screensave, and
>> its config file:  ~/.xscreensaver file, posted here for the attention of
>> the maintainers and the interest of members of the list.
>>
>> 1] Obnoxious nag messages - All logins to the devuan default desktop
>> begin with not one but two separate nag messages from xscreensaver. The
>> first "warns" the user that the version is out of date. The second
>> "warns" the user that the sysadmin is doing a dis-service by keeping it
>> out of date.
>>
>> 2] forced config screen - after the two obnoxious nag messages, one is
>> forced to be confronted with the xscreensaver customization screen
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
> 
> It's a time bomb by xscreensaver's upstream author.  And like micq before,
> it looks like xscreensaver needs to be replaced or forked.  Obviously, using
> gnome-screensaver is not an option as that pulls in a good part of Gnome3
> including systemd.
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] xscreensaver issues (including hardcoded DEBIAN!)

[Boruch Baum]

On 04/01/2016 02:31 PM, Adam Borowski wrote:
> On Fri, Apr 01, 2016 at 12:58:23PM -0400, Boruch Baum wrote:
>> Just looking at issues with the devuan default desktop's screensave, and
>> its config file:  ~/.xscreensaver file, posted here for the attention of
>> the maintainers and the interest of members of the list.
>>
>> 1] Obnoxious nag messages - All logins to the devuan default desktop
>> begin with not one but two separate nag messages from xscreensaver. The
>> first "warns" the user that the version is out of date. The second
>> "warns" the user that the sysadmin is doing a dis-service by keeping it
>> out of date.
>>
>> 2] forced config screen - after the two obnoxious nag messages, one is
>> forced to be confronted with the xscreensaver customization screen
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
> 
> It's a time bomb by xscreensaver's upstream author.  And like micq before,
> it looks like xscreensaver needs to be replaced or forked.  Obviously, using
> gnome-screensaver is not an option as that pulls in a good part of Gnome3
> including systemd.
> 

I'm not one to jump to that kind of conclusion before looking at some
alternatives first. It's possible that the solution has already been
provided by the author - I haven't checked the packages MAKEFILE for
possible build-time config options, or other compile-time options.
Lacking that, its also possible and may be appropriate to use debian's
'quilt' system to patch the upstream. It's also possible that just
contacting the author and making a request will effect a change.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] xscreensaver issues (including hardcoded DEBIAN!)

[Boruch Baum]

Just looking at issues with the devuan default desktop's screensave, and
its config file:  ~/.xscreensaver file, posted here for the attention of
the maintainers and the interest of members of the list.

1] Obnoxious nag messages - All logins to the devuan default desktop
begin with not one but two separate nag messages from xscreensaver. The
first "warns" the user that the version is out of date. The second
"warns" the user that the sysadmin is doing a dis-service by keeping it
out of date.

2] forced config screen - after the two obnoxious nag messages, one is
forced to be confronted with the xscreensaver customization screen

3] hard-coded debian url - this was hilarious to find. In the
xscreensaver customization screen, the default option for "text
manipulation" is a URL to an rss feed at planet debian. This default
turned out to be hard-coded(!!) in THREE binaries that I found:
/usr/bin/xscreensaver, /usr/bin/xscreensaver-demo,
/usr/bin/xscreensaver-getimage.

3.1] Once the file ~/.xscreensaver is created, one can edit the url there.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Configuring slim gui greeter

[Boruch Baum]

Just looking through the /etc/slim.conf file, and I see a few things
other members of the list might be interested in, and the maintainers
may want to consider.

1] default path - does not need to include 'games' folders

2] suspend command - need not be commented out, but the correct command
in devuan seems to be /usr/sbin/pm-suspend


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd installed and running in default desktop

[Boruch Baum]

At this point, after some more testing and fiddling, my questions are:
1] why is systemd-shim necessary (see below, after original message)?
2] why is devuan installing xfce4-power-manager with its seemingly
unnecessary recommendation of systemd?


On 03/31/2016 03:52 PM, Boruch Baum wrote:
> Am I the only one who hasn't noticed this yet? What am I missing?
> 
> ( posted in parallel at:
> https://git.devuan.org/devuan-packages/sysvinit/issues/14 )
> 
> I installed the default devuan desktop package today, using the devuan
> installer, and on my first boot, instead of using the graphical
> installer, I proceeded to C-M-F1 for a command-line login. Upon logging
> in, I received a message:
> 
> error message: systemd-logind[3096]: failed to start user service:
> unknown unit: user@1000.service
> 
> When I later escalated to su, I received a similar error message.
> 
> ps -aux | grep systemd
> shows a root process for /lib/systemd/systemd-logind
> 
> The same command on any Manjaro/OpenRC flavor I use yields no systemd
> processes whatsoever.
> 
> dpkg -l |grep systemd
> systemd 215-17+deb8u3
> systemd-shim 9-1
> sysv-rc 2.88dsf-59.2+devuan2
> sysvinit-core 2.88dsf-59.2+devuan2
> sysviniit-utils 2.88dsf-59.2+devuan2
> 
> Again, comparing with Manjaro/OpenRC, the only package with even a
> passing reference to systemd is:
> 
> pacman -Q | grep systemd
> eudev-systemdcompat 228-1
> 
> sources.list
> deb-src http://us.mirror.devuan.org/merged/ jessie main non-free
> contrib
> deb http://security.debian.org/ jessie/updates main contrib non-free
> deb-src http://security.debian.org/ jessie/updates main contrib
> non-free
> # jessie-updates, previously known as 'volatile'
> deb http://us.mirror.devuan.org/merged/ jessie-updates main
> contrib non-free
> deb-src http://us.mirror.devuan.org/merged/ jessie-updates main
> contrib non-free
> # jessie-backports, previously on backports.debian.org
> deb http://us.mirror.devuan.org/merged/ jessie-backports main
> contrib non-free
> deb-src http://us.mirror.devuan.org/merged/ jessie-backports
> main contrib non-free
> 

Running:

# aptitude why systemd (result: xfce4-power-manager recommends systemd)

# apt-get remove xfce4-power-manager

# apt-get autoremove (removes not just systemd, but also systemd-shim
and its bunch of dependencies)

# apt-get --no-install-recommends install xfce4-power-manager

Upon laptop reboot, and gui login, the xfce4-power-manager functions to
the extent that it:

1] responds to the pressing the power button with it dialog, and that
dialog will successfully logout, suspend, shut sown, reboot.

1.1] However, hibernate did not seem to work. It flickered the screen,
and did a complete shutdown.

2] The xfce4 panel has a power manager widget. All of its functions
work. Hibernate is not offered there as an option.

3] 'xfce4-power-manager --customize' has options for responding to
laptop lid closure, which are not working (tested for options
'lock-screen' and 'suspend'. Running 'acpi_listen' shows that the lid
closure is being detected. Other acpi events are recognized and function
as expected, ie screen brightness.

Re-installing systemd-shim did not change any of this, so I'm curious
why at this point its needed. I uninstalled it a second time.



-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd installed and running in default desktop

[Boruch Baum]

Am I the only one who hasn't noticed this yet? What am I missing?

( posted in parallel at:
https://git.devuan.org/devuan-packages/sysvinit/issues/14 )

I installed the default devuan desktop package today, using the devuan
installer, and on my first boot, instead of using the graphical
installer, I proceeded to C-M-F1 for a command-line login. Upon logging
in, I received a message:

error message: systemd-logind[3096]: failed to start user service:
unknown unit: user@1000.service

When I later escalated to su, I received a similar error message.

ps -aux | grep systemd
shows a root process for /lib/systemd/systemd-logind

The same command on any Manjaro/OpenRC flavor I use yields no systemd
processes whatsoever.

dpkg -l |grep systemd
systemd 215-17+deb8u3
systemd-shim 9-1
sysv-rc 2.88dsf-59.2+devuan2
sysvinit-core 2.88dsf-59.2+devuan2
sysviniit-utils 2.88dsf-59.2+devuan2

Again, comparing with Manjaro/OpenRC, the only package with even a
passing reference to systemd is:

pacman -Q | grep systemd
eudev-systemdcompat 228-1

sources.list
deb-src http://us.mirror.devuan.org/merged/ jessie main non-free
contrib
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib
non-free
# jessie-updates, previously known as 'volatile'
deb http://us.mirror.devuan.org/merged/ jessie-updates main
contrib non-free
deb-src http://us.mirror.devuan.org/merged/ jessie-updates main
contrib non-free
# jessie-backports, previously on backports.debian.org
deb http://us.mirror.devuan.org/merged/ jessie-backports main
contrib non-free
deb-src http://us.mirror.devuan.org/merged/ jessie-backports
main contrib non-free

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan installer main menu access

[Boruch Baum]

On 03/29/2016 12:33 AM, Gregory Nowak wrote:
> On Mon, Mar 28, 2016 at 06:30:42PM -0400, Boruch Baum wrote:
>> 4.1] Was it a case of 'fat-fingerng'? I don't think so, but it's
>> asking a lot to attempt to re-create this because with slow
>> bandwidth, each install attempt takes a long time to get to this
>> stage. Today's connection was especially slow. This has been the
>> only time and point in the install process that I've had a problem
>> returning to the main menu, so it might have been an errant
>> keystroke, but I think I was being careful.
> 
> You had previously indicated you have other debian/devuan boxes on
> your network.
Did not. Don't.

> Is there any reason why you can't install apt-cacher-ng on one of
> them?
See above.

> You could then experiment with as many install attempts as you
> want without having to download the same packages all over again.
What I did write in the past, in response to Adam Borowski's identical
suggestion, was that its asking a lot of a potential contributor to
require multiple machines, a network, and the additional software, for
something that could easily have been solved by either: 1] not being
stingy on the initial download, ie. offering a full iso instead of a
netboot, or 2] having the netboot installer also refer to a local cache.
Also, how many other linux distributions make that kind of request?

I'll mention one solution I didn't offer before because its performance
might not be as fast - use the extra space on the install medium. -IF-
the install medium is a new-ish USB stick, then it likely has a capacity
of 8/16/32 GB, and if the target is USB3-equipped, then the transfer
speeds should be good. The installer already sets up a small writable
FIRMWARE partition on the install media, so this additional suggestion
would be to not let the rest of the install media go to waste - use it
as a local cache.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] devuan installer main menu access

[Boruch Baum]

Short version: From the screen that lets the user select specific system
components to install, eg. XFCE, print server, SSH server, when I tabbed
to the selection "go back" with the intention of getting the main menu,
what happened instead was the installer began downloading "1173
packages". The only way I could figure to stop was to M-C-del, producing
a SIGTERM which rebooted.

Expanded version:

1] As a follow-up to a comment I made last week about saving downloaded
components for future installs (saving bandwidth/time), I've been
experimenting with how a user could re-use components using the ash
shell that's available with the net installer.

2] The first set of downloads, for the installer's own components, seem
to be deleted immediately upon their install. I was not able to retrieve
them for re-use from ash. FAILURE

3] The second set of downloads, for the linux base system, may have been
left on the target, but in advance of that download step, the debian
install commands with which I am familiar were not available. I had
archived deb files available to the installer and to the target, but got
stuck at trying to perform something like 'apt-get update' to let the
installer know they were there. FAILURE

4] The third set of downloads, for the additional system components,
should have been the easy lift. What I did was deselect the options for
a desktop and for a print server, expecting the system to want to
download ~273 files, as it did on prior tests. At that point, I tried
doing what I had no problem doing for the prior two stages - return to
the main install menu, and open up a shell. I tabbed to 'go back',
pressed 'enter', but the installer began downloading packages instead of
presenting the main menu, and indicated that it would download 1173
packages instead of 273.

4.1] Was it a case of 'fat-fingerng'? I don't think so, but it's asking
a lot to attempt to re-create this because with slow bandwidth, each
install attempt takes a long time to get to this stage. Today's
connection was especially slow. This has been the only time and point in
the install process that I've had a problem returning to the main menu,
so it might have been an errant keystroke, but I think I was being careful.

4.2] It would be nice to have had a less destructive method of aborting
the download than to reboot.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Boruch Baum]

Why on this list, of all the possible places in Creation? It's a great
and important topic, but have you found no other, more appropriate forum?

On 03/28/2016 02:50 AM, Edward Bartolo wrote:
> Hi,
> 
> As the title of the email indicates, I am doing some exercises to make
> sense out of C pointer syntax. I have been using pointers for as long
> as I have been programming without issues, apart from the usual
> initial programmatic errors when new code is run for the first time.
> However, C pointer syntax is proving to be as unintuitive as it can
> be. For this reason, I am doing some exercises regarding C pointer
> use.
> 
> I am attaching two short C programs that I created and which I tested
> to work although the mechanism by which they work is still somewhat
> hazy to me. Both programs use a function to change the value of a
> parameter. I want to understand, as opposed to knowing by rote, the
> mechanism why they work. Please note that I didn't consult any books
> to create the pointers. This is because I have already the concepts,
> but I cannot make sense, as in deeply understanding the details, of
> pointer syntax as used in C.
> 
> Edward
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] installer messes up swap partition on multi-boot

[Boruch Baum]

On 03/23/2016 01:01 AM, Go Linux wrote:
> On Tue, 3/22/16, Daniel Reurich  wrote:
> 
>> 
>> Given that suspend2disk uses the swap volume I'd recommend never 
>> using the same swap space for different linux systems anyway in a 
>> multi-boot setup.
>> 
> 
> 
> 
> Now I'm confused.  I thought that suspend used RAM and hibernate used
> swap. Oh wait . . .  suspend2disk isn't even in the devuan repos. Now
> I'm really confused.  Aside from that, I have shared swap partitions
> in the past.  I had no idea that was a nono.


> Learn something new everyday (if you're lucky).
Don't 'learn' anything just yet from what Daniel initially wrote. I (or
someone quicker than me) need to see and report back the condition under
which a boot performs a resume from suspend. Otherwise, what would be
the use-case of OS#2 resuming using a swap partition loaded with data
from OS#1's suspend?

> 
> golinux
> 
> 
> ___ Dng mailing list 
> Dng@lists.dyne.org 
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] installer messes up swap partition on multi-boot

[Boruch Baum]

On 03/23/2016 12:19 AM, Daniel Reurich wrote:
> Hi Boruch,
Good morning!

> 
> On 22/03/16 09:29, Boruch Baum wrote:
>> On today's install device, I had a pre-existing linux with a swap 
>> partition on the disk, and the partitioner insisted on
>> re-formatting it.
> 
> 
>> This is BAD. It changes the UUID of the swap partition, which
>> messes up the other operating systems on the device, because the
>> recent 'best practice' has been to identify partitions in fstab by
>> UUID.
> 
> Did it really? Good - so it should!! If you selected using that
> existing swap volume, I think that it's a reasonable default for it
> to format it. Same goes for any other volume except /home.  If you
> had reason to not want it formated then you should have to mark it to
> not be formatted.
That's not what happened, and I see there was room in what I wrote to be
misunderstood. I did NOT select the swap partition in any way; it was
auto-detected by the installer. Also, I did try to ask the installer to
not format the partition, but there was no such option. My memory is
that there was a column on the installer screen with the letter 'F' or
'f' that seemed to indicate that the partition was to be formatted, but
that it was immutable. When selecting the partition, my memory is that
likewise the option was not available.

Since I've read recently a few posts on the list about the option of
running an 'expert' install, I'll add that I was NOT using that install
method.
> 
> This protects you from situations where you do a new install
> re-using the existing partition/volume layout and an ensures that any
> old suspend2disk data in the swap is wiped out preventing a
> corruption resulting from the next reboot from trying to restore from
> the stale suspend image.
I don't follow your logic on this, so please elaborate. My understanding
is that contents of swap can be used to restore from suspend --- when
restoring from suspend! In what situation would a re-boot try to restore
a suspend state? Let's say that one powered off from suspend - would a
re-boot perform a restore? I can't test this right now because my devuan
evaluation was installed without any desktop and doesn't have a suspend
feature.
> 
> I'm sure that the installer only would do this if you chose to set
> that partition up as swap in the first place.
Daniel, when you start saying "I'm sure ... would" you're not
engendering confidence, you're indicating that you have no idea, but
you're willing to recklessly guess, against a user's report to the
contrary. Did you check the facts before writing?

I just now went to my devuan evaluation machine and rebooted using the
install media, trying both 'expert' and regular install.

1] The only difference I see between the two install modes is that the
'expert' mode initially presents the installer's main menu, and the
non-expert mode hides the main menu until later in the install process.

2] Neither the 'expert' or the non-expert install mode had an obvious
menu entry point for the installer's partition configuration function.

2.1] As a general matter, that's undesirable, so I'd like to report that
now, and request that the installer have that as a menu item. More
immediately, its unfortunate, because it makes it difficult to
double-check the partitioner at this point.

2.2] It seems like the only way to run the installer's partitioner is to
connect to the network! I'm not interested now in opening a shell and
running fdisk or whatever, I'm interested in quickly triple-checking my
previous reports, of what the installer's partitioning front-end is
offering when auto-detecting a swap parition. I'd like to also take this
opportunity to request that the installer not require a network
connection in order to run the partitioner.

> Given that suspend2disk uses the swap volume I'd recommend never
> using the same swap space for different linux systems anyway in a
> multi-boot setup.
That's very desktop-centric advice for what's supposed to be a
"universal operating system". It also presumes the system has
suspend2disk. It also presumes (I think incorrectly) that a reboot or a
cold boot would even try to restore from suspend.

I would really like to have experimented with suspend/power-off/reboot
before writing this post, but the only devuan system I have running was
installed without a desktop or a suspend feature, and I'm in the middle
of another experiment that will last a few days, and my other desktop
on-hand isn't devuan and has too much in-progress to risk a failed
resume from suspend.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan grub files

[Boruch Baum]

Oh, I Just remembered something else! When navigating the installer boot
menu, every time one changes a menu level, say from "advanced options"
back to the main menu, the installer issues a loud audible beep. This
audible bell is also sounded when the boot menu first loads. I'd suggest
removing that, as an annoyance.


On 03/22/2016 06:04 AM, Jaromil wrote:
> On Mon, 21 Mar 2016, Boruch Baum wrote:
> 
>> On that note, I'll chime in and say that I hate the red greeter
>> screen of the installer.
> 
> CenturionDan also reported that the theme is causing problems to the
> cd-installer so we'll likely drop it for a good old text terminal.
> 
> thanks for your insights
Happy/Hope to be of some help.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] On the wisdom on netboot installer images

[Boruch Baum]

On 03/21/2016 09:50 PM, Adam Borowski wrote:
> On Mon, Mar 21, 2016 at 05:19:33PM -0400, Boruch Baum wrote:
>> 1] For a day-to-day changing alpha release it makes plenty of sense to
>> keep the initial download as small as possible, since so much is
>> expected to change as part of the development process.
>>
>> 2] OTOH, a developer wants to encourage people to test the install and
>> the release often, so it makes sense to have an initial iso download
>> packed with the stable and large software packages that aren't central
>> to the what the distribution is innovating. Any time a user runs a
>> second test, she incurs a bandwidth burden of an entire new install.
>>
>> 3] One complicated solution would be to not destroy
>> /var/cache/apt/archive on the target when re-installing. It could be
>> done by having the installer suggest to mount that folder on its own
>> partition, and then have the installer refer to it at the download stage.
> 
> Trusting /var/cache/apt/archive on the target would risk way too many modes
> of breakage, let's not go there.
> 
> If you're doing frequent installs, you'd better install apt-cacher-ng (or
> one of its competitors) on a box on the local network, and use that whenever
> asked for a mirror.
> 
> The apt source will then be:
>   deb http://$YOUR_CACHE_BOX:3142/ftp.$COUNTRY.debian.org/debian/
> or
>   deb http://$YOUR_CACHE_BOX:3142/packages.devuan.org/merged
> 
> This way you download any package, binary or source, at most once.
> 

Good. But the point was to have that function folded into the installer,
with a fallback for a network download, in a manner simple for the
largest group of testers to use. Your suggestion seems to me in practice
to require of the user many more manual steps before, during, and after
each install. I've never used the technique, but you seem to also be
saying that it requires extra hardware, in the form of a local network
and a second box to host apt-cacher-ng.

Come to think of it, I challenge your starting point contention: "would
risk way too many modes of breakage", so let's do go there, if only for
a bit. What are all those "too many modes" and how bad are the risks?
What's the worst downside, worse than a failed keysign check?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] On the wisdom on netboot installer images

[Boruch Baum]

On 03/21/2016 09:02 PM, Hendrik Boom wrote:
> On Mon, Mar 21, 2016 at 05:19:33PM -0400, Boruch Baum wrote:
>>
>> 3] One complicated solution would be to not destroy
>> /var/cache/apt/archive on the target when re-installing. It could be
>> done by having the installer suggest to mount that folder on its own
>> partition, and then have the installer refer to it at the download stage.
> 
> You'd have to be able to check that the /var/cache was for the same 
> distro as the one you were testing.
Technically, that's right. In practice, I would suggest that it's
reasonable to put some responsibility on the shoulders of the user who
elects this option. At first, devuan would be the innovator, so there
would be no other distro with a reality of a /var/cache/apt/archive
mount point partition. If the idea makes sense and would get adopted by
other distros, it would only become an issue among families of linuxes
that use the same package extensions (eg deb, rpm). For a user who would
opt for a common partition for archiving packages from installs of
multiple distributions of the same extension, if the filenames were
identical, their key-signing would also need to match. Were the
keysigning to fail on an archived version of a package, ? (I don't know
how apt-get responds - does it recover by downloading a new copy? does
it force a sysadmin to manually rm the offender?)

So my guess is that the trouble would only arise when:
1] multiple distros use the technique
2] user is testing those multiple distros simultaneously
3] user uses the same partition for the mount points
4] they are the same package management familly (deb/rpm/etc)
5] the distros don't check the package keysig, or something 'bad' and
unrecoverable happens when they fail to match

Your point is prudent and in-place, that if devuan wanted to adopt the
technique, it should pro-actively have some fail-safe measure. What
comes to mind initially would be a label file, identifying to future
installs the identity of the previous one. Any distro adopting the
technique would be expected to check for the identity file, and reject
the mount point if it wasn't its own. The identiy file could be a simple
agreed-upon file name with a short text desciption of the distro that
put it there. Maybe allow it in the form foo.bar where foo is the
extension used by the package manager for the distro and bar is the
agreed upon name, so that distros of different package families could
co-exist in the same folder. Thus there could be files
rpm.identity_filename_standard and deb.rpm.identity_filename_standard in
the same folder, along with however many debs and rpms. That's a bit
blue-sky and edge-case, but worth spec-ing out as an option.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Devuan grub files

[Boruch Baum]

The devuan grub package contains debian-ized files:

1] /etc/grub.d/05_debian_theme

This file could be renamed devuan_theme, but some of the current content
would need to be changed or removed. It currently includes a case
statement for "Tanglu|Ubuntu|Kubuntu", which isn't necessary, and the
remaining case statement should be changed to whatever color theme
devuan decides upon.

On that note, I'll chime in and say that I hate the red greeter screen
of the installer.

Further down in the same file is a list of debian-specific background
images, for devuan to remove or replace

2] /etc/default/grub

There is a line in the file beginning 'GRUB_DISTRIBUTOR=', for which you
may want to replace '|| echo Debian' with '|| echo Devuan'


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] On the wisdom on netboot installer images

[Boruch Baum]

On 03/21/2016 06:19 PM, Rainer Weikusat wrote:
> Boruch Baum <boruch_b...@gmx.com> writes:
>> 1] For a day-to-day changing alpha release it makes plenty of sense to
>> keep the initial download as small as possible, since so much is
>> expected to change as part of the development process.
>>
>> 2] OTOH, a developer wants to encourage people to test the install and
>> the release often, so it makes sense to have an initial iso download
>> packed with the stable and large software packages that aren't central
>> to the what the distribution is innovating. Any time a user runs a
>> second test, she incurs a bandwidth burden of an entire new install.
> 
> Your idea of "wisdom" is a bit out-of-sync lopsided: I've been doing
> Debian installs based on 'netboot' images for a long time because that's
> just a lot easier and more comfortable to do: There's an 'initial
> download' of enough of the system to install more software and a user
> can then add more packages as needed 'on the go', without having to
> download a huge file containing mostly "stuff which won't be needed"
> (and without someone having to server this huge file to me).
> 
> There's also no need to download this "huge file" at all just to test
> 'installation'. It's perfectly possible to exit the Debian installation
> procedure after the base system has been set up and before any other
> software has been installed.

Of course you're right, for one half of what I was discussing. But you
do want people to be testing not just the install, but also the release,
don't you? That WILL require downloading an entire release in order to
check that the userland and desktop components interact properly, and
all the GUI theming operates as desired, and that all the defaults are
sensible. That's why I mentioned above that "2] OTOH, a developer wants
to encourage people to test the install and the RELEASE often".

The main point of my post was the paragraph you deleted.

> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] installer suggests wrong conclusion in network connect failure

[Boruch Baum]

This is another documentation issue in the text of the installer, this
time the message returned upon failure to connect to the network. The
message (in my case erroneously) jumps to the conclusion that the
network 'probably isn't using DHCP'. That's bound to confuse people most
prone to confusion - the less-experienced users.

I have no idea why the connection attempt failed the first two times I
tried. I just went all stubborn on the installer and repeated until it
gave up complaining and negotiated the connection.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Installer choices of timezone

[Boruch Baum]

I installed devuan today while in the USA, and was properly prompted for
a selection of USA timezones. That starts out as a good feature, as many
other installers just offer all timezones. However, the devuan subset
wasn't labeled in conformance with the names of the IANA tzdata
database[1], which has me suspicious there might maybe possibly be a bug
in how the timezones are being set.

[1] https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Installer 'Firmware' partition

[Boruch Baum]

On 03/21/2016 05:04 PM, Go Linux wrote:
> On Mon, 3/21/16, Boruch Baum <boruch_b...@gmx.com> wrote:
> 
>  Subject: [DNG] Installer 'Firmware' partition
>  To: dng@lists.dyne.org
>  Date: Monday, March 21, 2016, 3:51 PM
> 
>>  
>> This is another nice touch in the installer, and its a shame that its
>> insufficiently documented, so I'd like to suggest that some text be
>> added to an installer window to let users know.
>>
> 
> 
> 
> Perhaps you'd like to write up some documentation to better guide users on 
> their quest to install Devuan?
> 
> golinux
There's substance to your comment, so here goes:

"Your install media has been pre-configured with a writable
partition labeled 'Firmware' which you may use to load the firmware
file. You may now remove the media. From another computer, search for
the debian package containing file ---, download its SOURCE package,
file name suffix tar.gz, extract the archive, copy the file to the
'Firmware' partitiion, return to this machine, and plug the install
media back in."

I didn't see a need to do so in my original post, golinux, as OTOH its
the kind of 'effort' that takes all of a few minutes, but OTOH, when
suggested in the wrong forum, could lead to a needless and interminable
discussion, and this list is already prone to so much not directed at
getting the distribution final.

> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] installer messes up swap partition on multi-boot

[Boruch Baum]

Bad suggestion, Adam. I don't know that the debian installer acts that
way. The issue is that the devuan installer is deciding on its own to
re-format an existing swap partition.

On 03/21/2016 05:17 PM, Adam Borowski wrote:
> On Mon, Mar 21, 2016 at 04:29:47PM -0400, Boruch Baum wrote:
>> On today's install device, I had a pre-existing linux with a swap
>> partition on the disk, and the partitioner insisted on re-formatting it.
>> This is BAD. It changes the UUID of the swap partition, which messes up
>> the other operating systems on the device, because the recent 'best
>> practice' has been to identify partitions in fstab by UUID.
>>
>> It significantly slows the boot of those other linuxes, and they lose
>> their swap, and the sysadmin has to manually fix the fstab.
> 
> As your problem is not specific in any way to Devuan, I suggest reporting it
> upstream, ie, in Debian.
> 


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] On the wisdom on netboot installer images

[Boruch Baum]

1] For a day-to-day changing alpha release it makes plenty of sense to
keep the initial download as small as possible, since so much is
expected to change as part of the development process.

2] OTOH, a developer wants to encourage people to test the install and
the release often, so it makes sense to have an initial iso download
packed with the stable and large software packages that aren't central
to the what the distribution is innovating. Any time a user runs a
second test, she incurs a bandwidth burden of an entire new install.

3] One complicated solution would be to not destroy
/var/cache/apt/archive on the target when re-installing. It could be
done by having the installer suggest to mount that folder on its own
partition, and then have the installer refer to it at the download stage.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] installer suggests "debian" mirrors

[Boruch Baum]

This is just a typo in the installer, but the kind of typo that would
make users and cynics snicker: the mirror selection remark says
'usually ftp...debian.org is a good choice'. I reported this also in the
alph2 installer a few months back.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Installer 'Firmware' partition

[Boruch Baum]

This is another nice touch in the installer, and its a shame that its
insufficiently documented, so I'd like to suggest that some text be
added to an installer window to let users know.

When the installer performs 'detect network hardware' and detects
non-free firmware, it goes the extra mile and gives the user a specific
file name to obtain. What is a shame is that it leaves out:

1] The install media itself came pre-configured with a writable
partition (sdb2) labeled 'Firmware', for uh . . .

2] The installer is 'cool' with the user just pulling out that usb stick
and returning it later.

It's a shame to have a nice feature, and then hide it!

Also, once the installer is already doing the great job of listing a
specific filename for the required firmware, would it hurt to tell the
user how to get it?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] installer debug logs

[Boruch Baum]

I thought this was a very nice touch, to have in the installer, so I
tried it!

Time to quibble:

1] The feature lacks instructions, which would be an obstacle for it to
be performed by those who probably would most want to perform it - the
least experienced users.

2] I was expecting the obvious option, and was surprised it wasn't
offered. For me, the most obvious option would be to offer to
save the logs to the install media's FIRMWARE parition, which
had earlier been mounted in order to install the non-free firmware.

3] Currently, in order to use the feature, the installer silently tells
the user to open up an ash shell:
+ mount # looks like the 'Firmware' partition no longer mounted
+ ls -l /dev/disk/by-label # identify 'Firmware' partition
+ mkdir /mnt/Firmware  # mountpoint on ramdisk
+ mnt /mnt/Firmware /dev/sda2 # YMMV
+ return to the installer and save the debug logs to /mnt/Firmware

4] minor bug: the progress bar for 'save debug log' does not
disappear after continuing to other menu options (eg. execute a
shell).

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] installer messes up swap partition on multi-boot

[Boruch Baum]

On today's install device, I had a pre-existing linux with a swap
partition on the disk, and the partitioner insisted on re-formatting it.
This is BAD. It changes the UUID of the swap partition, which messes up
the other operating systems on the device, because the recent 'best
practice' has been to identify partitions in fstab by UUID.

It significantly slows the boot of those other linuxes, and they lose
their swap, and the sysadmin has to manually fix the fstab.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] minor packaging quibbles in devuan cli

[Boruch Baum]

Two minor annoyance issues, and one curiosity, in today's install of
devuan-cli:

1] sudo is not installed by default

2] Even though the installer asked me my brand of English, it installed
a second spelling dictionary, 'ibritish'.

3] Why are both gcc-4.8 and 4.9 installed?

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] surprising packages in devuan cli install

[Boruch Baum]

I just installed devuan, without a desktop, yet I ended up with over 35
packages installed that are X11 related. After some tracing, I see that
this is the same issue that I reported a few months ago: the default
install for a no-X devuan in choosing package 'pinentry-gtk2' instead of
'pinentry-curses'.

# apt-get install pinentry-curses
# apt-get purge pinentry-gtk2
# apt-get autoremove

Apt-getremoves 37 packages!

HOWEVER, maybe the reason it hasn't been changed these past months is
because I've overlooked something, and no one chose to get back to me.


-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Sending mail to <onel...@devuan.org>

[Boruch Baum]

Has anyone experience sending e-mail to the listed contact e-mail for
the project ? I just tried, and got bounced by a
purported "SPF: mechanism" error:

BEGIN ===
corellia.eurodns.com rejected a message that claimed an envelope sender
address of boruch_b...@gmx.com.

corellia.eurodns.com received a message from tupac2.dyne.org
(178.62.188.7) that claimed an envelope sender address of
boruch_b...@gmx.com.

However, the domain gmx.com has declared using SPF that it does not send
mail through tupac2.dyne.org (178.62.188.7). That is why the message was
rejected.
END =

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng