Re: [DNG] Devuan cannot exist without the help of Debian

[Irrwahn]

Arnt Karlsen wrote on 22.11.19 13:36:
> On Fri, 22 Nov 2019 10:55:46 +0100, Denis wrote in message 
> <20191122095546.fro7htitriq47xsx@reflex>:
[...]
>> And today once again I support the vote proposition nr.4 by Ian
>> Jackson
> 
> ..a direct link to Ian's vote proposition nr.4 and a direct link 
> on where to vote for that, would be helpful, there are 245 messages 
> "in the air" at https://lists.debian.org/debian-vote/2019/11/ now.

All proposals can be found here: https://www.debian.org/vote/2019/vote_002

Ian Jackson's proposal is listed as "Proposal D".

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)

[Irrwahn]

Hendrik Boom wrote on 12.06.19 14:40:
> On Wed, Jun 12, 2019 at 01:47:42PM +0200, Irrwahn wrote:
> 
>>
>> There is nothing wrong here. Gcc reports the size that is necessary to 
>> store an object of type sesqui_int, including any padding that has been
>> applied, e.g. for alignment reasons. An array of n elements of that type 
>> will in turn always be reported by sizeof as having *exactly* n times 
>> that size, in bytes. Gcc is therefore in accordance with the language 
>> definition. 
> 
> More precisely, sizeof(foo) is the spacing of consecutive elements of type 
> foo.
> 
> -- hendrik

Thank you Hendrik, that is indeed very aptly phrased! 

Just for the sake of completeness, the actual language definition 
takes the usual wordy but precise approach in Standardese:

 ISO/IEC 9899:2011 
 | 6.5.3.4 The sizeof and _Alignof operators
 | [...]
 | 2 The sizeof operator yields the size (in bytes) of its operand, 
 | which may be an expression or the parenthesized name of a type. 
 | The size is determined from the type of the operand. The result 
 | is an integer. If the type of the operand is a variable length 
 | array type, the operand is evaluated; otherwise, the operand is 
 | not evaluated and the result is an integer constant.
 | [...]
 | 4 When sizeof is applied to an operand that has type char, unsigned 
 | char, or signed char, (or a qualified version thereof) the result 
 | is 1. When applied to an operand that has array type, the result is 
 | the total number of bytes in the array. When applied to an operand 
 | that has structure or union type, the result is the total number of 
 | bytes in such an object, including internal and trailing padding.


Best regards

Urban

-- 
Sapere aude!



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

Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)

[Irrwahn]

Didier Kryn wrote on 12.06.19 12:15:
[...]

Hi Didier,

please allow me to clear up some apparent misconceptions below.

> 
>      What I meant in this discussion is that sizeof() allows to 
> calculate the number of elements of an array, because we make 
> assumptions on data layout, but this is an artefact and I don't think it 
> is specified by the language wether the result is exact or not.
> 
>      Let's consider the following type:
> 
> typedef struct {int i; short h} sesqui_int;
> 
>      One would naively consider that sizeof(sesqui_int) is equal to 6. 
> But, with gcc, the value is 8, which looses 2 bytes in which it could 
> store a short or two chars. This is because this struct must be aligned 
> on a 4-byte boundary and, if you make an array of these, 
> sizeof(sesqui_int)*number_of_elements must give the size of the array. 
> Gcc has chosen to return a wrong sizeof() for the sake of preserving a 
> naive size arithmetic.

There is nothing wrong here. Gcc reports the size that is necessary to 
store an object of type sesqui_int, including any padding that has been
applied, e.g. for alignment reasons. An array of n elements of that type 
will in turn always be reported by sizeof as having *exactly* n times 
that size, in bytes. Gcc is therefore in accordance with the language 
definition. 

I assume the misunderstanding here was that sizeof should report the 
minimal size an object would occupy in the absence of any alignment
requirements etc. imposed by the actual platform. This is not what sizeof 
is designed to do. Instead it shall report the *actual* amount of memory 
required to store such an object. If you expected something else you 
already made unwarranted assumptions about implementation details that 
should not matter to you as the programmer.

> 
>      Another implementation of the C language might decide to add 
> headers to arrays, in which it would store the size to perform strict 
> runtime checks. In this case the size of an array would be larger than 
> the sum of the sizes of its elements.

No, it must not. This is prohibited by the definitions and constraints 
in the C standard. The introduction of array headers would for example 
lead to  
  (void *) == (void *)[0]
not always being true, which would contradict the language definition. 
In other words, your hypothetical implementation would implement some 
language that is not C, by definition. 

On a somewhat related note: Any padding present in a struct can never 
appear at the start of that struct, i. e. the address of an object of 
structural type is guaranteed to always compare equal to the address 
of its first member.

> 
>      Therefore this use of sizeof(), even though widespread, remains a 
> trick.

Not so.  Num_array_elements = sizeof array / sizeof element is neither 
a trick nor an accident, but rather idiomatic C . It is guaranteed by 
the C standard (any version) to yield the correct element count. 
Predicting the behavior of any non-trivial C program would be a crap 
shot otherwise. Moreover, it would make impossible to reliably allocate 
dynamic memory for arrays, consider the well-known (and correct) idiom:

  some_type *arr = malloc(num_elements * sizeof *p);


And while we're at it, please let me add some random interesting facts 
about the sizeof operator one should be aware of: 

* Being the operand of the sizeof operator is one of the few cases 
  where an array designator does not decay into a pointer to its first 
  element, and a non-array lvalue is not converted to the value stored 
  in the designated object; e.g. the *p in the example above does _not_
  dereference p. (All of this is a fancy way of saying that sizeof 
  looks strictly only at the type of its operand, not its value).

* Since C99 there is one important exception to the rule that the 
  sizeof operator is evaluated at translation time, and that is when 
  applied to VLAs (variable length arrays) - for obvious reasons.

* The parentheses around the operand of sizeof are only mandatory, if
  said operand is a type name. For ordinary object designators (lvalues)
  they arguably add unnecessary clutter and may mislead novices into 
  the false belief that sizeof is a function, which it is not.


I hope that helped clear things up a bit. 


Best regards,

Urban
-- 
Sapere aude!



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

Re: [DNG] Update on the Green Hat Hackers attack

[Irrwahn]

KatolaZ wrote on 01.04.19 09:03:
> Dear D1rs,
> 
> we have analysed in depth the attack from the "Green Hat Hackers" that
> compromised the Devuan infrastructure in the last hours, and we
> concluded that you all are:
> 
>* APRIL FOOLS *
> 
> :P

D'oh!

A prank well executed from a purely technical POV, kudos for that. However 
IMO in quite bad taste given anything even remotely security related when 
talking OS distributions is quite a touchy subject. 

At the very least you had me with my finger already on the kill switch for 
one of the packet mirrors, for a short while. Not sure it was worth it.

> Hope you enjoyed the new Devuan gopherholes, as they are most probably
> going to stay. 

Now, this is the one part of the joke I can wholeheartedly appreciate. ;-)

[...]> if you are wondering, unfortunately 1554123859 is not a prime number :\

MFW I was literally only a few keystrokes away of actually checking. -.-

[...]
> Never forget to Live, Love, Linux, and have a good Laugh!
> 
> LLoLL

Evil me let off a diabolical chuckle, does that count?  }:->

Reasonable me, however, would like to kindly suggest you a choose less 
sinister scenario for potential future jokes on that scale. And please 
keep in mind that April fools jokes are popular only in some parts of 
so-called western culture, and not a concept readily recognized or 
accepted globally.

So yeah, please have a good laugh at your fellow Devuaners expense every 
once in a while, by all means. We all need to vent every now and then, 
especially those who work tirelessly to keep things rolling. Just be 
aware that this particular kind of joke might eventually backfire in 
unexpected ways.

Just my two nano-cents.

Cheers,
Urban
-- 
Sapere aude!



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

Re: [DNG] /usr to merge or not to merge... that is the question??

[Irrwahn]

g4sra wrote on 16.11.18 21:19:
> The concept of which is at fault anyway, if root file system network
> support no longer required the merge should go the other way in any
> case, it is /usr/{bin,sbin,lib} that is depreciated.
> 
> /usr/bin > /bin
> /usr/sbin > /sbin
> /usr/lib > /lib
> 
> with the exception of special cases which are frequently abused by
> distros but are not supposed to be a part of the standard OS and should
> stay under /usr.
> e.g.
> 
> /usr/local
> /usr/share

I once was on the same page, but have since changed my mind when I 
realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
actually to me makes more sense, as it keeps all the "static" files 
that are part of the distribution neatly in one place. The only other 
significant things left in / then are site specific configuration in 
/etc and, if not already placed in a dedicated file system, persistent 
variable data in /var.

This allows e.g. for things like rendering the entire "static" part 
of the system effectively immutable simply by mounting /usr read-only. 
(And yes, referring to other sub-threads, in that case one would 
indeed have to mount /usr by means of an initrd, which is neither 
brain science nor rocket surgery.)

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] initramfs?

[Irrwahn]

k...@aspodata.se wrote on 16.11.18 20:45:
> Urban:
[...]
>> Most, if not all, contemporary Linux based operating systems should be 
>> able to boot just fine without resorting to any kind of initramfs mechanism,
>> provided all the essential bits are located in the root-fs, and the kernel
>> has all the drivers necessary to access said root-fs compiled in.
> 
> You will have problems doing that when the boot fs is on a partition on 
> a md-raid partition and probably when the boot fs is somewhere on a lvm 
> thing. At least you'd have the problem of telling the kernel where the 
> root fs is that has dynamic device numbers and must be assembled or 
> something before the rootfs is available.
> 
> Booting from a md-raid with v0.90 metadata can be done though, since 
> theese can be autodetected by the kernel, and the same is valid for 
> nfs-booting; though the kernel devs. seems to view that as a hack and
> points to initrd as the solution.

You are correct. I oversimplified a bit, the reason being that scenarios 
like the one you just outlined won't be affected by /usr being merged 
or not, which is what the original subject of the thread was about.

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] /usr to merge or not to merge... that is the question??

[Irrwahn]

Steve Litt wrote on 16.11.18 18:35:
> On Fri, 16 Nov 2018 12:08:34 +0100
> Irrwahn  wrote:
> 
> 
>> And bringing anything related to systemd into the picture just
>> because its proponents also happen to support merged /usr is a red
>> herring.
> 
> That's   just   not   true.

Yes   it   is.  (Thanks for making me feel >40 years younger! :-)

If you are under the impression the merged /usr concept was invented 
by Redhat, or the freedesktop and/or the systemd people, you are 
demonstrably wrong.

On System V Release 4 and later /bin has already been a symlink to 
/usr/bin, and Solaris implemented the /usr merge about a decade ago.
Effectively, only some Unices and some Linux based distributions are 
the odd ones out in that respect.

> 
> We have a half a decade's history of seeing systemd stick its nose in
> the tent, and then keep pushing until the DIY human must leave the
> tent. I made very clear in my first post it's not a case of "just
> because its proponents also happen to support merged /usr". It's
> because eliminating /sbin (and also some others that Rick enumerated)
> forces use of an initramfs, and the systemd forces can easily acquire,
> monopolize and decompatablize the tools to create initramfs. After 5
> years systemd observation, this is not paranoia, this is an educated
> guess based on past behavior.

In my reply to your other post I explain why the notion of a merged /usr 
allegedly forcing the use of an iniramfs is a myth, I won't repeat it 
here for the sake of brevity. 

The part about "acquire, monopolize and decompatablize the tools to 
create initramfs" is ridiculous, as an initrd is nothing more than an 
(optionally compressed) cpio archive, loaded by the Linux kernel itself. 
Put some statically linked executable (e.g. a shell) inside, renamed to 
/sbin/init, and you have the most bare-bone of Linux systems imaginable, 
without even the need for a "real" root file system. (Where I used to work 
we regularly built entire embedded Linux systems that consisted of 
nothing more than a boot loader, a kernel and an initrd - go figure.)

Sorry, but no matter how educated, in this case your guess simply failed.

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] initramfs?

[Irrwahn]

Hendrik Boom wrote on 16.11.18 19:08:
> (1) Is initramfs so weird that only one or two people in the world can 
> make one?

No. 

And even though stock De(bi|vu)an installations by default use an 
initramfs (an intrd, to be precise): if you ever find yourself in a 
position where you have to _manually_ tweak it, chances are high that 
something much more fundamental is broken either in the distribution 
itself or on your particular box.

> (2) What is initramfs good for?  Linux used to work just fine without 
> it.

It's only needed if you have to do stuff before running the `real´ init 
process to bring up the system and all services. If, e.g., for some reason 
you decided to place stuff like kernel modules or other essential system 
components not in the root file system and therefore have to perform some 
special action and mounting before being able to bring up user space in 
its final form.

Most, if not all, contemporary Linux based operating systems should be 
able to boot just fine without resorting to any kind of initramfs mechanism,
provided all the essential bits are located in the root-fs, and the kernel
has all the drivers necessary to access said root-fs compiled in.

Regards,
Urban
-- 
Sapere aude!



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

Re: [DNG] /usr to merge or not to merge... that is the question??

[Irrwahn]

Steve Litt wrote on 16.11.18 11:11:
> On Fri, 16 Nov 2018 22:11:17 +1300
> Daniel Reurich  wrote:
[...]
>> So... for Devuan, do we want to default to a merged /usr in our coming
>> release of Beowulf or are we going to resist another pointless
>> rearranging of the deck chairs...
>>
>> Keen to get some feedback on this
> 
> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?

Steve, 

with all due respect, in think your reasoning suffers from some kind of
slight misconception: 

The file system hierarchy split between / and /usr happened because the
disk mounted at / on one particular machine was filling up. Neither was 
it a deliberate design decision, nor was it deemed elegant at the time 
(and still is not). It was nothing but a dirty makeshift botch to quickly 
compensate for some transient hardware constraint almost fifty years ago.
It has nothing to do with the practice of using an initramfs (or similar 
construct) for early user space system initialization.

In fact, if anything, a merged /usr obsoletes the need for an initramfs 
WRT mounting system partitions, as it is highly unlikely for /usr to 
reside on a separate volume when it is merged into the root hierarchy, 
where it belongs. If you dislike initramfs, you should go for a merged 
/usr tree to err on the safe side when it comes to ensure availability 
of essential system components during system initialization.

And bringing anything related to systemd into the picture just because 
its proponents also happen to support merged /usr is a red herring.

[Cut reasoning based on aforementioned misconception about the history 
of split /usr, and initramfs or systemd being relevant to the question 
at hand.]


Best regards,

Urban

-- 
Sapere aude!



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

Re: [DNG] /usr to merge or not to merge... that is the question??

[Irrwahn]

Daniel Reurich wrote on 16.11.18 10:11:
[...]
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
> 
> Keen to get some feedback on this
[...]

I cast my vote in favor of making merged /usr the default.

My reasoning behind this is as follows (disclaimer: rant mode = medium):

The practice of storing system files in a secondary hierarchy below
/usr was born out of disk space constraints on hardware that has been
obsoleted many, many decades ago. It is and has always been an ill
conceived kludge that somehow managed to cross the times and still be
present on some Unix-like operating systems.

The artificial separation of system files into the "essential" and
"non-essential" categories has always been a vague and arbitrary one,
and in the Debian case is botched since at least Wheezy, effectively
rendering the endeavor of making /usr a mount point for a separate disk
partition a nontrivial task (think initramfs).

The fact that split /usr has been abused to craft pathologic setups
like network mounted /usr volumes shared across multiple installations
is a moot point. This practice is demonstrably a recipe for disaster
when used for anything but fun experiments on non-critical toy
installations or as a demonstration piece on how to /not/ design a
reliable system.

Split /usr is an abomination that should have been put to rest long ago,
only to be referred to as quirky anecdote in some obscure footnote.
Merging /usr back is a small step on the long way to restore the FSH to
what it was meant to be.

(rant off)

TL;DR:
The Unix file system hierarchy is a mess. A merged /usr subtree brings
back a tiny little bit of sanity. Thus I vote for it to be the default
for new Devuan installations.

Best regards,
Urban


-- 
Sapere aude!



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

Re: [DNG] Plasma on Devuan Ceres

[Irrwahn]

Martin Steigerwald wrote on 02.11.18 22:31:
> Hi!

Hi Martin!

> I am considering to switch this main laptop from Debian Sid to Devuan 
> Ceres for quire some time already.
[...]
> So or so I am really keen to hear about how Plasma works on Ceres.
[...]

I didn't get around to testing Plasma on Ceres yet, but essentially it 
_should_ run on Ceres just as it does on ASCII, at least that's the 
goal. Except at the time of writing there are probably some quirks you 
should be aware of, see below.

> How about integration of Plasma with other stuff?
> 
> - NetworkManager:
[...]
I don't use it, cannot comment.

> - What about Pulseaudio? 
[...]
Should be the same as ASCII, i.e. libpulse0 depending on libsystemd0.

> - How about plugable devices like USB sticks? Are they automatically 
> detected in Plasma and ready to mount by click?

This touches on the probably most important area to pay attention to. 
Given the current(!) state of the repositories you will likely have to 
install some packages related to session management et. al. (policykit, 
elogind, udisks2, ...) from Devuan ASCII.  The experimental, unstable 
(Ceres) and testing (Beowulf) repositories are currently catching up 
to (re-)establish the intended package flow, which was bypassed towards  
the ASCII release to speed things up.

Note that things are moving swiftly these days, as the `wizards´ are 
pushing really hard to stabilize things beyond ASCII. (You guys rock!)

> Any other experiences about what does work and what does not work?
[...]

Sorry I can't be of more help, but maybe you got some pointers to what 
kind of quirks to be aware of, especially that /right now/ you may have 
to get some packages from current stable (ASCII) to get everything 
working.

Provided you still want to give it a go and not wait until the dust has 
settled it would be great if you could report back about how it went.

HTH, best regards
Urban

-- 
Sapere aude!



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

Re: [DNG] Please help with testing the new version of sysvinit

[Irrwahn]

KatolaZ wrote on 01.11.18 22:44:
> Dear d1rs,
> 
> TL;DR:
> ==
> 
> we need help in testing any regression with a new version of sysvinit
> (2.91-1+devuan1) that we have put in Devuan experimental
[...]

Casually toying around with it (including randomly shuffling services 
around some of the spare runlevels) in my ceres testbed revealed no 
immediately obvious bugs or regressions. Will keep it installed and 
include it in any further checks I'll do on ceres or beowulf.

Special thanks to all who engage in saving SysVinit from the danger of 
being dropped from Debian, excellent work! To make it a full success I
would assume it might prove necessary to sift through the Debian bug 
tracker for outstanding bugs filed against init scripts of individual 
daemon packages. I'll notify the debian-init-diversity list should I 
happen to stumble upon any such reports.

On a remotely related matter: 
In case one experiences excessive boot delays with 4.x kernels during 
startup of certain daemons (e.g. sshd, web server), particularly on 
headless machines or VM installations: Those may be caused by entropy 
starvation leading to blocked reads from /dev/random. This can be 
alleviated by installing a userland tool to fill the entropy pool, for 
example as provided by the 'haveged' package.

HTH, best regards
Urban
-- 
Sapere aude!



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

Re: [DNG] Please help with testing the new version of sysvinit

[Irrwahn]

KatolaZ wrote on 01.11.18 22:44:
[...]
> You just need to add Devuan experimental repos to your
> sources.list:
> 
>   http://pkgmaster.devuan.org/merged experimental main
> 
[...]

KatolaZ, 

above won't work for me, getting:

| http://pkgmaster.devuan.org/merged experimental Release [ERROR]
|  404  Not Found [IP: 5.196.38.18 80]

OTOH "http://pkgmaster.devuan.org/devuan experimental main" does work.

Is the experimental suite not merged deliberately, or is this an oversight?

Best regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] util-linux needs an upgrade on ceres

[Irrwahn]

KatolaZ wrote on 30.10.18 13:52:
> On Tue, Oct 30, 2018 at 09:28:04AM +0100, Irrwahn wrote:
[...]
>> So there clearly is some kind of inconsistency in present ceres which makes 
>> debootstrap reproducible go belly-up. 
>>
> 
> Hi Irrwhan,
> 
> you are right. Working on it. Update soon. Sorry for the inconvenience.
> 
[...]

Thanks a lot, KatolaZ! Glad I could help a bit. :)

Ceres is unstable after all, occasional breakage is to be expected.

HND
Urban


-- 
Sapere aude!



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

Re: [DNG] util-linux needs an upgrade on ceres

[Irrwahn]

KatolaZ wrote on 30.10.18 08:19:
> On Tue, Oct 30, 2018 at 08:10:37AM +0100, aitor_czr wrote:
[cut]
>> Building Ceres with the live-sdk, i've got the
>> following errors related with 'su' in the debootstrap.log file:
>>
>> tar: ./bin/su: Cannot open: File exists
>> tar: ./etc/pam.d/su: Cannot open: File exists
>> tar: ./usr/share/man/man1/su.1.gz: Cannot open: File exists
>>
[cut]> debootstrap on itself works fine and gives you ceres. 
[cut]


Hi KatolaZ, 

alas, it doesn't! I already hinted at that in my previous message buried 
deep in the thread with the inappropriate subject. As a minimal example 
suitable for easy reproduction, on

  $ uname -srv ; lsb_release -irc
  Linux 4.18.0-0.bpo.1-amd64 #1 SMP Debian 4.18.6-1~bpo9+1 (2018-09-13)
  Distributor ID:   Devuan
  Release:  2.0
  Codename: ascii

performing a simple

  $ sudo debootstrap --verbose ceres ./ceres  http://deb.devuan.org/merged

bails out while extracting util-linux_2.32.1-0.1+devuan1_amd64.deb, leaving 
the following lines in debootstrap.log:

  tar: ./bin/su: Cannot open: File exists
  tar: ./etc/pam.d/su: Cannot open: File exists
  tar: ./usr/share/man/man1/su.1.gz: Cannot open: File exists
  tar: Exiting with failure status due to previous errors

So there clearly is some kind of inconsistency in present ceres which makes 
debootstrap reproducible go belly-up. 

HTH, best regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] Speak now, or forever hold your peace

[Irrwahn]

KatolaZ wrote on 28.10.18 12:18:
> On Sun, Oct 28, 2018 at 12:05:11PM +0100, aitor_czr wrote:
>> Hi,
>>
>> On 10/27/2018 09:56 PM, Steve Litt wrote:
>>> I assume from your response that the util-linux issue is solved.
>> The live-sdk failed retreiving util-linux. I downloaded the sources, but
>> they didn't build succesfully at the first attempt.
>> I've just packaged it and now i'm going to build a repo with the customized
>> grub and the util-linux packages using amprolla, and try again with the
>> live-sdk.
>> Time to go for a walk :)
>>
> 
> Aitor, if you tried a couple of days ago, please consider tha
> util-linux was updated in ceres on Friday. Now
> debootstrapping/upgrading to ceres works again. 
> 

Hi KatolaZ,

not sure if it helps, but I had a few minutes to spare and tried to
debootstrap a ceres image using my own (in)famous wrapper script[1] 
using various mirrors. Debootstrap reproducible fails with error 
code 2 on the "Extracting util-linux..." step.

The debootstrap incantation of my latest attempt (in this particular
case using our own mirror, as I can reliably check it's rsync'd 
twice per hour from pkgmaster.d.o) reads:

sudo debootstrap --verbose --arch amd64 
--include=linux-image-amd64,grub-pc,firmware-linux-free,firmware-realtek,console-setup,console-setup-linux,locales,keyboard-configuration,busybox-static,live-boot,firmware-linux-nonfree,acpi-support,cron,dbus,rsyslog,netbase,net-tools,ntp,telnet,openssh-server,openssh-client
 --components=main,contrib,non-free --merged-usr ceres 
/home/urban/projects/irrvuan/mnt/minsys-ceres 
http://devuan.packet-gain.de/merged

Some relevant parts of the log (for full output see [2] below):

  I: Retrieving InRelease 
  I: Checking Release signature
  I: Valid Release signature (key id E032601B7CA10BC3EA53FA81BB23C00C61FC752C)
[... cut retrieval of lots of packages, and dependency resolution]
  I: Retrieving login 1:4.4-4.1
  I: Validating login 1:4.4-4.1
[...]
  I: Retrieving sysvinit-utils 2.88dsf-59.3+devuan2
  I: Validating sysvinit-utils 2.88dsf-59.3+devuan2
[...]
  I: Retrieving util-linux 2.32.1-0.1+devuan1
  I: Validating util-linux 2.32.1-0.1+devuan1
[...]
  I: Chosen extractor for .deb packages: dpkg-deb
[...]
  I: Extracting login...
[...]
  I: Extracting sysvinit-utils...
[...]
  I: Extracting util-linux...
  2018-10-28T13:17:41 * ERROR 2: debootstrap *

Unfortunately I could not find a way to make the debootstrap output even 
more verbose to get a better hint at what exactly makes it throw up.

However, on closer inspection using `dpkg-deb -e` I see that util-linux 
2.32.1-0.1+devuan1 has a "Breaks:" on "sysvinit-utils (<< 2.88dsf-59.4~)", 
but version 2.88dsf-59.3+devuan2 was retrieved. Moreover, it "Depends:" 
on "login (>= 1:4.5-1.1~)", but version 1:4.4-4.1 was retrieved.

I wonder if any of those might be part of the problem?

FWIW, the same overall process works flawlessly for ascii (as it did ever 
since), as well as for beowulf. Though for the latter I did not check if 
it results in a working system image, but at the very least it did not 
faceplant during the debootstrap step.


[OT]
Although I'm still following this list and on IRC on an almost daily basis, 
I'm unfortunately tight on resources to put into Devuan. It may take some
time for me to reply to any potential follow-ups. Still cheering for you 
from the side line though, y'all doing an incredibly fine job!
[/OT]

Hope that helped, best regards
Urban


[1] https://github.com/irrwahn/irrvuan

[2] Full debootstrap log:

2018-10-28T13:13:26 sudo debootstrap --verbose --arch amd64 
--include=linux-image-amd64,grub-pc,firmware-linux-free,firmware-realtek,console-setup,console-setup-linux,locales,keyboard-configuration,busybox-static,live-boot,firmware-linux-nonfree,acpi-support,cron,dbus,rsyslog,netbase,net-tools,ntp,telnet,openssh-server,openssh-client
 --components=main,contrib,non-free --merged-usr ceres 
/home/urban/projects/irrvuan/mnt/minsys-ceres 
http://devuan.packet-gain.de/merged
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id E032601B7CA10BC3EA53FA81BB23C00C61FC752C)
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: adduser debian-archive-keyring fdisk 
gcc-8-base gpgv init-system-helpers insserv libacl1 libapt-pkg5.0 libattr1 
libaudit1 libaudit-common libbz2-1.0 libc6 libcap-ng0 libcom-err2 libdb5.3 
libdebconfclient0 libext2fs2 libffi6 libgcc1 libgcrypt20 libgmp10 libgnutls30 
libgpg-error0 libhogweed4 libidn2-0 liblz4-1 liblzma5 libncursesw6 libnettle6 
libp11-kit0 libpam0g libpcre3 libseccomp2 libselinux1 libsemanage1 
libsemanage

Re: [DNG] systemd and ssh-server

[Irrwahn]

Steve Litt wrote on 26.07.2018 18:17:
> On Thu, 26 Jul 2018 13:17:21 +0200
> Irrwahn  wrote:
>> What's more, I'd
>> go even further and say I wouldn't mind at all if every daemon
>> package came with support for all init systems in current use
>> (rc-style sysv|openrc, runit, ... , systemd), as that would make
>> switching init systems in an already installed system much, much less
>> of a pain in the rear. Why would I care about a few dozen tiny
>> innocuous unused files on a system that per default install is
>> already cluttered with literally thousands of files I'm never going
>> to use in any way.
> 
> I write my own daemons. There may come a time when I put a free
> software license on one of them and distribute it to the world. If I
> did so, I might (or might not) include the runit run script I use to
> run it. If I were feeling particularly nice that day, I might also
> supply an s6 run script, because s6 run scripts are almost 1 to 1
> translations from runit.
> 
> But there's no way I'd ever take the time to supply facilities for
> startup in sysvinit, OpenRC, systemd or busybox. **Not my job!**

While writing I was thinking more about package maintainers, not 
necessarily the author of a piece of software, though there will
always be some considerable overlap between those groups of people.

>> That'd be what I'd call "init freedom". It's very unlikely to happen
>> in the foreseeable future though, as it would require cooperative
>> effort of hundreds of individuals to include and maintain those init
>> support files in the respective packages.
> 
> Now it sounds like you're talking about something else. It now sounds
> like you're talking about a group of init experts making startup
> facilities for programs using various inits. This is a good idea. A
> systemd unit file, or an s6 or runit run script offer excellent
> documentation for how to configure the application for just about any
> init system.

Again, as above, I was thinking more about distribution package 
maintainers. Though it would obviously be of great help if patches 
were submitted by "init experts", without giving much thought to 
the question what traits would characterize such an "expert". By
"cooperative effort" I meant that the maintainers of _all_ the 
daemon packages present in a distribution would have to provide 
and/or maintain init facilities for all supported init systems, 
as otherwise the whole endeavor would fail.

> 
> sysvinit and OpenRC typically have init scripts tens or hundreds of
> lines, making init integration of an application seem like an arcane
> art. What are they thinking? IMHO these immense and unfathomable init
> scripts are what opened the door for systemd.
> 


I rarely write init scripts from scratch, and when I have to edit
one I count myself lucky if it's just some posix shell script that, 
while admittedly not being exactly elegant, is in most parts 
comprehensible to me without in-depth study of some init system 
manual. Hence, I for one am content with the imperfect well-hung
sysv-rc init. I'd however never try to force that attitude onto 
other people. (Not implying you did, mind you, just generally 
speaking here.)


Each to their own, I'd say. While I agree that a lot of rc-style
scripts look quite messy, at least these are plain shell scripts, 
giving full control over as much minutiae of daemon behavior as 
is conceivably possible, as the author is provided with virtually
unrestricted access to the complete toolbox of standard unix 
utilities to pick from in order to accomplish his task. 

On the other hand, concise configuration files as used by many 
non-rc-style init systems have their own charm, but this gain in 
elegance comes at the expense of handing over a lot of fine 
grained control specifics to (a set of more or less integrated) 
binaries that behave to at least some degree opaque to the casual 
observer. This offloading of nitty-gritty specifics can come as 
either a blessing or a curse, depending on the case at hand.

In the big picture, rc-style init systems constitute (almost) 
one extreme of the spectrum, while systemd is the perfect example 
for the other extreme, i.e. what happens when scope creep takes 
the alleged simplification more than a few steps too far by 
basically building a shadow OS, epitomized as a nightmarish 
hairball of elements that each are individually inferior compared 
to their "do one thing" unixish counterparts in the actual OS.

Somewhere among this vast spectrum between spaghetti script and 
three-liners consumed by incomprehensible pseudo-modular binary 
monsters there should be something suitable for virtually anybody. 
And that is what makes me buy into the notion of init freedom as 
a declared objective of Devuan.

As always this po

Re: [DNG] A new article on Devuan (in German)

[Irrwahn]

KatolaZ wrote on 26.07.2018 12:03:
> Dear D1rs,
> 
> just to point out the nice article written by Michael Plura and
> recently published in the German computer magazine "iX":
> 
>   https://www.heise.de/select/ix/2018/8/1533453649894916

That was a pleasant read, thanks for the link! I hope we'll be able
to see more and more well balanced articles like this one, written 
by informed individuals who adhere to factual reporting instead of 
stirring up useless emotion-laden fights over spilled milk.

Regards,
Urban
P.S.: 
That bit about Devuan technical support made me chuckle:

| Technische Hilfe erhält man in der Regel schnell, auch wenn sich
| ein beachtlicher Teil der Konversationen um eher esoterische und
| prinzipielle Fragen dreht.

Which roughly translates to:

| In general you get technical support in a timely manner, even if 
| a considerable part of the conversation revolves around more
| esoteric and principled questions.

I take that as a polite way to give us a reminder to always strive 
to keep the signal to noise ratio as high as possible and to let 
threads about conspiracy theories and other cruft quickly find their 
final destination in /dev/null.

-- 
Sapere aude!



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

Re: [DNG] systemd and ssh-server

[Irrwahn]

Hendrik Boom wrote on 26.07.2018 12:35:
> On Wed, Jul 25, 2018 at 06:50:43PM +0200, Irrwahn wrote:
>> Hendrik Boom wrote on 25.07.2018 17:59:
>> [cut] 
>>> Package dependencies are of the form
>>> Install X if Y is installed
>>> Too bad it doesn't handle
>>> Install X it Y and Z are installed.
>>> I suspect, though, we don't wand to have to embed a SAT solver into the
>>> package manager.  It's already complicated enough.
>>
>> Hi Hendrik,
>>
>> I'm not entirely sure I correctly understand what you think that could
>> accomplish. In case you meant it the way I _think_ you did, this would 
>> be my two cents worth of comment:
>>
>> It wouldn't help a bit, at least in the case at hand. The package 
>> dependency exists to make sure a library (here: libsystemd.so.0) the 
>> application (here: sshd) was linked against is present on the system, 
>> as otherwise the application would simply fail to start, which is 
>> undesirable.
> 
> I was thinking about package Y, which has systemd init script in package Xd,
> depend on package Xd only if systemd is present.
> 
> No linking involved.
> 
> But I agree that adding such a mechanism would greaty complicate the 
> package manager, likely beyond feasibility.  Not worth it if it's only 
> to avoid a few small files that may never be used.
> 

Oh, you were talking about init scripts and unit files and the like, so 
I did get you wrong after all. 

I agree it's not worth it, for the reasons you gave. What's more, I'd go 
even further and say I wouldn't mind at all if every daemon package came 
with support for all init systems in current use (rc-style sysv|openrc, 
runit, ... , systemd), as that would make switching init systems in an 
already installed system much, much less of a pain in the rear. Why would 
I care about a few dozen tiny innocuous unused files on a system that per
default install is already cluttered with literally thousands of files 
I'm never going to use in any way.

That'd be what I'd call "init freedom". It's very unlikely to happen in 
the foreseeable future though, as it would require cooperative effort of 
hundreds of individuals to include and maintain those init support files 
in the respective packages.

Regards,
Urban
-- 
Sapere aude!



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

Re: [DNG] systemd and ssh-server

[Irrwahn]

Simon Hobson wrote on 25.07.2018 23:25:
> KatolaZ  wrote:
> 
>> Replace 'links2' with 'openssh-server' and 'libfbdirect' with
>> 'libsystemd0', and you should see what I mean. Most of the De??an
>> installations actually have tons of libraries that are never used, or
>> are just used to probe for a certain functionality that is not
>> available. This happens all the time, under the hood. 
> 
> Well yyeee, and no.
> AIUI it is **possible** to write your program with functionality along the 
> lines of :
> - test if libx is available
> - if so
> -- load libx
> -- call function y to see if facility z is available

And there's also the option of linking statically at build time.

Please note I'm mentioning this only for completeness' sake, not 
that I actually propose to descend to that ring of hell. (Except
for the few and far between well defined cases where this is 
actually a reasonable thing to do.)

Static linking: 
After shooting your foot you rebuild the world to recover.

Dynamic linking: 
You shoot everyone's foot at once in a single shot.

Moral of the story: There is no silver bullet.

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] systemd and ssh-server

[Irrwahn]

Hendrik Boom wrote on 25.07.2018 17:59:
[cut] 
> Package dependencies are of the form
> Install X if Y is installed
> Too bad it doesn't handle
> Install X it Y and Z are installed.
> I suspect, though, we don't wand to have to embed a SAT solver into the
> package manager.  It's already complicated enough.

Hi Hendrik,

I'm not entirely sure I correctly understand what you think that could
accomplish. In case you meant it the way I _think_ you did, this would 
be my two cents worth of comment:

It wouldn't help a bit, at least in the case at hand. The package 
dependency exists to make sure a library (here: libsystemd.so.0) the 
application (here: sshd) was linked against is present on the system, 
as otherwise the application would simply fail to start, which is 
undesirable.

Regards,
Urban

-- 
Sapere aude!



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

[DNG] New here and needing help about backports

[Irrwahn]

[Sorry, I accidentally hit "reply" instead of "reply list"; here's 
the same message re-posted to DNG.]

Stephane Ascoet wrote on 24.07.2018 13:33:
[...]
> But now I'm stuck with a similar problem for "linux-compiler-gcc-6-x86 
> 4.16.16-2~bpo9+1 [kernel - optional]"
> 
> It is needed but I can't install it because when I "aptitude search 
> linux-compiler" I get:
> i A linux-compiler-gcc-4.8-x86 
>- Compiler for Linux on x86 
> (meta-package) 
> 
> 
> i   linux-compiler-gcc-6-x86 
>- Compiler for Linux on x86 
> (meta-package)
> 
> When I install linux-compiler-gcc-6-x86 I get:
>   ii  linux-compiler-gcc-6-x86   4.9.110-1 
> amd64
> 
> I can't get the 4.16 one, please help!!!
> 

Hi Stephane,

did you explicitly tell whatever apt frontend you're using to pull the 
package from ascii-backports?  Like e.g.:

  apt-get install -t ascii-backports linux-compiler-gcc-6-x86

Re-reading your text I see you used aptitude for searching, so as an 
alternative you can use its interactive mode to mark the desired package 
for installation.

Background: By default the backports repositories take lower priority than
the main repositories, so you have to explicitly tell the package manager 
your intent to install a backported package - unless the backported version 
is already required as a dependency of an already (to be) installed package, 
which will lead to the correct version being pulled right away. 
  If, for example, linux-headers-4.16.0-0.bpo.2-amd64 is to be installed, 
then linux-compiler-gcc-6-x86 should be installed automagically.

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] Is Thunderbird clean?

[Irrwahn]

dan pridgeon wrote on 23.07.2018 18:01:
> Does installing Thunderbird drag in any systemd stuff.  Thank you.

Hi Dan.

No, it doesn't. Otherwise it would be impossible to install from the 
Devuan repositories, as all systemd stuff is banned there. (Except 
libsystemd0 which by itself is harmless without actual systemd being 
present. But that's irrelevant for thunderbird anyway.)

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] Unswapping interface namesRe: (WAS: what has gone wrong with networking in ascii?

[Irrwahn]

Hendrik Boom wrote on 15.07.2018 22:03:
[...]
> And I found a number of other eth's in /etc/* and /etc/*/* using grep.
[...]
> It would have been fouond with one more *: /etc/*/*/*

Hi Hendrik,

you may find that using grep's -r or -R option can make your life a 
lot easier. Quoting the man page:

   -r, --recursive
  Read  all  files  under  each directory, recursively,
  following symbolic links only  if  they  are  on  the
  command line.  Note that if no file operand is given,
  grep  searches  the  working  directory.This   is
  equivalent to the -d recurse option.

   -R, --dereference-recursive
  Read  all  files  under  each directory, recursively.
  Follow all symbolic links, unlike -r.

HTH, best regards
Urban

-- 
Sapere aude!



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

Re: [DNG] New here and needing help about backports

[Irrwahn]

Stephane Ascoet wrote on 13.07.2018 11:53:
[cut]
> On 
> 
>  
> I can see "[ascii-backports] virtualbox-5.2.10-dfsg-6~bpo9+1".
> 
> So I "aptitude update" but after that, "aptitude search virtualbox" only 
> gives me "i   virtualbox-5.1". What's going on???
> 
> For information:
> cat /etc/apt/sources.list
[cut]
> deb http://pkgmaster.devuan.org/merged ascii main
> deb http://pkgmaster.devuan.org/merged ascii-updates main
> deb http://pkgmaster.devuan.org/merged ascii-security main
> deb http://pkgmaster.devuan.org/merged ascii-backports main
[cut]

Hi Stephane,

as you can tell from page you linked to the link you posted VirtualBox 
is placed in the 'contrib' section, which you did not enable for the 
ascii-* stanzas in your sources.list.

HTH, best regards
Urban

-- 
Sapere aude!



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

Re: [DNG] Virtualbox

[Irrwahn]

Ozi Traveller wrote on 11.07.2018 01:36:
> Hi
> 
> Just wondering if anyone is using virtualbox, and whether it brings in and 
> systemd stuff?

Hi Ozi,

I'm using VirtualBox 5.2.14 from virtualbox.org, no systemd 
dependencies. The same should be true for the De(bi|vu)an 
package (ascii-backports has 5.2.10).

HTH,
Urban

-- 
Sapere aude!



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

Re: [DNG] dosemu package missing (SOLVED)

[Irrwahn]

Joel Roth wrote on 10.07.2018 20:50:
> Irrwahn wrote:
>> Joel Roth wrote on 10.07.2018 19:55:
>>> Hi maintainers 
>>>
>>> I notice that dosemu is available through debian (all
>>> releases), but the packages are not in the devuan repo,
>>> at least for the ascii release. 
>>>
>>> May be worth looking into
>  
>> Hi Joel,
>>
>> dosemu version 1.4.0.7+20130105+b028d3f-2+b1 is in Devuan 2.0 ASCII.
>>
>> As it's in the contrib division, section otherosfs, you might have 
>> to tweak your sources list to include 'contrib' in order to install 
>> it via apt(-get|titude). 
> 
> Thanks, Urban. 
> 
> I followed a tutorial for upgrading to ascii. I think the
> instructions for setting up /etc/apt/sources.list for devuan
> could benefit from including contrib. 
> 

You're welcome, Joel.

Well, just as in Debian, the contrib and non-free sections are not 
considered part of the distribution, and as such it's not particularly
surprising to find those not heavily advertised in (semi-)official
documents. (Although many of us have to rely on their presence, be it 
to drive a particular piece of hardware or for other individually 
important reasons.)

The case of dosemu piqued my interest, as it being placed in the 
contrib section would imply it is free software in itself, but depends 
on packages from the non-free section. However, looking at the list of 
dependencies I cannot make out anything coming from non-free. I'm not 
sure what to make of this. Either I'm missing some important connection, 
or it is some kind of glitch, possibly for historic reasons?! 
I genuinely don't know.

I have no experience with dosemu, and I do not know for what special 
purpose you're using it, but just in case someone is looking for an 
alternative from the free main (i.e. neither contrib nor non-free) 
section, there's also dosbox, which I have successfully used in the 
past to revive ancient software written for DOS.

Best regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] dosemu package missing

[Irrwahn]

Joel Roth wrote on 10.07.2018 19:55:
> Hi maintainers 
> 
> I notice that dosemu is available through debian (all
> releases), but the packages are not in the devuan repo,
> at least for the ascii release. 
> 
> May be worth looking into
> 

Hi Joel,

dosemu version 1.4.0.7+20130105+b028d3f-2+b1 is in Devuan 2.0 ASCII.

As it's in the contrib division, section otherosfs, you might have 
to tweak your sources list to include 'contrib' in order to install 
it via apt(-get|titude). 

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] dnsmasq: junk found in command line

[Irrwahn]

hal wrote on 09.07.2018 13:08:
> Hi,
> I am having a problem starting dnsmasq after latest update to my devuan VM.
> The error is when trying to start the init script:
> 
>dnsmasq: junk found in command line
> 
> I think I might be on old Devuan version[1] because /etc/issue says "1". Maybe
> this is the problem but I see a directory added/updated on Jun 25 
> /usr/share/dns/ with
> a few files in it. The init script uses sed to get some options from the 
> files there
> and then tries starting dnsmasq with fail message above.
> 
> If I debug init script[3], I get weird options indeed. Any ideas how to fix 
> this?
> For now I have dnsmasq started by command line with simple options "-d -C 
> configfile"
> Thank you
> 
[cut]

Hi hal,

I vaguely recall having had a similar issue on some Debian system some 
time in the past. A quick web search dug up this link containing a 
solution that looks familiar to me:

https://unix.stackexchange.com/questions/332168/how-to-get-dnsmasq-to-work

TL,DR: To solve the issue, purge and then reinstall dnsmasq, or, should 
that fail, in /etc/init.d/dnsmasq change the line setting the dnsmasq 
options to:

DNSMASQ_OPTS="$DNSMASQ_OPTS `mawk -- '{ printf " --trust-anchor=.,%d,%d,%d,%s", 
$5, $6, $7, $8 }' $ROOT_DS`"

Root cause presumably is the field delimiters in /usr/share/dns/root.ds 
having changed from spaces to TABs, tripping up the old parser.

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] [OT] Future codename proposal (was: Devuan ASCII 2.0.0 stable)

[Irrwahn]

Irrwahn wrote on 10.06.2018 19:52:

> I wonder if someone could sweet-talk the CSBN of the IAU into 
> creating the precondition for us to dub Devuan 21.0.0 UTF-8.

Corr.:  Of course that would be Devuan 22.0.0 UTF-8.  :-°




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

[DNG] [OT] Future codename proposal (was: Devuan ASCII 2.0.0 stable)

[Irrwahn]

Irrwahn wrote on 09.06.2018 14:34:

> Omedetō gozaimasu, Devuan ASCII!

I wonder if someone could sweet-talk the CSBN of the IAU into 
creating the precondition for us to dub Devuan 21.0.0 UTF-8.

-- 
SCNR, I see myself out.




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

Re: [DNG] Devuan ASCII 2.0.0 stable

[Irrwahn]

Veteran Unix Admins wrote on 09.06.2018 07:05:
> Dear Init Freedom Lovers
> 
> Once again the Veteran Unix Admins salute you!
> 
> We are happy to announce that Devuan GNU+Linux 2.0 ASCII Stable is
> finally available.[...]

Omedetō gozaimasu, Devuan ASCII!

Yet another important milestone on the (init) freedom road.
A big thank you to all the fine folks that made this happen!!!

Gochisōsama deshita!  ;^P

-- 
Sapere aude!



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

Re: [DNG] Thunderbird don't open Links in Firefox

[Irrwahn]

kernel panic wrote on 23.05.2018 10:15:
> Hello all,
> 
> i use the default Devuan Setup whit XFCE Desktop. My default Mailhandler
> is Thunderbird (from Devuan Source) and my default Browser is Firefox
> (also from Devuan Source)
> 
> I can't open any Link in a Mail on "a click" I have no glue why.
> Yesterday i open a Question on Mozilla Support (0) But, maybe the
> problem is deper inside?! You can see in the Link a screenshot from
> Thunderbird. My "Attatchment panel" is empty!?
[...]

Hi,

I remember having had a somewhat similar issue before. In my case it 
was caused by apparmor rules for Thunderbird. No idea if this could 
be the root for your problem, too.

HTH, regards
Urban

-- 
Sapere aude!



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

Re: [DNG] Two packages I miss in ascii/stretch

[Irrwahn]

lpb+dev...@kandl.houston.tx.us wrote on 26.04.2018 21:09:
> I'm putting off an upgrade to ascii because it doesn't include two
> packages I (still?) use: nagios3 and twinkle.
> 
> * how can I find out why they're not moving forward?
> * what would you suggest as a replacement for nagios or twinkle (SIP
> client)?
> 
> Thanks, Luigi

Re twinkle: version 1:1.10.1+dfsg-2 is in Devuan ASCII.

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

Re: [DNG] Help testing Devuan 2 ASCII installer and upgrades!

[Irrwahn]

Irrwahn wrote on 19.04.2018 12:16:
> Dear Devuaners,
> 
> the Devuan team is currently working towards a Release Candidate for 
> Devuan 2 "ASCII". Most of the parts should be already in place, but 
> particularly in the policykit/consolekit/elogind area we are in need of 
> some more thorough testing in order to guarantee correct installation 
> of any of the supported desktop environments as well as smooth upgrades 
> of existing installations.
[...]

For the record:

The following irregularities have already surfaced for fresh 
installations using the current state of the repositories: 
Installing SSH server in combination with a desktop environment 
that originally depends on consolekit session management 
results in elogind being installed (peculiar, but not harmful 
per se) and a mismatch of the policykit backend libraries - 
this definitely *is* a problem! 

Note that in each of the cases listed below both consolekit 
and elogind are present (weird, but not a problem in itself) 
and the elogind PAM module libpam-elogind is installed, while 
the consolekit PAM module libpam-ck-connector is missing -
which makes more or less sense, as these two are mutually 
exclusive. *However*, and this is the crux, given that exact
constellation it would be correct to also have the matching 
libpolkit-(backend|gobject)-elogind-1-0 packages, but instead 
the corresponding *-consolekit-* packages are installed.
Thus, unfortunately something is still slightly off with the 
polkit dependencies.

1. Standard install, Xfce + SSH server
 ii consolekit 0.4.6-6
 ii elogind 234.4-2
 ii libelogind0:amd64 234.4-2
 ii libpam-elogind:amd64 234.4-2
 ii libpolkit-agent-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-backend-1-0 0.105-18+devuan2.9
 ii libpolkit-backend-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-gobject-1-0 0.105-18+devuan2.9
 ii libpolkit-gobject-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii policykit-1 0.105-18+devuan2.9


2. Standard install, LXDE + SSH server
 ii consolekit 0.4.6-6
 ii elogind 234.4-2
 ii libelogind0:amd64 234.4-2
 ii libpam-elogind:amd64 234.4-2
 ii libpolkit-agent-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-backend-1-0 0.105-18+devuan2.9
 ii libpolkit-backend-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-gobject-1-0 0.105-18+devuan2.9
 ii libpolkit-gobject-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-qt5-1-1:amd64 0.112.0-5
 ii lxpolkit 0.5.3-2
 ii lxqt-policykit 0.11.1-1
 ii lxqt-policykit-l10n 0.11.2-1
 ii policykit-1 0.105-18+devuan2.9
 ii policykit-1-gnome 0.105-6

3. Expert install, MATE + SSH server 
 ii consolekit 0.4.6-6
 ii elogind 234.4-2
 ii libelogind0:amd64 234.4-2
 ii libpam-elogind:amd64 234.4-2
 ii libpolkit-agent-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-backend-1-0 0.105-18+devuan2.9
 ii libpolkit-backend-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-gobject-1-0 0.105-18+devuan2.9
 ii libpolkit-gobject-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii mate-polkit:amd64 1.16.0-2
 ii mate-polkit-common 1.16.0-2
 ii policykit-1 0.105-18+devuan2.9

Best regards
Urban

P.S.: In preliminary tests those DEs relying on elogind (e.g. 
LXQt, Cinnamon) do not suffer from this bug and correctly get 
a "pure" elogind session management with correctly matched 
policykit backend|gobject libraries.
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] New policykit-1 packages in ASCII

[Irrwahn]

Florian Zieboll wrote on 19.04.2018 15:32:
> On Thu, 19 Apr 2018 13:54:05 +0200
> Irrwahn <irrw...@freenet.de> wrote:
> 
>> LXDE/SLiM should work well with consolekit on ASCII, provided you have
>> at least the following packages installed:
>>
>>  ii consolekit 0.4.6-6
>>  ii libpolkit-agent-1-0:amd64 0.105-18+devuan2.9
>>  ii libpolkit-backend-1-0 0.105-18+devuan2.9
>>  ii libpolkit-backend-consolekit-1-0:amd64 0.105-18+devuan2.9
>>  ii libpolkit-gobject-1-0 0.105-18+devuan2.9
>>  ii libpolkit-gobject-consolekit-1-0:amd64 0.105-18+devuan2.9
>>  ii policykit-1 0.105-18+devuan2.9
> 
> 
> Hallo Urban,
> 
> I have installed all of them in the mentioned versions.
> 

Ugh, I just noticed something weird in my ASCII LXDE VM: 
despite consolekit and the matching polkit backend being 
installed, it also has elogind installed and apparently 
uses that for session auth. I guess you'd in fact be 
better off installing elogind, as KatolaZ suggested in 
his response.

Best regards
Urban

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

Re: [DNG] New policykit-1 packages in ASCII

[Irrwahn]

Florian Zieboll wrote on 19.04.2018 13:42:
> On Thu, 19 Apr 2018 11:38:46 +0100
> KatolaZ  wrote:
> 
>> thanks for the report.  It looks like installing policykit by hand
>> might be the solution here, but Irrwhan and Svante are the masters
>> here. I guess the latter log you posted would set you up fine if you
>> are on XFCE, LXDE or Mate.
> 
> 
> Hallo KatolaZ,
> 
> thank you for the quick reply. The manual re-install, followed by a
> dist-upgrade worked fine, just that now I am missing reboot / shutdown
> functionality from within LXDE again, which is why I originally had
> moved from consolekit to elogind. No serious problem for now, as the
> hw-button works - just as a feedback. 
[...]

Hi Florian,

LXDE/SLiM should work well with consolekit on ASCII, provided you have
at least the following packages installed:

 ii consolekit 0.4.6-6
 ii libpolkit-agent-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-backend-1-0 0.105-18+devuan2.9
 ii libpolkit-backend-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii libpolkit-gobject-1-0 0.105-18+devuan2.9
 ii libpolkit-gobject-consolekit-1-0:amd64 0.105-18+devuan2.9
 ii policykit-1 0.105-18+devuan2.9

Best regards
Urban

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

[DNG] Help testing Devuan 2 ASCII installer and upgrades!

[Irrwahn]

Dear Devuaners,

the Devuan team is currently working towards a Release Candidate for 
Devuan 2 "ASCII". Most of the parts should be already in place, but 
particularly in the policykit/consolekit/elogind area we are in need of 
some more thorough testing in order to guarantee correct installation 
of any of the supported desktop environments as well as smooth upgrades 
of existing installations.

Here is where you can make a valuable contribution: If you happen to 
have a spare Devuan (Jessie|ASCII) or a Debian (Jessie|Stretch) desktop 
machine (virtual or hardware) that you feel brave enough to sacrifice 
for testing the upgrade paths - please do so! Ideally, you should report 
any irregularities you encounter in this thread. The main observation 
focus should be set on session related functionality, especially the 
ability to user mount removable drives and to restart or shutdown the 
machine using the controls offered by the respective desktop environment.

Furthermore, testing fresh installs in various configurations using the 
latest ASCII mini.iso [1] will be much appreciated, although we should 
already have a pretty good coverage in that area, but more testing is 
always a Good Thing[TM].

Thank you very much, any help you can offer is much appreciated! 

Best regards
Urban

[1] Available here:
https://pkgmaster.devuan.org/devuan/dists/ascii/main/installer-amd64/current/images/netboot/mini.iso
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] broken PDF display

[Irrwahn]

Irrwahn wrote on 23.03.2018 20:04:
> Renaud (Ron) OLGIATI wrote on 23.03.2018 19:30:
>> On Fri, 23 Mar 2018 14:14:47 -0400
>> Haines Brown <hai...@histomat.net> wrote:
>>
>>> Recently and not in association with any system changes, atril and xpdf
>>> no longer displays the content of perhaps half my PDF files. They see
>>> all the pages, but they are blank. An exception is that sometimes a
>>> cover page, TOC, download notice at bottom of pages, or the graphics are
>>> displayed, but not the text. This is consistent: a failure or success
>>> repeats on subsequent tries.
> 
>  
> 
>> I have noticed the same behaviour in recent days, but while the .pdf files 
>> do not display properly in evince or pdfshuffler, they do in gv.
> 
> Hi Haines, hi Ron,
> 
> just a random shot in the dark, but since AFAICT atril and xpdf do not 
> share the same rendering engine (going solely by package dependencies, 
> I might well be wrong on that account), this could possibly be a font 
> caching problem. Maybe a forced rebuild of the font cache might help: 


Nevermind! Forget what I wrote - I mistakenly tested with ASCII instead of 
Jessie, sorry! 

Adam Sampson was spot on: On Jessie, downgrading libpoppler46 to 
0.26.5-2+deb8u1 
allows to get around the bug that is perfectly reproducible with ...+deb8u3.

Best regards
Urban

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

Re: [DNG] broken PDF display

[Irrwahn]

Adam Sampson wrote on 23.03.2018 19:55:
> Haines Brown  writes:
> 
>> Recently and not in association with any system changes, atril and xpdf
>> no longer displays the content of perhaps half my PDF files.
> 
> I'm seeing the same problem on plain Debian with xpdf and evince -- it's
> one of several problems that were introduced as part of security fixes
> in libpoppler46 0.26.5-2+deb8u2. ...+deb8u1 works OK, if you don't need
> the security fixes.
> 
> There are a couple of Debian bugs about this already:
> https://bugs.debian.org/886798
> https://bugs.debian.org/890826

Hi Adam,

interesting! FWIW, on Devuan ASCII libpoppler64 0.48.0-2+deb9u2 works fine,
even with the test document provided in #890826.

Best regards
Urban

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

Re: [DNG] broken PDF display

[Irrwahn]

Renaud (Ron) OLGIATI wrote on 23.03.2018 19:30:
> On Fri, 23 Mar 2018 14:14:47 -0400
> Haines Brown  wrote:
> 
>> Recently and not in association with any system changes, atril and xpdf
>> no longer displays the content of perhaps half my PDF files. They see
>> all the pages, but they are blank. An exception is that sometimes a
>> cover page, TOC, download notice at bottom of pages, or the graphics are
>> displayed, but not the text. This is consistent: a failure or success
>> repeats on subsequent tries.

 

> I have noticed the same behaviour in recent days, but while the .pdf files do 
> not display properly in evince or pdfshuffler, they do in gv.

Hi Haines, hi Ron,

just a random shot in the dark, but since AFAICT atril and xpdf do not 
share the same rendering engine (going solely by package dependencies, 
I might well be wrong on that account), this could possibly be a font 
caching problem. Maybe a forced rebuild of the font cache might help: 

  fc-cache -rf

FWIW, I can not reproduce any obvious rendering glitches here using any 
PDF software based on the usual libraries (cairo, pango, poppler, ...),
and I have a metric to of fonts installed on this here system. (While 
typing this I remembered years ago I had problems due to a broken font 
file, but that did not result in a _total_ loss of PDF font rendering 
capabilities across different tools.)

BTW mupdf would be yet another simple viewer for you to try, in case you 
haven't already.

HTH, best regards
Urban

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

Re: [DNG] Dist-upgrade to ACSII error

[Irrwahn]

John Crisp wrote on 23.03.2018 19:04:
> Oooops.
> 
> Was upgrading to ACSII and all was going swimmingly until right near the
> end (usual Friday then !)
> 
> Seems eudev is in a knot.
> 
> I think it probably needs removing and reinstalling, but that wants to
> rip out all the kernels !!!
> 
> Any suggestions on getting out of this one without a reboot?


Hi John,

IIRC this is a known problem during updates that is about to be fixed 
before ASCII goes stable.

Please try to:
  1. remove the transitional udev package (if applicable)
  2. move the file /etc/init.d/udev out of the way (if present)
  3. reinstall (or rather configure) the eudev package.

HTH, best regards
Urban

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

Re: [DNG] dnsmaq on devuan

[Irrwahn]

John Crisp wrote on 23.03.2018 02:22:
> I have been having some struggles running dnsmasq on Devuan Jessie.
> 
> After a lot of head scratching I started to realise the init file seems
> a touch out of whack. For starters, no pid file is generated when you
> start dnsmasq.
> 
> There I was thinking I was stopping and starting it when in reality, I
> was just adding more instances ! That would then explain why the new
> settings I kept trying seemed to fail miserably. Doh 
> 
> I do not have resolvconf installed.
> 
> dnsmasq  2.72-3+deb8u2
> 
> I just wanted a simple caching nameserver for VPN clients with some
> simple static upstream DNS nameservers set.
> 
> I can sit down and slowly debug my way through the init file but
> wondered if anyone else had any experiences with this?


Hi John,

I routinely have dnsmasq running on my Devuan ASCII box (was running 
Debian testing/jessie before) and never observed any irregularities.
I checked and the PID file is correctly maintained, issuing service 
start/stop/status commands works as expected. (dnsmasq 2.76-5+deb9u1)

For comparison I tested again on a Devuan Jessie VM (dnsmasq version
2.72-3+deb8u2, same as yours) with identical positive results. No 
resolvconf installed on both systems.
The dnsmasq init scripts in Jessie and ASCII differ basically just in 
the relocation /var/run --> /run. But since the former should be just
a symlink to the latter on both systems it should not have any 
noticeable effect at all. For reference I attached a diff between the 
two versions.

Whatever causes you trouble, I strongly believe it's not the dnsmasq 
init script per se that is to blame. 

Sorry I cannot provide you with an instant solution for your problem.

HTH, best regards
Urban

P.S.:  
Yes, I too find the file time stamps in the diff slightly irritating, 
but I double checked I was comparing the correct files. I did not 
inspect the respective source packages though.

-- 
Sapere aude!
--- dnsmasq.jessie	2017-10-01 19:17:30.0 +0200
+++ dnsmasq.ascii	2017-10-01 17:20:45.0 +0200
@@ -8,7 +8,8 @@
 # Description:DHCP and DNS server
 ### END INIT INFO
 
-set +e   # Don't exit on error status
+# Don't exit on error status
+set +e
 
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/sbin/dnsmasq
@@ -29,12 +30,11 @@
 export LANG
 fi
 
-# /etc/dnsmasq.d/README is a non-conffile installed by the dnsmasq package.
-# Should the dnsmasq package be removed, the following test ensures that
-# the daemon is no longer started, even if the dnsmasq-base package is
-# still in place.
-test -e /etc/dnsmasq.d/README || exit 0
-
+# The following test ensures the dnsmasq service is not started, when the
+# package 'dnsmasq' is removed but not purged, even if the dnsmasq-base 
+# package is still in place.
+test -e /usr/share/dnsmasq/installed-marker || exit 0
+ 
 test -x $DAEMON || exit 0
 
 # Provide skeleton LSB log functions for backports which don't have LSB functions.
@@ -81,7 +81,7 @@
[ "$IGNORE_RESOLVCONF" != "yes" ] &&
[ -x /sbin/resolvconf ]
 then
-	RESOLV_CONF=/var/run/dnsmasq/resolv.conf
+	RESOLV_CONF=/run/dnsmasq/resolv.conf
 fi
 
 for INTERFACE in $DNSMASQ_INTERFACE; do
@@ -121,16 +121,16 @@
 	#   1 if daemon was already running
 	#   2 if daemon could not be started
 
-# /var/run may be volatile, so we need to ensure that
-# /var/run/dnsmasq exists here as well as in postinst
-if [ ! -d /var/run/dnsmasq ]; then
-   mkdir /var/run/dnsmasq || return 2
-   chown dnsmasq:nogroup /var/run/dnsmasq || return 2
+# /run may be volatile, so we need to ensure that
+# /run/dnsmasq exists here as well as in postinst
+if [ ! -d /run/dnsmasq ]; then
+   mkdir /run/dnsmasq || return 2
+   chown dnsmasq:nogroup /run/dnsmasq || return 2
 fi
 
-	start-stop-daemon --start --quiet --pidfile /var/run/dnsmasq/$NAME.pid --exec $DAEMON --test > /dev/null || return 1
-	start-stop-daemon --start --quiet --pidfile /var/run/dnsmasq/$NAME.pid --exec $DAEMON -- \
-		-x /var/run/dnsmasq/$NAME.pid \
+	start-stop-daemon --start --quiet --pidfile /run/dnsmasq/$NAME.pid --exec $DAEMON --test > /dev/null || return 1
+	start-stop-daemon --start --quiet --pidfile /run/dnsmasq/$NAME.pid --exec $DAEMON -- \
+		-x /run/dnsmasq/$NAME.pid \
 	${MAILHOSTNAME:+ -m $MAILHOSTNAME} \
 		${MAILTARGET:+ -t $MAILTARGET} \
 		${DNSMASQ_USER:+ -u $DNSMASQ_USER} \
@@ -167,7 +167,7 @@
 	#   1 if daemon was already stopped
 	#   2 if daemon could not be stopped
 	#   other if a failure occurred
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile /var/run/dnsmasq/$NAME.pid --name $NAME
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile /run/dnsmasq/$NAME.pid --name $NAME
 }
 
 stop_resolvconf()
@@ -185,9 +185,9 @@
 	#   1 if daemon is dead and pid file exists
 	#   3 if daemon is not running
 	#   4 if daemon status is unknown
-	

Re: [DNG] pam_limits or limits.conf different from Debian?

[Irrwahn]

Patrick Dunford wrote on 02.03.2018 13:45:
> I did some more tweaking, and basically it looks like I have to set the hard 
> limit higher as well as the soft limit, in /etc/security/limits.conf
> 
> The hard limit in Debian must be set higher somewhere else, because you don't 
> have to set that one in the same file normally.
> 
[cut]

That is consistent with my own observations. On my desktop ASCII 
machine the hard limit for nofile appeared to be set to an arbitrary 
limit of 4096. Unfortunately I, too, have no clue by what mechanism 
this limit is pre-configured.

Note, however, that you can set both the hard and soft limits to 
the same value simultaneously in /etc/security/limits.conf by using 
a '-' (hyphen) in the  field (second column); for example:

 - nofile 32000


Best regards
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] warning: Devuan jessie i386 doesn't boot on i586

[Irrwahn]

Alexander Bochmann wrote on 14.02.2018 21:56:
> Ran into this when trying to move an old box with a Via C3 CPU 
> from Debian jessie (last release to support i586) to Devuan jessie: 
> System resets before even loading Devuan-built grub. 
[...]

Now that is particularly odd, as grub is not among the packages 
that were forked by Devuan but rather is merged from Debian. 

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Hleb Valoshka wrote on 14.02.2018 21:54:
> On 2/14/18, Irrwahn <irrw...@freenet.de> wrote:
>>>>> Fresh installations of Devuan ASCII 2.0.0 Beta should not be affected.
>>>> Actually no, i've installed Ascii for testing purposes and systemd
>>>> policykit backend was pulled.
>>> That's a first AFAICT. Noted.  Thanks, Hleb! :)
>>> Oh, you wouldn't have by any chance saved the package list in that state?
>>> In the unlikely case you have, could you please email it to me?
> 
> I created a ascii chroot using debootstrap and then installed
> task-xfce-desktop using interactive mode of aptitude, which showed 2
> broken packages - backend and gobject of policykit. It was the
> previous weekend, so there is tiny chance that the is issue has been
> solved already (for clean installations).

That might indeed be the case, as there were some last-minute 
changes to the policykit packages right before the beta release. 
 
>> P.S.:
>> I forgot to ask: Did you use a package mirror or did you perform a purely
>> offline install?
> 
> I used http://deb.devuan.org/merged

That's fine, then.

Thanks for the info! :)
 
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Dr. Nikolaus Klepp wrote on 14.02.2018 21:35:
[...]
> On my system it tried to pull in libpolkit-gobject-1-0-systemd. The reason 
> was aptitude: "twin-trinity" (which is installed) provides 
> "x-display-manager" was ignored, instead aptitude resolved by some obscure 
> reason that the not installed "cinnamon" provides "x-display-manager", so 
> "libpolkit-gobject-1-0-systemd" has to be installed (but not "cinnamon"), 
> ignoring "twin-trinity" which already provides "x-display-manager".
> 
> The second solution that aptitude resolved did not pull in 
> "libpolkit-gobject-1-0-systemd", so that was no big issue.
> 
> After I followed your advise giving in 
> https://lists.dyne.org/lurker/message/20180214.123746.e89eaef8.en.html (I 
> decided to go with elogind) aptitude did resove correctly.

Hi, 

thank you for your valuable feedback! We will definitely have to have 
a closer look at the dependency chains in that whole area. 

Best regards
Urban

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Irrwahn wrote on 14.02.2018 19:46:
> Hleb Valoshka wrote on 14.02.2018 19:20:
>> On 2/14/18, Irrwahn <irrw...@freenet.de> wrote:
>>
>>> Fresh installations of Devuan ASCII 2.0.0 Beta should not be affected.
>>
>> Actually no, i've installed Ascii for testing purposes and systemd
>> policykit backend was pulled.
> 
> That's a first AFAICT. Noted.  Thanks, Hleb! :)
> 
> Oh, you wouldn't have by any chance saved the package list in that state? 
> In the unlikely case you have, could you please email it to me?

P.S.:  
I forgot to ask: Did you use a package mirror or did you perform a purely 
offline install? 

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Hleb Valoshka wrote on 14.02.2018 19:20:
> On 2/14/18, Irrwahn <irrw...@freenet.de> wrote:
> 
>> Fresh installations of Devuan ASCII 2.0.0 Beta should not be affected.
> 
> Actually no, i've installed Ascii for testing purposes and systemd
> policykit backend was pulled.

That's a first AFAICT. Noted.  Thanks, Hleb! :)

Oh, you wouldn't have by any chance saved the package list in that state? 
In the unlikely case you have, could you please email it to me?

Thanks again & best regards
Urban

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Didier Kryn wrote on 14.02.2018 17:05:
> Le 14/02/2018 à 16:21, Irrwahn a écrit :
[...]
>> Just go ahead, have your session management of the day!;-P
> 
>      Did that, I reinstalled slim and made it the DM in charge. 
> Everything works fine, except slim has lost its beautifull background. 
> Now its background is just grey.
> 
>              Didier

H ... you might try to (re-)install the desktop-base package from 
Devuan. It has the theme for slim IIRC (among other stuff).

Urban

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

leloft wrote on 14.02.2018 15:46:
[...]
> I do not know anything like enough to do anything more than comment, but
> does the above indicate that the *-backend-systemd is being pulled in
> as a result of an unhelpful dependency chain.  And why does the
> installation of libpolkit-backend-1-0-consolekit pull in 
> elogind libelogind0 libpam-elogind libpolkit-gobject-1-0-systemd
> when consolekit has been installed in preference to elogind?
[...]

It would appear so, but just now it's hard to put the finger on the 
exact spot where things are wired wrong. This is but one of the kinks 
to expect in beta release, and the very reason why there is a beta 
released in the first place. I'm sure it will eventually get sorted out.

And, FWIW, the backend-systemd could IMHO easily be dropped entirely, 
as it would be rather peculiar for someone to actually try and force a 
genuine systemd package into Devuan, of all systems. ;o)

Best regards
Urban

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Didier Kryn wrote on 14.02.2018 15:54:
> Le 14/02/2018 à 15:32, Irrwahn a écrit :
>> Removing consolekit isn't mandatory, but yes, in doing so one causes
>> same breakage just as you described.
> 
>      Sure it is possible to have both Consolekit and Elogind, but can 
> they be both active?
> 
>              Didier

Yes. 

Oh, how I would know, you might ask.  Well, for a start, I'm typing this
message on a desktop machine where it's the case.  :)

As I wrote in the OP: Which one gets the cookie, so to speak, is decided 
by the choice of polkit backend. Currently elogind here, but I could just 
as well swap it out for the consolekit backend library, should I decide to 
start my lightdm/Xfce desktop that way. 

Just go ahead, have your session management of the day! ;-P

And kudos to the fine chaps that made it possible!

Urban

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

Re: [DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

Didier Kryn wrote on 14.02.2018 15:06:
> Le 14/02/2018 à 13:37, Irrwahn a écrit :
[...]
>> 1. Make sure you have at least one of (traditional) consolekit or (new)
>> elogind installed. (Note: You can have both installed and active; which
>> one is actually used however is decided by which libpolkit-backend you
>> choose to install, see 4.)
>      I had both elogind and consolekit.
> 
>      Removing consolekit forces removal of task-xfce-desktop and few 
> other packages including slim.

Removing consolekit isn't mandatory, but yes, in doing so one causes 
same breakage just as you described.

[...]
>> Note:  Depending on what login manager you use in conjunction with which
>> desktop environment you might have to experiment a bit to find out which
>> of consolekit or elogind works best for you (or works[TM] at all).
> 
>      Note that task-xfce-desktop requires slim and slim requires consolekit.

Correct. That however is not an accident, but more or less on purpose.

> 
>      I already had lightdm installed, but slim was the onein function. 
> Tried dpkg-reconfigure lightdm, expecting to select the DM in function, 
> but there was no dialog. After reboot, the lightdm greeting popped up. 
> Xfce pannel's buttons for exit/reboot/shutdown now work properly.

Side note: It is absolutely possible to have the consolekit/slim/xfce 
combo working. Incidentally, that is exactly the setup that gets 
installed when you go all with the defaults during a fresh ASCII BETA 
installer run.

>      Mmc devices can now be mounted from the icon on xfce desktop - 
> permission was denied before.
> 
>      Good job!

Glad that did help, you're welcome. :)

>      If elogind is to be Devuan's default, then, for consistency, 
> another DM than slim should be the default, and task-xfce-desktop should 
> be modified acordingly.

(See side note above.)

AIUI there has not even been any decision *if* there even will be a single
default in this respect, at the very least for ASCII. Different flavors 
of desktop environments work more or less well with different combinations 
of session management and login manager, and consequently the various 
task-...-desktop meta-packages each come with their distinct preferred 
(but not necessarily mandatory) set of default dependencies. But mostly (at 
least going by my own experience during a few dozen test installations I did 
in the last days) it's a matter of taste and personal preference. That's the 
up- and the downside in providing freedom of choice, in a nutshell. :)

Best regards
Urban

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

[DNG] IMPORTANT! How to fix degraded session management after Devuan ASCII upgrade.

[Irrwahn]

PLEASE NOTE: 
  The following only applies to already existing ASCII systems that got 
upgraded to the newest package versions as present in the repositories. 
Fresh installations of Devuan ASCII 2.0.0 Beta should not be affected.

TL;DR
-
Make sure you got the correct libpolkit-backend installed!

Background
--  
  It would appear that under certain circumstances an unsuitable flavor 
of libpolkit-backend-1-0- gets pulled in upon upgrade. This can lead 
to a temporary loss of desktop session related functionality, namely the 
ability to user-mount removable drives or to shutdown/restart the system 
using the GUI controls provided by the respective desktop environment. The 
issue was ultimately caused by the recent addition of elogind to the 
repositories, or rather the repackaging of policykit-1 that followed suit.

Resolution
--
1. Make sure you have at least one of (traditional) consolekit or (new)
   elogind installed. (Note: You can have both installed and active; which 
   one is actually used however is decided by which libpolkit-backend you 
   choose to install, see 4.)

2. Make sure (at least one of) the above is activated. You may do so by
   interactively running the 'pam-auth-update' command as root.

3. Ensure the following packages got installed:
 policykit-1  0.105-18+devuan2.4
 libpolkit-agent-1-0  0.105-18+devuan2.4
 
4. Install one of the mutually exclusive policykit backend libs, i.e.
   - EITHER -
 libpolkit-backend-1-0-elogind  0.105-18+devuan2.4  and
 libpolkit-gobject-1-0-elogind  0.105-18+devuan2.4

   - OR -
 libpolkit-backend-1-0-consolekit   0.105-18+devuan2.4  and
 libpolkit-gobject-1-0-consolekit   0.105-18+devuan2.4

   depending on which session manager backend you intend to use, see 1.

   In case you find you have a backend with -systemd in the name installed:
   that one will _not_ work, and is most likely the cause why things went 
   sideways in the first place.

5. After making changes to the session management you should either reboot 
   the system or at least cycle through runlevel 1.

Note:  Depending on what login manager you use in conjunction with which 
desktop environment you might have to experiment a bit to find out which 
of consolekit or elogind works best for you (or works[TM] at all).


Bottom line: As always in life, keep your backends covered. ;-)

HTH, HANVD, and enjoy the ASCII Beta!

Best regards
Urban

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

Re: [DNG] Devuan ASCII 2.0.0 Beta released

[Irrwahn]

Stefan Mark wrote on 14.02.2018 10:55:
> On Wed, 14 Feb 2018 10:48:20 +0100
> Veteran Unix Admins  wrote:
> 
>> **Devuan 2.0 ASCII Beta at:**
>> http://files.devuan.org/devuan_ascii
>>   
> 404 :)
> I think its https://files.devuan.org/devuan_ascii_beta/

Yes.  8^)

And @all: 
Please keep in mind this is a _beta_, so we will inevitably hit 
some bumps along the ride.

Best regards
Urban

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

Re: [DNG] Devuan ASCII 2.0.0 Beta released

[Irrwahn]

Happy VUAlentine's Day, Devuan!   :)

May you manifold and spread all the love 
that dedicated people put into you!


Urban
-- 
Sapere aude!


Veteran Unix Admins wrote on 14.02.2018 10:48:
> 
> Dear dev1rs
> 
> the Veteran Unix Admins salute you!
> 
> On February 14th 2015, Devuan unveiled a "pre-alpha" Valentine release
> of Devuan Jessie [1] just a few months after the Veteran Unix Admins
> declared their intention to fork Debian on November 27th 2014 [2].
> That was the beginning of our collective journey. Now, three years
> later, Valentine's day has more love for the Devuan community.  The
> long-awaited release of Devuan 2.0 ASCII Beta (minor planet nr. 3568)
> is here!
> 
> ## So what's new in Devuan 2.0 ASCII Beta?
> 
> - OpenRC is installable using the expert install path
>(thanks Maemo Leste!)
> 
> - eudev has replaced systemd-udev (thanks Gentoo!)
> 
> - elogind has been added as an alternative to consolekit
>   (thanks Gentoo!)
> 
> - Desktop users can choose among fully functional XFCE (Default), KDE,
>   Cinnamon, LXQT, MATE, and LXDE desktops
> 
> - CLI-oriented users can select the "Console productivity" task that
>   installs a fully-featured set of console-based utils and tools.
> 
> - A .vdi disk image is now provided for use with VirtualBox.
> 
> - ARM board kernels have been updated to 4.14 and 4.15 for most
>   boards.
> 
> ## Devuan 2.0 ASCII Stable is on the horizon
> 
> Although Devuan 2.0 ASCII Beta has been powering thousands of servers
> and desktops for the last two years and been extensively tested by the
> Devuan community, it is being released as a beta because at Devuan we
> value involvement and feedback. So we want even more extensive testing
> of Devuan 2.0 ASCII Beta to confirm "when it is ready" to be called a
> Stable release.
> 
> Once Devuan 2.0 ASCII Stable is released, our efforts will turn to
> Devuan 3.0 Beowulf (minor planet nr. 38086).
> 
> ## Download Devuan 2.0 ASCII Beta
> 
> **Devuan 2.0 ASCII Beta at:**
> http://files.devuan.org/devuan_ascii
>   
> **Devuan 2.0 ASCII Beta is available for amd64 and i386 in the
>   following flavours:**
> 
>  - installable live CD/DVD
>  - installation CD/DVD
>  - NETINST CDROM
>  - installable minimal live 
>  - qcow/vagrant images
> 
> **ARM:**
> https://files.devuan.org/devuan_ascii/embedded/README.txt
> 
> **Virtual machines:**
> https://files.devuan.org/devuan_ascii/virtual/README.txt
> 
> ## Upgrade to Devuan 2.0 ASCII Beta
> 
> Devuan 2.0 ASCII Beta provides safe upgrade paths from Devuan 1.0
> Jessie, Debian 8.x Jessie, Debian 9.x Stretch. Just follow the
> relevant instructions at:
> https://devuan.org/os/documentation/dev1fanboy/migrate-to-ascii
> https://devuan.org/os/documentation/dev1fanboy/upgrade-to-ascii
> 
> ## Feedback (we love that!)
> 
> If you try to install Devuan 2.0 ASCII Beta from a DVD or CD setup
> please test it offline (i.e., without a network connection and without
> a configured mirror). If something goes wrong please try it online
> (i.e., with a network connection and a configured mirror).  And then
> please report your findings to us including the list of packages as
> given by `dpkg -l | gzip -9 > packagelist.gz` and the output of `cat
> /var/lib/pam/session > pamconfig.txt`
> 
> Please get in touch with us through one of the community channels
> listed below or on freenode #devuan-dev for real-time interaction.
> 
> ## Information and contacts
> 
> Web: http://www.devuan.org
> Forum: http://dev1galaxy.org
> BTS: http://bugs.devuan.org
> IRC: #devuan (freenode)
> 
> Journalists please note: this announcement of Devuan 2.0 ASCII Beta 
> release is mainly for internal testing not for wide redistribution.
> An announcement for the Devuan 2.0 ASCII Stable release  will 
> hopefully follow very soon.
> 
> happy hacking!
> 
> The dev1 team
> 
> [1] You can find an archive of the pre-alpha Valentine release message here:
> https://lists.dyne.org/lurker/message/20180213.205150.929bbd85.en.html
> [2] https://devuan.org/os/debian-fork/
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

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

Re: [DNG] Install one package from Ceres

[Irrwahn]

Hendrik Boom wrote on 14.02.2018 03:05:
> On Tue, Feb 13, 2018 at 03:39:18PM +0100, Irrwahn wrote:

[...]
>> Modulo any pinning you may have in place, you will still have to use 
>> the -t option.
> 
> Just wondering -- what would keep it from using the ceres packages when 
> I don't specify -t ceres?  Doesn't it normally use the newest pckages 
> from the ones specified in sources.list?
[...]

For some reason or another I was thinking "experimental" instead of 
"unstable".  Brain fart, my bad. :)

Best regards
Urban
-- 
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Install one package from Ceres

[Irrwahn]

Hendrik Boom wrote on 13.02.2018 15:22:
> How do I install one package from Ceres? Together with its necessary 
> dependencies, of course.
> 
> I run an ascii system.
> 
> Do I really have to switch my sources.list to Ceres, install it, and 
> then switch it back to ascii?

Not switch, but temporarily amend, e.g. by adding:

deb  https://pkgmaster.devuan.org/merged unstable main 

to /etc/apt/sources.list , followed by "apt-get update".

> 
> Just specifying the -t ceres on the apt-get command didn't work:
> 
> root@notlookedfor:/home/hendrik# apt-get install -t ceres libsdl2
> Reading package lists... Done
> E: The value 'ceres' is invalid for APT::Default-Release as such a 
> release is not available in the sources
> root@notlookedfor:/home/hendrik# 

Modulo any pinning you may have in place, you will still have to use 
the -t option.

HTH
Best regards

Urban

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

Re: [DNG] dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument

[Irrwahn]

J. Fahrner wrote on 13.02.2018 14:55:
> Am 2018-02-13 13:50, schrieb Irrwahn:
>> That message can safely be ignored.
>>
>> This is caused by the dbus startup from script(s) /etc/X11/Xsession.d/ 
>> .
>> It basically means that dbus did not find systemd upon launch, which is
>> to be expected on a Devuan system that by definition comes w/o systemd.

[ Nota bene: *Every* *single* Devuan installation in existence that has 
  the dbus-x11 package installed will throw this info message. ]
 
> I know most scripts and config files come from Debian, and the Devuan 
> devs don't want to touch every package containing such systemd 
> directives. But wouldn't it be nice to have a patch-script, which 
> locates all known files containing "systemd" and patches them to remove 
> this systemd stuff after installation?
> 

Please feel free to correct me, but I don't believe it's that simple.
First off, someone would have to locate all these instances, and verify 
it's safe to patch them, and how, and keep that list up to date and 
operational on each iteration of every affected package, all while taking 
into account any possible cross-package side effects. Secondly, that 
script would have to be run after every system upgrade, no matter how 
minor or trivial.

But for the sake of argument let's assume some volunteer (maybe you? :-)) 
stepped up to maintain such a beast: What would be the benefit gained by 
it? Avoiding some benign informational log messages? Sorry, but that 
makes a spurious argument:  If I've received even only the fraction of a 
penny for each bogus message cluttering up ~/.xsession-errors, or any other 
log file for that matter, my only worry in life would be how to defend my 
then-own private island against the rising sea level. ;-)  Or, attacking 
from another angle, if I were to file a bug report for every such incident 
I'd already be blacklisted for flooding the bug trackers.

AIUI(!) it's Devuan's mission to provide an universal operating system 
offering its users as much freedom of choice as _reasonably_ feasible, not 
to eradicate each and every verbatim reference to some specific software 
package. 

Heck, going by my observations there isn't ATM even enough manpower to 
strip all affected packages from 'real' dependencies on libsystemd0! (And, 
at least to me, it's not yet crystal clear if in the end that would even 
be desirable - go figure!)

Of course all that 2ct worth drivel reflects just my personal point of view, 
YMMV, and all the other usual disclaimers apply.

HAND, with best regards

Urban

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

Re: [DNG] dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument

[Irrwahn]

J. Fahrner wrote on 13.02.2018 13:30:
> My .xsession-errors has the following warning
> 
> dbus-update-activation-environment: systemd --user not found, ignoring 
> --systemd
>   argument
> 
> Any ideas what's causing this? Is there some wrong config file around?

That message can safely be ignored.

This is caused by the dbus startup from script(s) /etc/X11/Xsession.d/ .
It basically means that dbus did not find systemd upon launch, which is 
to be expected on a Devuan system that by definition comes w/o systemd.

HTH
Best regards

Urban

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

Re: [DNG] Error when upgrading eudev

[Irrwahn]

J. Fahrner wrote on 12.02.2018 18:18:
> Am 2018-02-12 18:12, schrieb KatolaZ:
>> On Mon, Feb 12, 2018 at 06:07:01PM +0100, J. Fahrner wrote:
>>> Am 2018-02-12 03:21, schrieb Alessandro Selli:
  You will probably be able to work out this problem issuing the following
 command:

 apt-get -y install libpolkit-agent-1-0 policykit-1

>>>
>>> That worked, but throws some errors:
>>>
>>
>> It's not throwing any error. apt is just resolving a dependence that
>> entails upgrading packages with modified deps. When apt is done, your
>> system should not have any held or unconfigured package.
>>
>> Please double-check by ensuring that:
>>
>>   # apt-get -f install
>>
>> does nothing at all.
> 
> Yes, apt-get -f install does nothing after that upgrade.

Good.

> But is it wanted, that this upgrade of polkit installs 
> libpolkit-backend-1-0-systemd???

No, it is not.  It's a bug.  Or rather a glitch I'd call it.
(See my reply on the other sub-thread.)

Best regards
Urban

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

Re: [DNG] Reboot through a ConsoleKit DBus message as user

[Irrwahn]

J. Fahrner wrote on 12.02.2018 18:08:
> Am 2018-02-12 16:35, schrieb Irrwahn:
>>> $ dpkg -l | fgrep libpolkit-backend
>>> rc  libpolkit-backend-1-0:i3860.105-9+devuan1
>>> i386 PolicyKit backend API
>>> ii  libpolkit-backend-1-0-systemd:i3860.105-18+devuan2.4
>>   ^
>> Now, there's your problem! :)
>>
>> You should have one of:
>>  libpolkit-backend-1-0-elogind
>> or, probably more fittingly in your case:
>>  libpolkit-backend-1-0-consolekit
>> installed.
> 
> Cause is the recent polkit update:

As I suspected. The glitch that I was referring to up-thread manifests 
in libpolkit-backend-1-0-systemd and libpolkit-gobject-1-0-systemd
being installed by apt-get, instead of one of their respective *-elogind 
or *-consolekit counterparts. I will contact the packager about possible 
ways to prevent this, as the *-systemd backend is basically useless in
Devuan.

> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following additional packages will be installed:
>libpolkit-backend-1-0-systemd libpolkit-gobject-1-0-systemd
> The following packages will be REMOVED:
>libpolkit-backend-1-0 libpolkit-gobject-1-0
> The following NEW packages will be installed:
>libpolkit-backend-1-0-systemd libpolkit-gobject-1-0-systemd
> The following packages will be upgraded:
>libpolkit-agent-1-0 policykit-1
> 2 upgraded, 2 newly installed, 2 to remove and 0 not upgraded.
> Need to get 162 kB of archives.
> After this operation, 147 kB disk space will be freed.
> Get:1 http://pkgmaster.devuan.org/merged ascii/main amd64 policykit-1 
> amd64 0.105-18+devuan2.4 [59.8 kB]
> Get:2 http://pkgmaster.devuan.org/merged ascii/main amd64 
> libpolkit-agent-1-0 amd64 0.105-18+devuan2.4 [22.1 kB]
> Get:3 http://pkgmaster.devuan.org/merged ascii/main amd64 
> libpolkit-gobject-1-0-systemd amd64 0.105-18+devuan2.4 [38.5 kB]
> Get:4 http://pkgmaster.devuan.org/merged ascii/main amd64 
> libpolkit-backend-1-0-systemd amd64 0.105-18+devuan2.4 [41.4 kB]
> apt-listchanges: Reading changelogs...
> Fetched 162 kB in 0s (340 kB/s)
> dpkg: libpolkit-backend-1-0:amd64: dependency problems, but removing 
> anyway as you requested:
>   policykit-1 depends on libpolkit-backend-1-0 (>= 0.99).
> 
> Removing libpolkit-backend-1-0:amd64 (0.105-9+devuan1) ...
> Preparing to unpack .../policykit-1_0.105-18+devuan2.4_amd64.deb ...
> Unpacking policykit-1 (0.105-18+devuan2.4) over (0.105-9+devuan1) ...
> Preparing to unpack .../libpolkit-agent-1-0_0.105-18+devuan2.4_amd64.deb 
> ...
> Unpacking libpolkit-agent-1-0:amd64 (0.105-18+devuan2.4) over 
> (0.105-9+devuan1) ...
> 
> dpkg: libpolkit-gobject-1-0:amd64: dependency problems, but removing 
> anyway as you requested:
>   consolekit depends on libpolkit-gobject-1-0 (>= 0.94).
>   policykit-1-gnome depends on libpolkit-gobject-1-0 (>= 0.99); however:
>Package libpolkit-gobject-1-0:amd64 is to be removed.
>   colord depends on libpolkit-gobject-1-0 (>= 0.99).
>   network-manager depends on libpolkit-gobject-1-0 (>= 0.104); however:
>Package libpolkit-gobject-1-0:amd64 is to be removed.
>   upower depends on libpolkit-gobject-1-0 (>= 0.99).
>   udisks2 depends on libpolkit-gobject-1-0 (>= 0.101); however:
>Package libpolkit-gobject-1-0:amd64 is to be removed.
>   policykit-1 depends on libpolkit-gobject-1-0 (= 0.105-18+devuan2.4); 
> however:
>Package libpolkit-gobject-1-0:amd64 is to be removed.
>   libpolkit-agent-1-0:amd64 depends on libpolkit-gobject-1-0 (= 
> 0.105-18+devuan2.4).
> 
> Removing libpolkit-gobject-1-0:amd64 (0.105-9+devuan1) ...
> Selecting previously unselected package 
> libpolkit-gobject-1-0-systemd:amd64.
> Preparing to unpack 
> .../libpolkit-gobject-1-0-systemd_0.105-18+devuan2.4_amd64.deb ...
> Unpacking libpolkit-gobject-1-0-systemd:amd64 (0.105-18+devuan2.4) ...
> Selecting previously unselected package 
> libpolkit-backend-1-0-systemd:amd64.
> Preparing to unpack 
> .../libpolkit-backend-1-0-systemd_0.105-18+devuan2.4_amd64.deb ...
> Unpacking libpolkit-backend-1-0-systemd:amd64 (0.105-18+devuan2.4) ...
> Setting up libpolkit-gobject-1-0-systemd:amd64 (0.105-18+devuan2.4) ...
> Setting up libpolkit-agent-1-0:amd64 (0.105-18+devuan2.4) ...
> Setting up libpolkit-backend-1-0-systemd:amd64 (0.105-18+devuan2.4) ...
> Processing triggers for libc-bin (2.24-11+deb9u1) ...
> Processing triggers for man-db (2.7.6.1-2) ...
> Processing triggers for dbus (1.10.22-1+devuan1) ...
> Setting up policykit-1 (0.105-18+devuan2.4) ...
> Installing new version of config file /etc/pam.d/polkit-1 ...


Best regards
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Reboot through a ConsoleKit DBus message as user

[Irrwahn]

J. Fahrner wrote on 12.02.2018 16:22:
> Am 2018-02-12 16:04, schrieb Irrwahn:
>> Assuming you are on an ASCII system:
> 
> Yes.
> 
>> I strongly suspect this is linked to the recent addition of elogind
>> to the repositories and the consequential changes to policykit.
 

> I found a simpler way to make it work again on stackexchange (last 
> message):
> https://unix.stackexchange.com/questions/29637/how-do-i-shut-down-a-system-through-a-consolekit-dbus-message-as-user
> 
> But is this the right way to do this?

Yes. No. Maybe. As almost always when dealing with unixoid systems there 
is no one single right way to do a thing. Unless you use the broadest 
definition of the term, i.e.: "The right way is whatever works[TM] for me."

However, that having said (and IANAPKE[*]):
I suspect that the "ResultAny=yes" line in the linked SE thread could 
be considered a security hole at least by some. (I should probably not 
mention I used similar hacks in the past - alas, I just did. :P)

[*] I am not a policykit expert  ;o)

HTH
Best regards
Urban

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

Re: [DNG] Reboot through a ConsoleKit DBus message as user

[Irrwahn]

J. Fahrner wrote on 12.02.2018 16:19:
> Am 2018-02-12 16:05, schrieb Hleb Valoshka:
>> What Devuan version do you run? Ascii, don't you?
> 
> Yes, ascii.
> 
>> Show output of dpkg -l | grep libpolkit-backend
> 
> $ dpkg -l | fgrep libpolkit-backend
> rc  libpolkit-backend-1-0:i3860.105-9+devuan1
> i386 PolicyKit backend API
> ii  libpolkit-backend-1-0-systemd:i3860.105-18+devuan2.4   
  ^
Now, there's your problem! :)

You should have one of:
libpolkit-backend-1-0-elogind
or, probably more fittingly in your case:
libpolkit-backend-1-0-consolekit
installed.
Please refer to my earlier answer up-thread for more details.

Please allow me a side note, directed at all readers:
I assume we will see some more glitches like that happening upon 
updating Ascii systems in the near future.  Please remember: 
As solid as it may appear, Ascii is a yet unreleased testing suite, 
so some breakage should be expected anytime!

Best regards
Urban

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

Re: [DNG] Reboot through a ConsoleKit DBus message as user

[Irrwahn]

J. Fahrner wrote on 12.02.2018 15:41:
> Hi,
> I have a small python gui script rebooting,shutdown,suspend. This sends 
> dbus messages to consolekit and is no longer working since a recent 
> update.
> 
> Rebooting is done as:
> 
> $ dbus-send --system --print-reply --dest='org.freedesktop.ConsoleKit' 
> /org/freedesktop/ConsoleKit/Manager 
> org.freedesktop.ConsoleKit.Manager.Restart
> Error org.freedesktop.ConsoleKit.Manager.NotPrivileged: Not Authorized
> 
> Any ideas what change recently caused this non-functioning? And how make 
> it work again?

Assuming you are on an ASCII system:

I strongly suspect this is linked to the recent addition of elogind
to the repositories and the consequential changes to policykit.

In order to regain "classic" consolekit operation you may try the 
following recipe:

1. Make sure the following packages are installed in their respective 
   most recent versions:
consolekit
policykit-1
libpolkit-backend-1-0-consolekit

2. Run pam-auth-update in a root console and make sure that elogind 
   is disabled and consolekit is enabled, leaving all other options 
   as they are.

3. Reboot, or at least cycle through runlevel 1 and back to 2.

To switch back to elogind, if you so desire, you basically revert 
steps 1. and 2.: Install libpolkit-backend-1-0-elogind and enable 
it with pam-.auth-update, disabling consolekit at the same time.

BTW, if you only used your script to fix a previous loss of GUI 
functionality WRT to shutdown, you may find that with elogind most
(if not all) desktop environments should now have (re-)gained that 
capability. Of course, this obviously only applies if you're using 
any prepackaged DE at all.

HTH
Best regards
Urban

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

Re: [DNG] Minor Ascii upgrade fixes ?

[Irrwahn]

dev wrote on 06.02.2018 16:28:
> 
> 
> On 02/06/2018 09:15 AM, Irrwahn wrote:
>> In xfce4-terminal:  Right click --> Preferences --> Colors.
> 
> Thanks, this is great for setting the terminal colors but I don't see a
> way to change the "window frame" color: https://imgur.com/a/bedWL
> 
> Is this perhaps an Openbox setting?
> 

Window decorations are the window manager's business. So, yes, in your 
case that would presumably be openbox, or rather the theme you told it 
to use. Beware that most themes are broken for GTK-3. I'm not sure 
however if xfce4-terminal is GTK-2 or GTK-3.
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Minor Ascii upgrade fixes ?

[Irrwahn]

dev wrote on 06.02.2018 16:03:
[...]
> * I'm running xfce-terminal on LXDE. Anyone know how to change the
> terminal color scheme? I thought xfce4-appearance-settings
> would do, but I have "dusk" selected and the terminal is still
> white: https://imgur.com/a/v8hHd

In xfce4-terminal:  Right click --> Preferences --> Colors.
Most (all?) terminal emulators maintain their own color scheme, 
independent of the general desktop settings. And IMHO thankfully 
so, I might add.

[...]
> * whenever I get an IM in Pidgin, my volume goes to 100% when the
> notification sound is played. Uh.. anyone heard of this issue?:
> https://imgur.com/a/fNn7t
> 
>  I seem to have more pulse stuff installed than before:
> 
>   $ aptitude search pulse | grep ^i
>   i  apulse - PulseAudio emulation for ALSA
>   i A gstreamer1.0-pulseaudio - GStreamer plugin for PulseAudio
>   i  libpulse-mainloop-glib0 - PulseAudio client
>libraries (glib   support)
>   i  libpulse0 - PulseAudio client libraries
>   i A libpulsedsp - PulseAudio OSS pre-load library
>   i A pulseaudio - PulseAudio sound server
>   i A pulseaudio-utils - Command line tools for the PulseAudio
>   sound  server
>   i A xfce4-pulseaudio-plugin - Xfce4 panel plugin to control pulseaudio
[...]

Seems you have full pulseaudio installed now. If you want to (or 
possibly have to, due to dependencies) keep it you could install the 
pavucontrol package which lets you (among other things) fine-tune the 
volume settings on an per-application level.

Can't really comment on your other issues though, sorry.

HTH, best regards
Urban

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

Re: [DNG] desktop screen recording with sound?

[Irrwahn]

dev wrote on 02.02.2018 16:23:
[...]
> The 14.04 PPA 
[...]10:2.6.5-dmo1 
[...]

Dev, 

please forgive me if may appear rude, but that looks like a terrible 
Frankenmess! You'd probably be much better off updating your Devuan 
Jessie to Devuan Ascii, which offers SimpleScreenRecorder. (BTW, I 
just tried it and already like it much better than recordmydesktop; 
will probably stick to it.)

Of course: 
  Only my 2ct, grain of salt, YMMV, disclaimer yadda-yadda, etc.pp.

Best regards
Urban

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

Re: [DNG] solved, Re: upgraded to Ascii, but now sqwebmail isn't working

[Irrwahn]

Gregory Nowak wrote on 01.02.2018 00:09:
> On Tue, Jan 30, 2018 at 05:03:54PM -0700, Gregory Nowak wrote:
>> The bad news is that now sqwebmail isn't working, and it still did
>> after my upgrade to jessie.
> 
> I have this solved thanks to a tip from the courier-sqwebmail
> listwhich pointed me in the right direction.
[...]
> This is a major show stopper, and should be filed as a bug if it isn't
> already. Can I file this in devuan's bug tracker, or do I need to
> install debian stretch, and file the bug from there against debian's
> bug tracker (if it isn't filed already)?
[...]

Since this pertains to a package that Devuan pulls from Debian unaltered
you should file the bug against the Debian package (if it hasn't already, 
as you wrote). However, I do not see why you'd have to install Stretch
for that?  AFAIK, you can still file a bug the "classic" way by email, 
no need to use reportbug.  Cf. https://www.debian.org/Bugs/Reporting

HTH, best regards
Urban

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

Re: [DNG] desktop screen recording with sound?

[Irrwahn]

dev wrote on 31.01.2018 17:24:
> 
> 
> On 01/31/2018 09:15 AM, Irrwahn wrote:
> 
>>
>> As you seem to have pulseaudio (at least partially) installed
> 
> Thanks, I think some of it was required for the apulse package in
> firefox. Not sure.
> 
>> try to set the audio source to "pulse" in recordmydesktop. Though I have 
>> no idea if that would actually work with apulse. (It does on my system 
>> with pulseaudio fully installed, FWIW.)
(That was badly worded by me: It works with pulse for me, not apulse.)

> Thanks. Still no luck :/

Too bad. Did you actually start it like "apulse recordmydesktop"? AIUI, 
that's how apulse is supposed to work with any application it supports.
(NB: I'm flying blind, as I never used apulse myself, just trying to 
make an educated guess.)

> I use virt-manager which seems to have a dep (god, why?) on
> libpulse-mainloop-glib0 and libpulse0 so can't uninstall those.

It seems to get pulled in via a dependency on libgvnc. 

Best regards
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] desktop screen recording with sound?

[Irrwahn]

dev wrote on 31.01.2018 15:40:
> I have some online classes which are Flash based "webinars" that I'd
> like to save for viewing on my train/bus commute. gtk-recordmydesktop
> works for the video part but I can't record any audio. I'm using
> straight ALSA on my Devuan system and tried setting gtk-recordmydesktop
> audio option to PCM and DEFAULT but no good.
[...]

As you seem to have pulseaudio (at least partially) installed, you could 
try to set the audio source to "pulse" in recordmydesktop. Though I have 
no idea if that would actually work with apulse. (It does on my system 
with pulseaudio fully installed, FWIW.)

HTH, best regards
Urban

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

Re: [DNG] raspberry pi 3

[Irrwahn]

Hendrik Boom wrote on 20.01.2018 20:33:
> I gather from the extracts provided by the spam sites Google thinks are 
> relevant to devuan that there is a devuan for the Raspberry Pi.
> 
> Where do I find it?  How do I install it?  Can I install and try out 
> Ascii?  or just Jessie?

Hendrik, 

there are no official images or installation media available for ASCII yet.
But you might want to have a look at
   https://devuan.smallinnovations.nl/?dir=devuan_jessie/embedded
(mirror of files.devuan.org, more mirrors listed at devuan.org main page).

Upgrading from Jessie to ASCII should essentially be a matter of editing
/etc/apt/sources.list, followed by apt-get update; apt-get dist-upgrade.

HTH, Regards
Urban

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

Re: [DNG] googling devuan ascii leads to spam sites

[Irrwahn]

Hendrik Boom wrote on 20.01.2018 20:31:
> I googles "devuan ascii" today and in the top few finds there were three 
> spam sites -- sites which either jut advertised expensive junk, or else 
> pretended to be my ISP doing a survey and as a reward offering 
> expensive junk such as (probably fake) testosterone supplements.
> 
> At this point the power went out, so I didn't get to see if there were 
> more.
> 
> The brief excerpts Google presented before I clicked  on links were 
> legitimate-looking quotes from Devuan sites, listing things like the 
> platforms devuan runs on and so forth.
> 
> Somehow the spammers have manages to out-SEO the legitimate Devuan 
> sites.  It's not making it easy for newcomers to find us.
> 
> Ugly.

Interesting. Motivated by your message I searched the web for devuan 
ascii (without quotes!), using Ecosia, DuckDuckGo, bing, StartPage, 
Google (yuck!) and, what the heck, even Yahoo, and in all cases the 
top hits were more or less relevant to Devuan. A lot of those referred 
to instructions on how to upgrade from jessie to ASCII. The results 
may be skewed though, as I probably get .de versions of the pages, but 
curious nonetheless.

Regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Hleb Valoshka wrote on 19.01.2018 20:44:
> On 1/19/18, Irrwahn <irrw...@freenet.de> wrote:
>> I think that has to be done anyway, because currently one cannot
>> have policykit without having consolekit installed with it, due to
>> the "Depends". The package should have something akin to:
>>
>>   Depends: libpam-elogind | consolekit
>>
>> Anyone up for the task?
> 
> As it has been already told this task is not about of mere package rebuilding.
> 
> But if you are in mood for testing, you can download from [1]
> policykit built with elogind support (consolekit support is dropped as
> it supports only one) and repeat your test. It was built in ascii
> chroot so it's installable both in ascii & ceres.
> 
> Repository with its source is at [2]. The branch is based on
> suites/ascii-proposed.
> 
> 1. https://mega.nz/#!lEVXUY6R!5MJOEEAtSadvwkv27tAPZguuYh0kRI8TVh-OL0VEj5Q
> 2. https://git.devuan.org/375gnu/policykit-1/tree/elogind-support

Great, thanks a bunch Hleb!

* Installed your packages over already present policykit, leaving elogind 
  in place.

* Was able to purge consolekit2 after that, without dragging policykit with 
  it, as I expected.

* Shutdown/Restart from XFCE GUI is now working correctly!

* USB drive user mount in Thunar is now working! (Admittedly, in the meantime 
  I had added udisks2 and related stuff, but that only made the drive show up
  automagically. Mounting it as user was still prohibited unless I installed 
  your reconfigured policykit.)

* "loginctl reboot" from VT now working!
  (Despite still spewing a slightly irritating message; console transcript
   follows:)

 urban@vbascii2:~$ loginctl reboot
 System is going down for reboot NOW!
 Failed to reboot system via elogind: Message recipient disconnected from 
message bus without replying
 urban@vbascii2:~$
 Broadcast message from root@vbascii2 (console) (date yadda-yadda):
 The system is going down for reboot NOW!
 INIT: Switching to runleve: 6
 INIT: Sending processes the TERM signal
 Removed session 2.
 etc. pp. (the usual runlevel change sermon)
   
   I guess that could be an artifact of the shutdown method used by elogind?

All in all, I think that looks somewhat promising. However, as KatolaZ rightly 
pointed out, it'd be important to know which other setups would possibly be 
broken by that approach, and what issues in other DEs might still persist.
Given the clusterf^W glorious goodness that all these kits'n'kats constitute,
I doubt it would be possible for it to make it in an ascii release proper —
unless an armada of people step forward to volunteer for smoke testing this in 
each and every conceivably sane DE configuration. (I, for one, am however 
tempted to actually use it on my actual desktop system, provided it ever hits 
at least the experimental repository.)

Thanks again for going to such lengths, and best regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

KatolaZ wrote on 19.01.2018 19:05:
> On Fri, Jan 19, 2018 at 06:48:42PM +0100, Irrwahn wrote:
> 
> [cut]
> 
>>
>> In my mind, the whole mess looks more like a gigantic game of nuclear 
>> whack-a-mole, and the only winning move is not to play. (The optimist
>> believes we are living in the best of all possible worlds. The pessimist 
>> is afraid the optimist is right. Guess, which faction I belong to. ;^)
>>
>> But honestly, KatolaZ, thanks for damping my enthusiasm. :)
>>
> 
> Dear Urban, it was not my intention to damp your enthisiasm, at all,
> so please accept my apoligies if I did :\

Oh, no need to apologize! I guess my message read far more ironic, or 
even sarcastic, than I intended. I was trying to convey my sincere 
thanks for putting everything in perspective. Alas, English is not my 
native tongue, plus I'm German, and us being direct is a prejudice 
that oftentimes turns out to be true.  ;o)

> 
> We need a lot of enthusiasm. And we also need to test this stuff in as
> many different setups as possible, before deciding what's next,
> IMHO. The help of all the knowledgeable people who are working on that
> is very much appreciated :)

Oh, I wasn't discouraged by your input, no worries, please. :)

> TBH, it would be great if at the end of those tests we could have a
> summary that explains what are the issues, what are the possible
> solutions, and what we can do to help implementing them without
> breaking too much stuff around ;)

And I'll continue to contribute whatever my time and capabilities allow 
to reach that goal. After all, Devuan was the last straw that kept me 
from ditching GNU/Linux altogether in the wake of the systemd meltdown.
[rant] But, honestly, the *BSDs are not the best alternative when it 
comes to desktop systems; server installations are another cup of tea, 
but that's (no longer) my main concern right now. [/rant]

Best regards
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

KatolaZ wrote on 19.01.2018 17:36:
> On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote:
>> [...], because currently one cannot 
>> have policykit without having consolekit installed with it, due to 
>> the "Depends". The package should have something akin to: 
>>
>>   Depends: libpam-elogind | consolekit
>>
>> Anyone up for the task?
>>
> 
> Urban, it's not just a matter of recompiling a single package. It is
> more about knowing how such a change would impact the whole
> distribution, and desktop-things in particular. 
> 
> So before we rush into "remove that dep...oh no add that other one
> instead...oh no, let's replace this component with a brand-new one
> which does not exist yet..." we must know exactly where we want to go,
> how to get there, and if the trip is worth the effort at all.

Yeah, I'm beginning to grasp how deeply intertwined this entire
hairball is. Either things used to be much easier in the past, or 
I've become substantially dumber. (Probably both. :P)

> Having elogind and consolekit2 in experimental is all about trying to
> see if some of the few glitches on the Devuan desktop can be easily
> solved. IMHO, this does not mean that we must solve *all* of those
> glitches, especially because the same concept of "session" (which is
> the root of all this evil) looks at best badly defined, if not totally
> bogus.

I agree, but as is, for elogind to be of any use, policykit must be 
installable independently of consolekit(2). Or maybe I completely 
misinterpreted the whole situation, which is absolutely possible —
in which case I apologize for the noise.

> We don't necessarily have to follow the white rabbit into its dark
> hole, especially because there is a high probability that the rabbit
> will turn into a snake. We have the option to stay outside and enjoy
> the sun...

In my mind, the whole mess looks more like a gigantic game of nuclear 
whack-a-mole, and the only winning move is not to play. (The optimist
believes we are living in the best of all possible worlds. The pessimist 
is afraid the optimist is right. Guess, which faction I belong to. ;^)

But honestly, KatolaZ, thanks for damping my enthusiasm. :)

Best regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Adam Borowski wrote on 19.01.2018 15:56:
> On Fri, Jan 19, 2018 at 02:17:28PM +0100, Irrwahn wrote:
>> I think that has to be done anyway, because currently one cannot 
>> have policykit without having consolekit installed with it, due to 
>> the "Depends". The package should have something akin to: 
>>
>>   Depends: libpam-elogind | consolekit
>>
>> Anyone up for the task?
> 
> You would have to change policykit to allow runtime detection of logind vs
> consolekit.  Currently it can be compiled only one way or the other.

Oh, crud! Nothings ever easy. Having two versions of policykit 
probably would be an even worse idea, wouldn't it?

> The dbus API is incompatible.  Both can coexist, but it's a bad idea to have
> consolekit be unaware of sessions handled by logind -- thus, if you want to
> keep consolekit alive, it'd better to implement logind API, as that's what
> the desktop environments ecosystem moved to.

I somehow doubt there's a lot of capable people willing to 
do it. Of course, I'd be happily proven wrong on that account.

> 
> Devuan doesn't (currently?) support non-Linux kernels, but Debian/kfreebsd
> and Debian/hurd guys would thank you for this.

Hm, that increases the chances again, I guess. 

> 
> On the other hand, I have doubts whether logind or consolekit are the best
> approaches.  The more I look at them, the more I boggle about the
> pointlessness of the whole concept of "sessions": with systemd, you can't
> have more than one GUI session; when a GUI session is on, ssh-ing in lets
> you access all resources that are supposed to be restricted to that GUI
> session; switching to another VT stops music from playing (because
> security).  Thus, if you drop things we don't want, it all boils down to
> "does this user have a locally logged in session?".  Type "who" and here's
> your answer.  It would be possible to have a thin stub that answers dbus
> requests with standard POSIX backends, or similar non-NIH tools like
> pm-suspend.

[Rant]
Honestly, I'm already close to the point to kick all that session bullshit 
to the curb, and go back to startx or the like to bring up a graphical
environment, and sudo-mount my thumbdrives, or whatever. And before anyone 
cries "but, but, but security": there are much, much more serious security 
holes to plug, besides me running X as root on my @/)%$$ desktop!)
[/Rant]

> 
> Such a stub would lose that "fast user switching" feature, but come on -- we
> live in a many computers per person world, rather than many persons per
> computer as it was the case in the past.  Thus, my idea would have the
> following assumptions:
> * someone with physical access can always shutdown/reboot the machine: if
>   the software disagrees, there's a big button and a small one close to it,
>   if even that fails, there's a power cord (or a laptop battery).  Kiosks
>   are about the only cases to the contrary, and they already restrict you
>   from issuing a "shutdown" command anyway.
> * multiple remote users are an important use case, both for command-line and
>   GUI (vnc/...) logins
> * conversely, multiple local users don't matter anymore: everyone has
>   multiple screen-attached computers.  Note the name: _personal_ computer.
>   When I say this, someone always responds with "but sub-saharan
>   classrooms".  Nope: ages ago we had such a situation in our world, and
>   I don't remember a single case when kids had separate accounts where
>   they'd lock a session before passing the keyboard to their neighbour.
> Thus, I knowingly dismiss a valid use case as irrelevant, to buy us KISS.
> It's not so different from systemd: it disallows you to log in via vnc if
> you have a local session, which is an use case I did need in the past.

I wholeheartedly agree. I never were able to find a single person that 
used, lest relied upon, that multi-seat/multi-session pseudo-feature.
We've come a long way since 1984.

> 
> But, it's good to have elogind available, even if just for a transition.
> For starters, such an unix-logind doesn't exist yet.  Vapourware that I
> don't volunteer to write is quite a weak argument...
> (Compare the complete code of loginkit:
> https://github.com/dimkr/LoginKit/blob/jessie/loginkitd/loginkitd.c)

True dat. That's one, if not /the/, crucial point. I'd volunteer to 
support such an endeavor in whatever way I can, however writing stuff 
like that from scratch is currently beyond my capabilities, and would 
probably drive what's left of my sanity right over the edge (I've touched 
dbus before, will never touch that POC again!), so unfortunately I too 
have to pass on taking a lead role in that, sorry.

> 
> Meow!

Eek!

Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Hleb Valoshka wrote on 19.01.2018 13:28:
> On 1/19/18, Irrwahn <irrw...@freenet.de> wrote:
>> Scenario 1:
>> ---
>>  │ PAM profiles to enable:
>>  │
>>  │[*] Unix authentication
>>  │[*] Authenticate using SSH keys and start ssh-agent
>>  │[*] elogind Session Management
>>  │[ ] ConsoleKit Session Management
>>
>>   User loggind in via GUI:
>> * session is listed by loginctl
>> * Restart/Shutdown only logs out and leads back to lightdm greeter.
>>
>>   User logged in via VT:
>> * session is listed by loginctl
>> * "loginctl reboot": "Failed to reboot system via elogind:
>>   Interactive authentication required."
> 
> It seems to me that these issues are caused by policykit, in devuan it
> doesn't support logind (obviously) so it's unable to authenticate
> user's requests.

Yes, that appears to be the most likely explanation. 

> Maybe we need to rebuild it with support for elogind.

I think that has to be done anyway, because currently one cannot 
have policykit without having consolekit installed with it, due to 
the "Depends". The package should have something akin to: 

  Depends: libpam-elogind | consolekit

Anyone up for the task?

Best regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Andreas Messer wrote on 19.01.2018 07:16:
> That seems strange. loginctl is a elogind command and when elogind does not
> know about the session loginctl should reject or ask for auth. I'll dig into
> this a little bit more. Probably time to setup a vm.

So, I did a little more testing:

* Fresh ascii VM with lightdm and XFCE4; not tampered with.
* ConsoleKit is actually consolekit2 from experimental.
* VM was rebooted after each PAM configuration change.
* USB mass storage devices do not show up in Thunar at all, let 
  alone being user mountable - despite udisks2 being installed.
  (So, I definitely did something special on the other, older VM!)

Scenario 1:
---
 │ PAM profiles to enable:
 │
 │[*] Unix authentication
 │[*] Authenticate using SSH keys and start ssh-agent
 │[*] elogind Session Management
 │[ ] ConsoleKit Session Management

  User loggind in via GUI:
* session is listed by loginctl
* Restart/Shutdown only logs out and leads back to lightdm greeter.

  User logged in via VT:
* session is listed by loginctl
* "loginctl reboot": "Failed to reboot system via elogind:
  Interactive authentication required."


Scenario 2:
---
 │ PAM profiles to enable:
 │
 │[*] Unix authentication
 │[*] Authenticate using SSH keys and start ssh-agent
 │[ ] elogind Session Management
 │[*] ConsoleKit Session Management

  User loggind in via GUI:
* session not listed by loginctl
* Restart/Shutdown work as intended.

  User logged in on VT:
* session not listed by loginctl
* "loginctl reboot": complains (dbus service unavailable), but works!


Scenario 3:
---
 │ PAM profiles to enable:
 │
 │[*] Unix authentication
 │[*] Authenticate using SSH keys and start ssh-agent
 │[*] elogind Session Management
 │[*] ConsoleKit Session Management

  User loggind in via GUI:
* session is listed by loginctl
* Restart/Shutdown only logs out and leads back to lightdm greeter.

  User logged in on VT:
* session is listed by loginctl
* "loginctl reboot": asks to authenticate as root.


HTH, best regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Andreas Messer wrote on 19.01.2018 07:16:
> On Wed, Jan 17, 2018 at 09:26:59PM +0100, Irrwahn wrote:
>> Outcome is the same when logged in via a VT console, while elogind 
>> is fully enabled (and ck2 and pk installed). With elogind disabled 
>> (ck+pk only), no extra authentication is needed. 
> 
> That seems strange. loginctl is a elogind command and when elogind does not
> know about the session loginctl should reject or ask for auth.

And that would make a lot more sense. Maybe it has some kind of 
fallback implemented? After all, it's elogind, not sd-logind.

I sincerely hope we're actually debugging elogind, and not a 
setup I broke. In the course of the day I will probably find 
more time to invest in this.

Best regards
Urban

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

Re: [DNG] elogind available in experimental and ascii-proposed

[Irrwahn]

Didier Kryn wrote on 18.01.2018 11:34:
> Le 18/01/2018 à 11:22, Irrwahn a écrit :
>> Didier Kryn wrote on 18.01.2018 10:38:
>> [...]
>>>       Now it works. Will wait until consolekit2 is available, though, to
>>> make a more significant test. I'm using xfce4.
>> Didier,
>>
>> consolekit2 is available in experimental, installs cleanly in ascii.
>> Relevant sources.list line:
>>   deb http://pkgmaster.devuan.org/devuan/ experimental main
>      Thanks Urban.
> 
>      Fact is I posted my mail yesterday to you instead of dng - by 
> mistake, and it was rejected - and realized it today. And I sent it 
> today to the list.
> 
>      I'll do the test although haven't the time today.
> 
>      Best regards.
>                                          Didier

Oh, not actually rejected, I just found it in my spam folder. 
Anyway, you should be white-listed now, just in case. ;-)

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

Re: [DNG] elogind available in experimental and ascii-proposed

[Irrwahn]

Didier Kryn wrote on 18.01.2018 10:38:
[...]
> 
>      Now it works. Will wait until consolekit2 is available, though, to 
> make a more significant test. I'm using xfce4.

Didier,

consolekit2 is available in experimental, installs cleanly in ascii.  
Relevant sources.list line:
 deb http://pkgmaster.devuan.org/devuan/ experimental main

Best regards
Urban

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

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Hleb Valoshka wrote on 17.01.2018 20:54:
> On 1/17/18, Irrwahn <irrw...@freenet.de> wrote:
> 
>> * screen sessions killed on logout
>>   (regression, works with elogind disabled!)
> 
> This is because elogind is designed to be logind replacement (and
> actually shares its code) and so it's bug-for-bug compatible. Systemd
> uses cgroups to track processes and on logout kills all user's
> processes started during the session.

According to A. Messer this behavior can be changed in a configuration 
file.

> 
>> *  urban@vboxascii:~$ loginctl reboot
>>AUTHENTICATING FOR org.freedesktop.login1.reboot
> 
> This is incorrect behaviour. Required privileges should be granted
> automatically due to pam module, could you show your
> /etc/pam.d/session-common?
> 
> Oh, wait...
> 
>>Connection to 192.168.2.167 closed by remote host.
> 
> Remote connection, so this explains the previous message.
> 
> Can you repeat the same but with a local login?

Outcome is the same when logged in via a VT console, while elogind 
is fully enabled (and ck2 and pk installed). With elogind disabled 
(ck+pk only), no extra authentication is needed. 

However, I just finished debootstrapping a fresh ascii VM, and 
interestingly USB mounting with ck2 is broken again. Presumably I 
previously messed around with the older VM I made the tests with, 
possibly hacked open some polkit actions, or the like. Thus, the 
results I got must be taken with considerably more than just a grain 
of salt! OTOH, the reboot/shutdown sequences look the same as before,
i.e. requiring extra authentication.

HTH, regards
Urban
 -- 
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] elogind available in experimental and ascii-proposed

[Irrwahn]

Didier Kryn wrote on 17.01.2018 11:59:
> Le 15/01/2018 à 11:30, KatolaZ a écrit :
>> The package is now available in Devuan in "ascii-proposed"
> 
>      I've added this repository to my sources.list:
> deb http://pkgmaster.devuan.org/merged/ ascii-proposed main contrib non-free
> 
> Also added the following line to apt.conf, because synaptic refused to 
> read the repository:
> acquire::allowinsecurerepositories "yes";
> 
> Nevertheless, I can't see neither elogind, nor consolekit2

Uh? Aptitude sees it just fine (and I already installed it in a VM):

  Origin: None:2.0.0/ascii-proposed, Master:1.0.0/experimental [amd64]
  Origin URI: 
http://deb.devuan.org/devuan/pool/main/e/elogind/elogind_234.4-1+devuan1_amd64.deb

and

  Origin: None:2.0.0/ascii-proposed, Master:1.0.0/experimental [i386]
  Origin URI: 
http://deb.devuan.org/devuan/pool/main/e/elogind/elogind_234.4-1+devuan1_i386.deb

You might want to use interactive aptitude instead of synaptic.
Alternatively, you could perform a direct download via above URLs.
 
Ck2, OTOH, is not in the repositories yet, due to issues building 
it using c-i, AIUI.

As for the "allowinsecurerepositories" issue: is your devuan-keyring
package up-to-date?

HTH, best regards
Urban
-- 
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Help with Spectre and Meltdown

[Irrwahn]

marc wrote on 17.01.2018 07:27:
[...]
> * Stop running code which you don't trust. That comes in two forms:
> Don't enable javascript on your browser, and don't use cloud-based
> systems or virtual hosts. Those things you don't want to do anyway
> if you care about security. 
>   
> Not sure how Devuan could help with those, except maybe make sure
> that none of the web-based infrastructure (devgalaxy, etc) require
> javascript or maybe package up some of the firefox forks which
> are more security focused.

Which would essentially boil down to a list of three candidates: 
waterfox, icecat, or palemoon. 

My 2¢: Out of these, currently waterfox is my personal favorite, as 
palemoon started to fail me on several occasions, not being able to
reasonably render several web pages I use regularly. Didn't have 
much exposure to icecat, though.

Best regards
Urban
-- 
Sapere aude!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] elogind testing for experimental and ascii-proposed

[Irrwahn]

Andreas Messer wrote on 16.01.2018 22:24:
> since we have to test elogind now with various setups, KatolaZ asked me to
> write a short guide what needs to be tested. So here we go:
[snipped procedure]

I gave it a quick spin on my ascii VM with lightdm and XFCE:

1. Simply installing elogind caused no regressions, as expected.

2. With consolekit/policykit and elogind fully enabled:

  - lightdm+XFCE graphical login: 

* login, logout, poweroff, reboot, USB drive mount: 
   working (same as without elogind, or disabled elogind)

  - ssh console login:

* screen sessions killed on logout 
  (regression, works with elogind disabled!)

* ssh-agent killed on logout 
  (regression, not killed with elogind disabled!)

*  urban@vboxascii:~$ loginctl reboot
   AUTHENTICATING FOR org.freedesktop.login1.reboot
   Authentication is required for rebooting the system.
   Authenticating as: ,,, (urban)
   Password: 
   AUTHENTICATION COMPLETE
   Failed to reboot system via elogind: Message recipient disconnected
 from message bus without replying
   urban@vboxascii:~$ 
   Broadcast message from root@vboxascii (console) (Tue Jan 16 23:25:17 
2018):
   The system is going down for reboot NOW!
   Connection to 192.168.2.167 closed by remote host.

*  root@vboxascii:~# loginctl reboot
   Failed to reboot system via elogind: Message recipient disconnected 
 from message bus without replying
   root@vboxascii:~# 
   Broadcast message from root@vboxascii (console) (Tue Jan 16 23:52:22 
2018):
   The system is going down for reboot NOW!
   Connection to 192.168.2.167 closed by remote host.

3. No consolekit/policykit, only elogind installed and activated
   (not sure if that even makes any sense, but what the heck):

  -lightdm+XFCE graphical login: 

* login, logout: working

* GUI poweroff, reboot, USB mount: NOT working!

  - ssh console login:

* screen sessions and ssh-agent killed on logout

*  urban@vboxascii:~$ loginctl reboot
   Failed to reboot system via elogind: The name org.freedesktop.PolicyKit1 
 was not provided by any .service files
   

TL;DR: 
The only immediately noticeable regression caused by enabling elogind 
in this setup was detached background processes (screen, ssh-agent) 
being killed upon session termination; user mount, poweroff, and reboot 
worked as expected.

HTH, best regards
Urban

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

Re: [DNG] elogind available in experimental and ascii-proposed

[Irrwahn]

KatolaZ wrote on 15.01.2018 11:30:
> Dear D1rs,
> 
> as recently discussed, our Andreas Messer has worked on packaging
> elogind in the last few days. elogind is a replacement for the
> "logind" systemd component, maintained by the Gentoo folks, and should
> in theory allow packages which need libpam-systemd and logind services
> to be installed on Devuan without problems (and without requiring
> libpam-systemd itself)
> 
> The package is now available in Devuan in "ascii-proposed" and
> "experimental". Please test it extensively and report any issue on
> bugs.devuan.org.
[...]

I installed the package from ascii-proposed in an ascii VM without any 
problems. However, how would one go about actually testing it?  The 
system uses lightdm as the DM and XFCE as DE, but not much in terms of 
bells and whistles. Think of it as a radically stripped down version of 
my actual desktop kitchen-sink: 907 vs. 3146 installed packages. 

Any hints or directions what packages or functionalities could be tried 
out to give elogind a spin?
Best regards
Urban

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

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Irrwahn]

Irrwahn wrote on 05.01.2018 08:32:
[...]
> From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
> I gather that it is possible to configure this in sd-logind, 
> so I simply assume the same holds for elogind as well. 
> 
> However, in message #256 in that same thread Martin Steigerwald 
> asserts that this setting breaks shutdown (in the sense of not 
> behaving exactly the way it used to with sysvinit). Will elogind 
> suffer from the same regression, or will that issue be taken 
> care of?

After reading the elogind README once again, I think the following 
quote actually answers my question:

 +
 | For shutdown, reboot, and kexec, elogind shells out to "halt",
 | "reboot",and "kexec" binaries.
 +

AIUI, elogind calls "halt", which in turn would call "shutdown", 
which executes the equivalent of "init 0". Thus, assuming PID1 is 
SysV-init, the traditional behavior would be preserved, correct?

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

Re: [DNG] request: please evaluate/provide elogind-or-other ASAP

[Irrwahn]

Andreas Messer wrote on 05.01.2018 07:55:
> Hi Adam,
> 
> On Thu, Jan 04, 2018 at 11:44:25PM +0100, Adam Borowski wrote:
>> [...]
>> Thus: could you guys please prioritize work on elogind or some alternative?
> 
> Just started yesterday: https://git.devuan.org/amesser/elogind. There was
> already some work by shwsh but that seem to be stalled. (All the devuan
> packet stuff is missing there as well.)[...]

DISCLAIMER: My knowledge in this area is rather limited, so 
please bear with me!

Having that out of the way: First off, I appreciate any effort 
made in that direction! However, I have one question I deem 
important, namely: Will elogind display the same behavior as 
systemd-logind regarding killing long running processes upon 
user logout? IMNSHO it should not, i.e. it should follow the 
principle of least surprise by not killing background user 
processes on logout. 

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394
I gather that it is possible to configure this in sd-logind, 
so I simply assume the same holds for elogind as well. 

However, in message #256 in that same thread Martin Steigerwald 
asserts that this setting breaks shutdown (in the sense of not 
behaving exactly the way it used to with sysvinit). Will elogind 
suffer from the same regression, or will that issue be taken 
care of?

In case this were trivial questions with obvious answers: 
Sorry for wasting your time!

Best regards
Urban

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

Re: [DNG] Sakura: was ROXterm flickers in ascii

[Irrwahn]

Steve Litt wrote on 03.01.2018 16:21:
> On Tue, 2 Jan 2018 17:13:50 +0100
> Irrwahn <irrw...@freenet.de> wrote:
> 
>> In case you become interested in a replacement with a similar 
>> feature set, yet still small-ish footprint and reasonable list 
>> of dependencies: I can recommend sakura! I've been using it for 
>> years now 
> 
> Irrwahn, thanks for turning me on to Sakura. I'll be using it a lot in
> the future.

You're welcome. ;o)

> Sakura is a great terminal emulator with abyssmal documentation. None
> of its features or operations are discoverable until you learn that its
> configuration is contained in ~/.config/sakura/sakura.conf, and even
> then you must figure out by trial and error, by reading the source, or
> by verbal history passed from father to son, that every hotkey mentioned
> must be used in conjunction with the Shift+Ctrl combination.
> 
> Next step is to look inside sakura.c, at the #define statements,
> particularly the ones that /DEFAULT_.*_ACCELERATOR/. Compare those
> defaults the accelerator declarations in sakura.conf as it ships from
> the factory, and you find that the accelerators are the
[...]

Well, a good portion of the info you provide (in the part I snipped)
is contained, or at least pointed to, in the sakura man-page. Though 
I have to admit its author could have been a bit more verbose about
some aspects. Otherwise I have to agree with your sentiment: Since 
I've been using it, I never felt the need to look for alternatives.

Best regards
Urban

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

Re: [DNG] ROXterm flickers in ascii

[Irrwahn]

Adam Borowski wrote on 03.01.2018 00:31:
> On Tue, Jan 02, 2018 at 06:03:21PM +0100, Irrwahn wrote:
>> According to:
>> https://packages.debian.org/search?keywords=roxterm=names=all=all
>> there are roxterm packages in Debian Jessie and Sid, but I have no 
>> clue why it was dropped from Stretch. Situations like this to me 
>> smell like negligent package maintenance
> 
> Yes, it is negligent package maintenance -- both upstream and in-Debian
> maintenance.  To get roxterm back, you'd need to step up for both positions.

Ah, just as I thought!

> Stuff won't fix itself...
> 
> In the meantime, you can use one of remaining terminals.  I see 31 that
> declare Provides:x-terminal-emulator, and a wild guess is that only around
> half of available terminals declare this tag.

Luckily I'm not the one who asked for it; I seem to remember 
to have tried it once quite some time ago, and wasn't any more 
impressed by it than by any other old terminal emulator.

Thanks for the info anyway.

Best regards

Urban

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

Re: [DNG] ROXterm flickers in ascii

[Irrwahn]

Didier Kryn wrote on 02.01.2018 17:37:
> Le 02/01/2018 à 17:13, Irrwahn a écrit :
[...]
>> In case you become interested in a replacement with a similar
>> feature set, yet still small-ish footprint and reasonable list
>> of dependencies: I can recommend sakura! I've been using it for
>> years now (after gnome-terminal and its clones went belly-up
>> along with the rest of the train wreck that once was a workable
>> desktop environment) and never had reason to look back or complain.
>>
>> Terminator would be another alternative. However, to me it feels
>> a bit sluggish — might have to do with it being seemingly written
>> entirely(?) in python.

>      I was a long time user of gnome-terminal. I found recently that 
> xfce4-terminal is very close. xfce4-terminal has the same dependency as 
> roxterm on libvte and libcairo. sakura seems has a very similar 
> dependency list. Both sakura and xfce4-terminal depend on the newer 
> version of libvte (2.91). Seems roxterm is delayed or has been dropped.

Yes, xfce4-terminal is quite usable, too, and I just found out I 
still have it installed. ATM I cannot recall why I stopped using it.
Might have tripped over a borked version at some point in the past?

According to:
https://packages.debian.org/search?keywords=roxterm=names=all=all
there are roxterm packages in Debian Jessie and Sid, but I have no 
clue why it was dropped from Stretch. Situations like this to me 
smell like negligent package maintenance, so I tend to stay away 
from those, unless it is absolutely essential to me. (In which case 
I'd try to coerce the unstable version into whatever suite I'm 
actually using. The standard disclaimer about "Franken-De(bi|vu)an" 
systems applies, of course.)
 
Urban

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

Re: [DNG] ROXterm flickers in ascii

[Irrwahn]

Hendrik Boom wrote on 02.01.2018 16:46:
> On Tue, Jan 02, 2018 at 11:04:32AM +0100, Didier Kryn wrote:
>> Le 02/01/2018 à 03:40, Hendrik Boom a écrit :
>>> I've been using ROXterm in Devuan ascii.
[...]
>>     In which repository did you find roxterm? I can find rox-filer (which
>> needs some hand-made configuration) in ASCII, but not roxterm.
> 
> I'm not sure.  Possibly somewhere Steve Litt recommended, but I no longer 
> know.  I'll investigate on the off chance I'll find out.
> 
> If it's not in Devuan, obviously it's not a Devuan problem.

In case you become interested in a replacement with a similar 
feature set, yet still small-ish footprint and reasonable list 
of dependencies: I can recommend sakura! I've been using it for 
years now (after gnome-terminal and its clones went belly-up 
along with the rest of the train wreck that once was a workable 
desktop environment) and never had reason to look back or complain. 

Terminator would be another alternative. However, to me it feels 
a bit sluggish — might have to do with it being seemingly written
entirely(?) in python.

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

Re: [DNG] lprng in ascii

[Irrwahn]

Hendrik Boom wrote on 02.01.2018 15:38:
> On Tue, Jan 02, 2018 at 08:02:37AM +0100, Irrwahn wrote:
>> Hendrik Boom wrote on 02.01.2018 03:49:
>>> lprng is only partially installed after upgrade.  Aptitude and apt keep 
>>> telling me this.  However, it seems to work fine, and I have no problems 
>>> talking to my postscript laser printer. 
>>>
>>> lprng's line in interactive aptitude is:
>>>
>>> Chlprng  3.8.B-2.13.8.B-2.1
[...]
>>> Setting up lprng (3.8.B-2.1) ...
>>> invoke-rc.d: initscript lprng, action "start" failed.
>>> dpkg: error processing package lprng (--configure):
>>>  subprocess installed post-installation script returned error exit status 
>>> 1
>>> Errors were encountered while processing:
>>>  lprng
>>>  
>>> root@notlookedfor:/home/hendrik/printme# 
>>>
>>>
>>> Any ideas?
>>
>> Lprng installs and configures fine on my ascii VM (after removing
>> cups-bsd and cups-client, BTW.)
> 
> Mine was upgraded from jessie a few days ago.
> 
>>
>> * Did any relevant messages end up in the system log?
> 
> I'll look in the upgrade log.

If there really should be anything wrong with the init script, 
some message should be logged during system startup, too!

>> * Did you try to completely purge and then reinstall the package?
> 
> Not yet.

That's the very first thing I try on the occasional fsckup during 
package installation. Sometimes old configuration files can lead 
to hiccups, especially when skipping multiple intermediate versions 
during a (dist-)upgrade.

>> * There's only a few places where the /etc/init.d/lprng script can 
>>   exit with a code different from 0 upon start.
>>   Maybe you could try manually executing those parts of the script
>>   to check which one actually fails? E.g.:
>>   #test -f /usr/sbin/lpd || test -d /usr/lib/x86_64-linux-gnu/lprng || exit 5

I should've added, in above example, better replace "exit 5" with
something like "echo 'Ouch!'", or else the error indication will 
be you being logged out from the console. ;o)

>> Going by your recent slew of problem reports I cannot help the 
>> impression your system may be hosed in a rather peculiar way.
> 
> It had been hosed a year or so ago -- when aptitude had thousands of 
> broken or uninstalled and uninstallable packages .  A package repository 
> for up-to-date ocaml had been in my sources.list and it apparently had 
> packages that related neither to ocaml or Devuan jessie.  I could still 
> use aptitude from the command-line, but intereactive aptitude was 
> unusable.
 
> I had to purge aptitude entirely and reinstall it using apt to cure the 
> problem.

I had broken aptitude installations in the past, resorting to 
apt is the correct action. It's more robust and slightly more
low-level, anyway.

Urban

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

Re: [DNG] Ascii packages with dependency on libsystemd0 ?

[Irrwahn]

Mike Tubby wrote on 02.01.2018 10:11:
> All,
> 
> Over the new year holiday I decided to debootstrap ascii on to our ARM-based 
> vehicle router and have it working, which is good, however when installing 
> openssh-server I notice that it pulled in libsystemd0:
[...]
>   libkrb5support0 *libsystemd0* libx11-6 libx11-data libxau6 libxcb1 libxdmcp6
[...]

> I'm not sure whether this is expected behavior for a system without systemd 
> or not?

This is AIUI perfectly fine, as libsystemd0 is (for the 
time being) a kind of stub library that is used in cases 
where systemd is not installed. IIRC, the consensus on 
this list, after some debate, was that it does no harm 
in and of itself, and allowing it in actually takes the 
burden of the Devuan developers/maintainers to fork every 
single Debian package that has even the ever so slightest 
dependency on systemd.

Nonetheless, IMVHO, it should be closely monitored for the 
foreseeable future for any indications of non-trivial code 
sneaking in there.

TL;DR: On a full-blown Devuan desktop system you probably 
cannot easily avoid it, but its (mostly ;o) harmless.

Best regards,
Urban

-- 
Sapere aude!


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

Re: [DNG] Bad package versions in ascii

[Irrwahn]

J. Fahrner wrote on 02.01.2018 08:16:
> Hi,
> there are several packages in ascii with bad package versions. In later 
> releases versions should NEVER be lower than in former releases. Package 
> versions have to be ascending.
> 
> On my system the following packages were not upgraded because of bad 
> versions:
> 
> Package   Jessie  Ascii
> 
> desktop-base  1:1.2   1:0.99
> task-laptop   3.33+devuan1.0  3.33+devuan0.3
> tasksel   3.33+devuan1.0  3.33+devuan0.3
> tasksel-data  3.33+devuan1.0  3.33+devuan0.3
> task-laptop   3.33+devuan1.0  3.33+devuan0.3
> task-german   3.33+devuan1.0  3.33+devuan0.3

I'm not sure (and will certainly be corrected if wrong), but 
I can only assume that the Ascii versions of these packages 
are not done yet, and that the lower version numbers actually 
mean those are in fact older packages from a time quite before 
Jessie went stable. 

IOW, you'd probably actually *downgrade*, if you were to install 
the Ascii versions!!

Best regards,
Urban

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

Re: [DNG] lprng in ascii

[Irrwahn]

Hendrik Boom wrote on 02.01.2018 03:49:
> lprng is only partially installed after upgrade.  Aptitude and apt keep 
> telling me this.  However, it seems to work fine, and I have no problems 
> talking to my postscript laser printer. 
> 
> lprng's line in interactive aptitude is:
> 
> Chlprng  3.8.B-2.13.8.B-2.1
> 
> on trying to clear its status by an explicit install, it appears not to 
> be able to 'start' it: 
> 
> root@notlookedfor:/home/hendrik/printme# aptitude install lprng
> The following partially installed packages will be configured:
>   lprng 
> No packages will be installed, upgraded, or removed.
> 0 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> Need to get 0 B of archives. After unpacking 0 B will be used.
> Setting up lprng (3.8.B-2.1) ... 
> invoke-rc.d: initscript lprng, action "start" failed.
> dpkg: error processing package lprng (--configure):
>  subprocess installed post-installation script returned error exit status 
> 1
> Errors were encountered while processing:
>  lprng
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Setting up lprng (3.8.B-2.1) ...
> invoke-rc.d: initscript lprng, action "start" failed.
> dpkg: error processing package lprng (--configure):
>  subprocess installed post-installation script returned error exit status 
> 1
> Errors were encountered while processing:
>  lprng
>  
> root@notlookedfor:/home/hendrik/printme# 
> 
> 
> Any ideas?

Lprng installs and configures fine on my ascii VM (after removing
cups-bsd and cups-client, BTW.)

* Did any relevant messages end up in the system log?

* Did you try to completely purge and then reinstall the package?

* There's only a few places where the /etc/init.d/lprng script can 
  exit with a code different from 0 upon start.
  Maybe you could try manually executing those parts of the script
  to check which one actually fails? E.g.:
  #test -f /usr/sbin/lpd || test -d /usr/lib/x86_64-linux-gnu/lprng || exit 5

Going by your recent slew of problem reports I cannot help the 
impression your system may be hosed in a rather peculiar way.

Best regards
Urban

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

Re: [DNG] Happy New Year!

[Irrwahn]

A happy and successful year 12018 (sic!) to all 

Devuanitas, Devuanitos, Devuanistas, Devuaneros, Devuanii, 
DevuanerInnen, Devuan-chans, Devuan-kuns, Devuanerds, 
Devuanions, Devuanijsjes, Devuanskis, Devuanskovs, 

wherever and whatever you are!

Keep rocking the fork! ;o)


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

Re: [DNG] eudev in experimental for ascii

[Irrwahn]

KatolaZ wrote on 27.11.2017 12:11:
> On Mon, Nov 27, 2017 at 11:42:04AM +0100, Jaromil wrote:
[SNIP]
>>
>>   apt-get -t experimental install eudev
>>
>> currently, the full version of the package is 3.2.2-devuan2.7
[SNIP]
> 
> A more extensive testing of istallation in different multiarch
> environments would be welcome.

But with pleasure. :-)

Flawless installation via aptitude in interactive mode on my 
amd64 (+foreign-arch i386) kitchen-sink desktop machine 
running up-to-date ASCII, 
 replacing: udev 232-25+deb9u1
 with:  eudev 3.2.2-devuan2.7

Aptitude's second suggestion was the correct resolution for 
replacing the foreign architecture library libudev1:i386 
with its libeudev1:i386 counterpart. (To be fair, given the 
way the priorities are set, aptitude couldn't have possibly 
decided that on its own, as long as eudev resides only in 
experimental.)

No irregularities or apparent regressions after rebooting the 
machine. 

Thanks guys, and congratulations, that looks just fine!

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

Re: [DNG] new dbus packages for ASCII in experimental -- PLEASE HELP TESTING

[Irrwahn]

On Tue, 13 Jun 2017 11:16:41 +0100, Katolaz wrote:
> Hi All,
> 
> we have just built updated dbus packages for ascii. They are still in
> experimental:
> 
>   deb http://packages.devuan.org/devuan/ experimental main
> 
> and the current version number is 1.10.18-1+devuan2.2. This build
> should fix the following bugs:
> 
>   http://bugs.devuan.org/95
>   http://bugs.devuan.org/102
> 
> and also:
> 
>   https://git.devuan.org/devuan-packages/dbus/issues/31
> 
> and should allow an alternative dependency path (through dbus-x11) for
> many applications which otherwise will depend on systemd. But I am the
> least adequate person to test dbus, since I am not using any of the
> goodies which depend on it. So please, if you are using ascii with any
> Desktop Environment, could you please hel testing those packages and
> report any problem, so that we can move them to the main ascii repo
> asap?
> 
> Thanks
> 
> KatolaZ


Hi KatolaZ,

I gave it a quick spin on my Ascii "kitchen-sinK" machine, by replacing the 
1.10.18-1.0nosystemd1 version I had previously pulled from the angband 
repository with your new 1.10.18-1+devuan2.2 packages. That included dbus-x11 
as well, as it was already installed on the system. 

I can tell no difference in any behavior, all dbus related functionality 
appears to work perfectly fine, no dependencies were broken during the change. 

Oh, and gconf2 (which was also already installed, version 3.2.6-4+b1) seems 
to be quite happy with it.

HTH
Regards
Urban


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