Page 4 of 9

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-11 11:48
by edbarx
Searched for CLI program calls within gparted's source code. Here is what I was looking for: :)

Code: Select all

bool ext2::move( const Partition & partition_new,
                 const Partition & partition_old,
                 OperationDetail & operationdetail )
{
	Sector distance;
	Glib::ustring offset;
	distance = partition_old.sector_start - partition_new.sector_start;
	offset = Utils::num_to_str( llabs(distance) * partition_new.sector_size );
	if ( distance < 0 )
		return ! execute_command( "e2image -ra -p -o " + offset + " " + partition_new.get_path(),
		                          operationdetail, true, true );
	else
		return ! execute_command( "e2image -ra -p -O " + offset + " " + partition_new.get_path(),
		                          operationdetail, true, true );

}
That is why I love GNU/Linux, with closed source software one cannot do that. :mrgreen:

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-11 11:57
by adenukolnis
goulo wrote:Yeah, giving up iceweasel would be a heavy price to pay to get rid of dbus! I too am curious if there is a solution to that. Thamks for reporting your explorations.
You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends. As far as I can tell it is just the backend of dbus so I wouldnt think it provides any active service. The dbus and dbus-x11 packages are the frontend daemons and tools as far as I know.

Instead of the complete lxde desktop, what I would probably do is run openbox and lxpanel which will give me the same look and feel although it will not have the lxde session system running.

You might also check out the razorqt desktop for a familiar enviorment.

Of course there is always icewm for a user environment too.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-11 21:36
by timbgo
I realized I needed to update also my Gentoo local mirror, which, in air-gapped (poor user's, not professional air-gapped) is quite some work. Still doing it.

And then comes the updating the master, then cloning onto the only-internet same MBO Gentoo box, and then goes very scrutineous preparations, because I'm not an expert, that exposing of my provider's brazen censorship is something utmost that I have ever been able to do...

Scrutineous preparations for controlled (packet capture) subscribing and sending to debian-devel mail-list. There, I'm certain, are many developers who want us to fight for these options and freedom!

But I see you have more ideas. And, since the Gentoo update is now in works, I have to first let you know that I very much appreciate your advice and your efforts, adenukolnis and edbarx, but they call for more time than just a few minutes, for replying.

On a sidenote, I will also be looking into what slipped my attention somehow, and what exbarx gave:
http://www.brain-dump.org/blog/entry/40 ... _in_Debian

But, what fits into a few minutes writing is this:
I plan trying and installing, since I have openbox and X11, those packages that I have, the ./configure ; make ;make install (or whatever the README and INSTALL) in those packages (haven't untarred them yet), from source, keep exact track which file they install, if they manage to install, and see if that dependency on dbus is real or if it is impositional for no reason.

More time, as I said, I need, to look into and reply to other ideas. Which I will examine before deciding on the above (which does look the simplest to try, was a LinuxFromScrach-er myself), or some of your ideas.

And I have to go, for now.

Miroslav Rovis

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-12 18:03
by timbgo
adenukolnis wrote:
goulo wrote:Yeah, giving up iceweasel would be a heavy price to pay to get rid of dbus! I too am curious if there is a solution to that. Thamks for reporting your explorations.
You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends. As far as I can tell it is just the backend of dbus so I wouldnt think it provides any active service. The dbus and dbus-x11 packages are the frontend daemons and tools as far as I know.
But I pinned the entire dbus family whatsoever with *dbus* (asterisks on both sides).
I checked, and indeed in my crippled master Debian that I am currently experimenting with, I have no dbus family member, to call'em that, just affectionately... Yeah, ermh, very affectionately...

I don't need dbus to control my system and encryption on it:

( same topic, the post with talk of Daniel Robbins )
http://forums.debian.net/viewtopic.php? ... 45#p552566

I really have serious issues having been offered to use a GUI, which fortunately is not the case in Debian, to simply type in my passphrase when I want to encrypt or decrypt something, as I wrote about in (another of my Offtopic's posts):

gpg-agent now forced upon users of GnuPG
http://forums.debian.net/viewtopic.php?f=3&t=114427

which I made further study of in:

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-9 ... ml#7551458

Any encrypting on my computer, if it isn't by my design, by my decision, or in some other way in my complete control, in not welcome. I don't have any of such in Gentoo. I might previously have had, but for that reason, in Gentoo, I have spent already months of my dedicated studying/attempting/researching for true privacy and freedom...
Instead of the complete lxde desktop, what I would probably do is run openbox and lxpanel which will give me the same look and feel although it will not have the lxde session system running.

You might also check out the razorqt desktop for a familiar enviorment.
razorqt is probaly Qt based. I would never post what I prepared if I went to reread this:

GTK fesses up – this ain’t for you; Qt takes over the world
https://igurublog.wordpress.com/2014/01 ... the-world/

but IIRC, QT is big business. No good things for GNU any from big business, be it Google, Red Hat or any... I could weep, thinking where GNU/Linux is allowing Itself to be dragged and humiliated, and gutted out... Theory only, this. Can't study razorqt.
Of course there is always icewm for a user environment too.
So lxde-panel or icewm. But the choice is after the systemd/dbus issue and the rest that I plan (cry for help at debian-devel) is done.

Unless I break. Because this is getting hard. Privacy looks very hard to attain in Debian. Because, no!, someone else doing the encrypting on my computer is not my privacy but his.

The multiseats! The mutliseated computers for all users of GNU/Linux in the world. That is poetteringware!

Sorry for the guy, Lennart Pöttering, but he's worse than Billy the Moral Gangster Gates. The latter was at least openly greedy (what was that letter of him crying for his dear moneys when the piracy Windoze went wild?), but this one is talking from inside GNU/Linux and killing it, and dragging his hordes behind, of mosly ignorant and uninformed, but also profiteers and liers. He is worse than Billy!

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-12 18:10
by timbgo
edbarx wrote:Searched for CLI program calls within gparted's source code. Here is what I was looking for: :)

Code: Select all

bool ext2::move( const Partition & partition_new,
                 const Partition & partition_old,
                 OperationDetail & operationdetail )
{
	Sector distance;
	Glib::ustring offset;
	distance = partition_old.sector_start - partition_new.sector_start;
	offset = Utils::num_to_str( llabs(distance) * partition_new.sector_size );
	if ( distance < 0 )
		return ! execute_command( "e2image -ra -p -o " + offset + " " + partition_new.get_path(),
		                          operationdetail, true, true );
	else
		return ! execute_command( "e2image -ra -p -O " + offset + " " + partition_new.get_path(),
		                          operationdetail, true, true );

}
That is why I love GNU/Linux, with closed source software one cannot do that. :mrgreen:
Complete post above. No, I don't talk C (if that is C), and I am not as advanced as to understand how this could help us in our quest for freedom from poetteringware...
Miro

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-12 18:16
by timbgo
edbarx wrote:
timbgo wrote:Command Line Interface. But I don't get it how it applies here?
If a fraction of those functions can be delegated to CLI programs, it should be possible to use those programs as backends. This is done in many situations, where a graphical frontend like synaptic, uses CLI backends.

Added Later:
Since in C/C++ main() is a function, I am suspecting, using a CLI backend is a matter of importing that function, essentially, making the backend program behave like a library. What I know for sure is that the OS calls main() to run a program.
Unabridged post above. edbarx, I'm more of a regular user in these terms. If you manage to, but with very probable prospects, put that to use so we can liberate our boxes, great.
But I don't even see, for lack of my understanding of these codes and aspects, clearly here, and have spent too much time already. Fatigue entering.
No, I think we desperately need help from debian-devel.
I work too slowly. Why can't anyone just send that notice to those developers?
(see previous posts if someone is reading this in parachuted fashion; search for, say Wookey, and search for mirabilos)
Miro

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-12 18:21
by timbgo
While I have updated my private Gentoo mirror and my Gentoo boxes, I haven't prepared the issue for mailing to the developers yet (just pleaded if someone could help in that regard again, in the previous post), and in fact most of my work since I left here yesterday was with the issue of living systemd-free in Debian.

I decided I knew too little to be able to rid myself of the dbus dependency the way that edbarx suggested
( http://www.brain-dump.org/blog/entry/40 ... _in_Debian )

and went for the old general compilation way (configure, make, make install of the upstream sources).

I have discovered only that ffmpeg can be installed without any dbus/systemd/pulseaudio/oetteringware-generally, and that tells something doesn't it?

But tried quite a few times unsuccessfully to install mplayer.

With mplayer goes also mencoder. And I use my old command line to capture DVB from an old TV card on whichever of the Debian boxes that I install the TV-card in (physically in the PCI-slot). If I were able to get that mencoder to do the work, that would be a major breakthrough.

Yes, getting mencoder to work on my no-dbus, no-systemd, no-policykit, no-pulseaudio, no-any-poetteringware, would be a major breakthrough, because it would without much doubt prove that potteringware is really just an overhead on top of real programs, that can perfectly, although not at all easily at the current state of affairs, be done away with.

I plan to explain in detail what I've done since I left yesterday.
EDIT 2014-10-22: I remembered this promise of mine often later on, but it kept looming as too much work, and not pressing work, so I left it behind. Anyway, that was all compiling the LinuxFromScratch way, if you know LFS, or simply the configure; make; make install way which you (I'm always having newbies in mind as well, not the competent only who conversed with me here)...
And is not appropriate for methods in Debian distro...
What I did proved my point, and many others' points all over the internet: that those dependencies are unnecessarily introduced and can be done without.
I am currently exploring, will be testing it these hours:
MirDebian “WTF” Repository
http://users.unixforge.de/~tglaser/debs/debidx.htm
which is soon to be on:
https://people.debian.org/~tg/
Pls. disregard other promises possibly in further posts down from here that I have to render void with this notice. Thanks!

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-12 20:47
by timbgo
I untar'd the mplayer sources (it's upstream sources, so I don't think it mattered that I got them from m y local Gentoo mirror). and, as per the instructions in the README, I first tried:

Code: Select all

debian/daily-build.sh -b
And I got this result:

Code: Select all

root@mybox:/usr/local/src/mplayer-1.2_pre20130729# debian/daily-build.sh -b
dpkg-buildpackage: source package mplayer                        
dpkg-buildpackage: source version 2:1.0~svn
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by root <root@mybox>
dpkg-buildpackage: host architecture amd64
 dpkg-source -i -I.svn --before-build mplayer-1.2_pre20130729
dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input data in general section of control info file
dpkg-checkbuilddeps: Unmet build dependencies: ladspa-sdk libenca-dev libaa1-dev libasound2-dev libaudio-dev libcaca-dev libcdparanoia-dev | libcdparanoia0-dev libbluray-dev libdirectfb-dev libdts-dev libesd0-dev libfaad-dev libfribidi-dev libgif-dev libgtk2.0-dev libjack-dev libjpeg-dev liblircclient-dev liblivemedia-dev liblzo2-dev libmp3lame-dev libmpcdec-dev libopenal-dev libpulse-dev libschroedinger-dev libsdl1.2-dev | libsdl1.1-dev libsmbclient-dev libspeex-dev libsvga1-dev libswscale-dev libtheora-dev (>= 1.0~beta1) libvorbis-dev libvorbisidec-dev libx264-dev (>= 2:0.115~) libxinerama-dev libxv-dev libxvidcore-dev libxvmc-dev libxxf86dga-dev libvdpau-dev vstream-client-dev yasm
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
root@mybox:/usr/local/src/mplayer-1.2_pre20130729#
Ah, it's missing the dev packages. I figure that out only now, hours after the event. I said I was slow.

Can't try anything there now. I'm working on reporting my other attempts as well.

Next, I tried the following.

Code: Select all

./configure --prefix=/usr
It complained it needed yasm.

Code: Select all

apt-get install yasm
Installed.

I used redirection as below, to be able to report the state of affairs.

Code: Select all

./configure --prefix=/usr 2>&1 | tee /somewhere/mplayer_`date +%y%m%d_%H%M`_configure.txt
make 2>&1 | tee /somewhere/mplayer_`date +%y%m%d_%H%M`_make.txt
I won't be repeating those redirection to not clutter this report.

Then I ran:

Code: Select all

make
But mplayer could not compile, and the make ran very short.

Code: Select all

help/help_create.sh help/help_mp-en.h UTF-8
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o command.o command.c
In file included from libmpdemux/stheader.h:23:0,
                 from command.c:32:
libmpdemux/aviheader.h:25:30: fatal error: libavutil/common.h: No such file or directory
 #include "libavutil/common.h"
                              ^
compilation terminated.
Makefile:758: recipe for target 'command.o' failed
make: *** [command.o] Error 1
Another attmpet at mplayer. And my attempts here go from the start. Removing the antire untarred directory and going all over.

So this is the output of
configure --prefix=/usr:

Code: Select all

Checking for cc version ... 4.8 
Checking for working compiler ... yes
Detected operating system: Linux
Detected host architecture: x86_64
Checking for cross compilation ... no 
Checking for host cc ... cc 
Checking for CPU vendor ... AuthenticAMD (15:43:1) 
Checking for CPU type ...  AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 
Checking for kernel support of mmx ... yes 
Checking for kernel support of mmxext ... yes 
Checking for kernel support of 3dnow ... yes 
Checking for kernel support of 3dnowext ... yes 
Checking for kernel support of sse ... yes 
Checking for kernel support of sse2 ... yes 
Checking for kernel support of sse3 ... yes 
Checking for kernel support of cmov ... yes 
Checking for mtrr support ... yes 
Checking for GCC & CPU optimization abilities ... native 
Checking for byte order ... little-endian 
Checking for extern symbol prefix ...  
Checking for assembler support of -pipe option ... yes 
Checking for relocatable binary ... yes (fast PIC)
Checking for PIC ... yes 
Checking for .align is a power of two ... no 
Checking for ebx availability ... yes 
Checking for yasm ... yasm 
Checking for bswap ... yes 
Checking for xmm clobbers ... yes 
Checking for langinfo ... yes 
Checking for language ... messages: en - man pages: en - documentation: en 
Checking for enable sighandler ... yes 
Checking for runtime cpudetection ... no 
Checking for restrict keyword ... restrict 
Checking for __builtin_expect ... yes 
Checking for kstat ... no 
Checking for atanf ... yes 
Checking for cbrt ... yes 
Checking for cbrtf ... yes 
Checking for cosf ... yes 
Checking for expf ... yes 
Checking for exp2 ... yes 
Checking for exp2f ... yes 
Checking for isnan ... yes 
Checking for isinf ... yes 
Checking for llrint ... yes 
Checking for llrintf ... yes 
Checking for log2 ... yes 
Checking for log2f ... yes 
Checking for log10f ... yes 
Checking for lrint ... yes 
Checking for lrintf ... yes 
Checking for rint ... yes 
Checking for round ... yes 
Checking for roundf ... yes 
Checking for sinf ... yes 
Checking for trunc ... yes 
Checking for truncf ... yes 
Checking for atan2f ... yes 
Checking for ldexpf ... yes 
Checking for powf ... yes 
Checking for mkstemp ... yes 
Checking for nanosleep ... yes 
Checking for socklib ... yes 
Checking for netdb.h, struct addrinfo ... yes 
Checking for netdb.h, getaddrinfo() ... yes 
Checking for sockaddr_storage ... yes 
Checking for struct ipv6_mreq ... yes 
Checking for struct sockaddr_in6 ... yes 
Checking for struct sockaddr sa_len ... no 
Checking for arpa/inet.h ... yes 
Checking for inet_pton() ... yes 
Checking for inet_aton() ... no 
Checking for socklen_t ... yes 
Checking for closesocket() ... no 
Checking for networking ... yes 
Checking for inet6 ... yes 
Checking for gethostbyname2 ... yes 
Checking for SCTP ... no 
Checking for sys/poll.h ... yes 
Checking for inttypes.h (required) ... yes 
Checking for int_fastXY_t in inttypes.h ... yes 
Checking for malloc.h ... yes 
Checking for aligned malloc ... no 
Checking for memalign() ... yes 
Checking for posix_memalign() ... yes 
Checking for alloca.h ... yes 
Checking for fastmemcpy ... yes 
Checking for hard-coded tables ... no 
Checking for mman.h ... yes 
Checking for mprotect ... yes 
Checking for dynamic loader ... yes 
Checking for dynamic a/v plugins support ... no 
Checking for pthread ... yes (using -lpthread)
Checking for direct.h ... no 
Checking for windows.h ... no 
Checking for io.h ... no 
Checking for rpath ... no 
Checking for iconv ... yes 
Checking for soundcard.h ... yes (sys/soundcard.h)
Checking for termcap ... yes (using -lncurses)
Checking for termios ... yes (using termios.h)
Checking for shm ... yes 
Checking for strsep() ... yes 
Checking for vsscanf() ... yes 
Checking for POSIX select() ... yes 
Checking for audio select() ... yes 
Checking for gettimeofday() ... yes 
Checking for glob() ... yes 
Checking for setenv() ... yes 
Checking for setmode() ... no 
Checking for sys/sysinfo.h ... yes 
Checking for Apple IR ... yes 
Checking for pkg-config ... yes 
Checking for Samba support (libsmbclient) ... no 
Checking for /dev/mga_vid ... no 
Checking for tdfxfb ... no 
Checking for s3fb ... no 
Checking for wii ... no 
Checking for tdfxvid ... no 
Checking for xvr100 ... no 
Checking for tga ... yes 
Checking for md5sum support ... yes 
Checking for yuv4mpeg support ... yes 
Checking for bl ... no 
Checking for DirectFB ... no 
Checking for X11 headers presence ... yes 
Checking for X11 ... yes 
Checking for Xss screensaver extensions ... no 
Checking for DPMS ... yes (using Xdpms 4)
Checking for Xv ... no 
Checking for XvMC ... no 
Checking for Video Decode Acceleration (VDA) ... no 
Checking for VDPAU ... no 
Checking for Xinerama ... no 
Checking for Xxf86vm ... yes 
Checking for XF86keysym ... yes 
Checking for DGA ... no 
Checking for xmga ... no 
Checking for 3dfx ... no 
Checking for VIDIX ... yes 
Checking for VIDIX PCI device name database ... yes 
Checking for VIDIX dhahelper support ... no 
Checking for VIDIX svgalib_helper support ... no 
Checking for GGI ... no 
Checking for GGI extension: libggiwmh ... no 
Checking for AA ... no 
Checking for CACA ... no 
Checking for SVGAlib ... no 
Checking for FBDev ... yes 
Checking for DVB ... yes 
Checking for PNG support ... yes 
Checking for MNG support ... no 
Checking for JPEG support ... no 
Checking for OpenJPEG (JPEG 2000) support ... no 
Checking for PNM support ... yes 
Checking for GIF support ... no 
Checking for VESA support ... no 
Checking for SDL ... no 
Checking for SDL image ... no 
Checking for OpenGL ... yes (backends: x11 egl_x11)
Checking for MatrixView ... yes 
Checking for DXR2 ... no 
Checking for DXR3/H+ ... no 
Checking for IVTV TV-Out (pre linux-2.6.24) ... no 
Checking for V4L2 MPEG Decoder ... yes 
Checking for OSS Audio ... yes 
Checking for aRts ... no 
Checking for EsounD ... no 
Checking for NAS ... no 
Checking for pulse ... no 
Checking for JACK ... no 
Checking for OpenAL ... no 
Checking for ALSA audio ... no 
Checking for Sun audio ... no 
Checking for VCD support ... yes 
Checking for Blu-ray support ... no 
Checking for dvdread ... yes (internal)
Checking for internal libdvdcss ... yes 
Checking for libcdio ... no 
Checking for cdparanoia ... no 
Checking for bitmap font support ... yes 
Checking for freetype >= 2.0.9 ... yes 
Checking for fontconfig ... yes 
Checking for fribidi with charsets ... no 
Checking for SSA/ASS support ... yes 
Checking for ENCA ... no 
Checking for zlib ... yes 
Checking for bzlib ... no 
Checking for RTC ... yes 
Checking for liblzo2 support ... no 
Checking for mad support ... no 
Checking for Twolame ... no 
Checking for Toolame ... no 
Checking for OggVorbis support ... no 
Checking for libspeex (version >= 1.1 required) ... no 
Checking for libgsm ... no 
Checking for OggTheora support ... no 
Checking for mpg123 support ... no 
Checking for liba52 support ... no 
Checking for libmpeg2 support ... yes (internal)
Checking for libdca support ... no 
Checking for libmpcdec (musepack, version >= 1.2.1 required) ... no 
Checking for FAAC support ... no (in FFmpeg: no)
Checking for FAAD2 support ... no 
Checking for libilbc support ... no 
Checking for libopus decoding support ... no 
Checking for LADSPA plugin support ... no 
Checking for libbs2b audio filter support ... no 
Checking for Win32 codecs ... no 
Checking for XAnim codecs ... yes (dynamic loader support needed)
Checking for RealPlayer codecs ... yes (dynamic loader support needed)
Checking for QuickTime codecs ... auto 
Checking for Nemesi Streaming Media libraries ... no 
Checking for LIVE555 Streaming Media libraries ... no 
Checking for RTMPDump Streaming Media library ... no 
Checking for FFmpeg ... yes 
Checking for libpostproc ... yes 
Checking for libopencore_amr narrowband ... no 
Checking for libopencore_amr wideband ... no 
Checking for libdv-0.9.5+ ... no 
Checking for CrystalHD ... no 
Checking for Xvid ... no 
Checking for Xvid two pass plugin ... no 
Checking for x264 ... no (in FFmpeg: no)
Checking for libdirac ... no 
Checking for libschroedinger ... no 
Checking for libvpx ... no 
Checking for libnut ... no 
Checking for zr ... no 
Checking for libmp3lame ... no (in FFmpeg: no)
Checking for mencoder ... yes 
Checking for UnRAR executable ... yes 
Checking for TV interface ... yes 
Checking for DirectShow TV interface ... auto 
Checking for Video 4 Linux TV interface ... no 
Checking for Video 4 Linux 2 TV interface ... yes 
Checking for Radio interface ... no 
Checking for Capture for Radio interface ... no 
Checking for Video 4 Linux 2 Radio interface ... auto 
Checking for Video 4 Linux Radio interface ... auto 
Checking for Video 4 Linux 2 MPEG PVR interface ... yes 
Checking for ftp ... yes 
Checking for vstream client ... no 
Checking for OSD menu ... no 
Checking for Subtitles sorting ... yes 
Checking for XMMS inputplugin support ... no 
Checking for GUI ... no
Checking for automatic gdb attach ... no 
Checking for compiler support for noexecstack ... yes 
Checking for linker support for --nxcompat --no-seh --dynamicbase ... no 
Checking for linker support for --large-address-aware ... no 
Checking for linker support for --version-script ... yes 
Checking for joystick ... no 
Checking for lirc ... no 
Checking for lircc ... no 
Checking for DVD support (libdvdnav) ... yes (internal)
Checking for XML catalogs ... SGML catalog 
Checking for XML chunked stylesheet ... chunk.xsl 
Checking for XML monolithic stylesheet ... docbook.xsl 
Checking for XML DTD ... docbookx.dtd 
Checking for valid XSLT processor ... xsltproc 
Creating config.mak
Creating config.h

Config files successfully generated by ./configure --prefix=/usr !

  Install prefix: /usr
  Data directory: /usr/share/mplayer
  Config direct.: /usr/etc/mplayer

  Byte order: little-endian
  Optimizing for: native

  Languages:
    Messages/GUI: en
    Manual pages: en
    Documentation: en

  Enabled optional drivers:
    Input: dvdnav(internal) ftp pvr tv-v4l2 tv libdvdcss(internal) dvdread(internal) vcd dvb networking 
    Codecs: ffmpeg(internal) real xanim libmpeg2(internal) 
    Audio output: oss v4l2 mpegpes(dvb) 
    Video output: v4l2 matrixview opengl pnm mpegpes(dvb) fbdev xvidix cvidix x11 xover yuv4mpeg md5sum tga 

  Disabled optional drivers:
    Input: vstream radio tv-v4l1 tv-dshow librtmp live555 nemesi cddb cdda bluray smb 
    Codecs: libvpx libschroedinger libdirac x264 xvid crystalhd libdv libopencore_amrwb libopencore_amrnb qtx win32 libopus ilbc faad2 faac musepack libdca liba52 mpg123 libtheora libgsm speex libvorbis toolame twolame libmad liblzo gif OpenJPEG 
    Audio output: sun alsa openal jack pulse nas esd arts ivtv dxr2 sdl 
    Video output: zr zr2 ivtv dxr3 dxr2 sdl vesa gif89a jpeg mng svga caca aa ggi winvidix 3dfx xmga dga vdpau xvmc xv directfb dfbmga bl xvr100 tdfx_vid wii s3fb tdfxfb mga 

'config.h' and 'config.mak' contain your configuration options.
Note: If you alter theses files (for instance CFLAGS) MPlayer may no longer
      compile *** DO NOT REPORT BUGS if you tweak these files ***

'make' will now compile MPlayer and 'make install' will install it.
Note: On non-Linux systems you might need to use 'gmake' instead of 'make'.

Please check MTRR settings at /proc/mtrr (see DOCS/HTML/en/video.html#mtrr)

NOTE: Win32 codec DLLs are not supported on your CPU (x86_64) or your
operating system (Linux). You may encounter a few files that cannot
be played due to missing open source video/audio codec support.

Check config.log if you wonder why an autodetection failed (make sure
development headers/packages are installed).

NOTE: The --enable-* parameters unconditionally force options on, completely
skipping autodetection. This behavior is unlike what you may be used to from
autoconf-based configure scripts that can decide to override you. This greater
level of control comes at a price. You may have to provide the correct compiler
and linker flags yourself.
If you used one of these options (except --enable-menu and similar ones that
turn on internal features) and experience a compilation or linking failure,
make sure you have passed the necessary compiler/linker flags to configure.

If you suspect a bug, please read DOCS/HTML/en/bugreports.html.
The lines that strike me:

Code: Select all

Checking for ALSA audio ... no 
but later:

Code: Select all

    Audio output: sun alsa openal jack pulse nas esd arts ivtv dxr2 sdl 
I don't understand that.

And here's why, if anyone could explain to us. I'm still vague on it.

Code: Select all

From [b]config.log[/b] of the mplayer compilation in question:
##########################################

============ Checking for ALSA audio ============

#include <alsa/asoundlib.h>
int main(void) { return 0; }

cc -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize /tmp/mplayer-configure--6770/tmp.c  -fpie -DPIC -D_REENTRANT    -ffast-math -fpie -pie   -lncurses -lpng -lz   -lXext -lX11 -lpthread -lXxf86vm -lGL -ldl -lEGL -ldl  -o /tmp/mplayer-configure--6770/tmp -lasound -ldl -lpthread -lm
/tmp/mplayer-configure--6770/tmp.c:1:28: fatal error: alsa/asoundlib.h: No such file or directory
 #include <alsa/asoundlib.h>
                            ^
compilation terminated.


Result is: no 
##########################################
[1]

The fact is: truly no such file: asoundlib.h in directory alsa or any other on my crippled, experimented-with Debian air-gapped box (just rechecked).

Just checked in my Gentoo box, /usr/include/alsa/asoundlib.h is there. But this online Debian box doesn't have it:

Code: Select all

# find /usr/ -name 'asoundlib.h'
#
returns empty.

Even without figuring this our, I thought it must be mplayer will install if I manage to install ffmpeg.

I just check ffmpeg which I managed to install. I has too few formats supported, such as not x264 and not libvorbis (it reported it would install it but I couldn't encode into it), but I managed to convert audio from an elsewhere captured TV/DVB snippet from mp2 into a wav format, so probably can be gotten to work fine.

Why is it, that dbus has to be a requirement for ffmpeg? How immoral from whoever makes that a requirement for FFmpeg on Debian.

So, ffmpeg installed.

BTW, this is the ffmpeg configure line:

Code: Select all

./configure --prefix=/usr --enable-gpl --enable-x11grab
--enable-gpl is a requirement for --enable-x11grab, which I need for my screencasting:

Code: Select all

ffmpeg -f x11grab -s xga -r 25 -i :0.0 Screen_`date +%y%m%d_%H%M`_`hostname`.mkv
That line worked on my no-poetteringware experimental Debian.

Now mplayer will, as I will demonstrate, stop short again, but not so quickly at all!

In the meantime, lest I forget to say, I also upgraded that experimental box with this week's Jigdo Testing Branch. DVD's served from my local mirror.

Just one tip for people who might be reading this and anyhow thinking of compiling upstream packages (any packages) the the old configure/make/make install way:

If you do so, you have to keep track of the files that the package you are compiling installs on your system. Else, troubles looming over you box! If you some time in the future decide you want to remove it, how will you do i? And also, if you don't remove them, how do you know if a particular file does not belong to one of those that you compiled and install the old way?

I keep track of them this way:

Code: Select all

find /<my-system-partitions> -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt
<my-system-partitions> can be one sole, or can be all that is mounted on root if I unmount foreing filesystems, say from my SOHO.
And that line finds all the files that are at a particular time in my system partitions.

Run this separately from a command line to see what it does:

Code: Select all

date +%y%m%d_%H%M
It just puts into the name of that FIND_xxxxxxx_yourhostname.txt file the date and time when you take down the list of ALL files in your system partition(s).

The easiest way to know what a particular compiled program will install is to run that command after a successful:

Code: Select all

make
and then run:

Code: Select all

make install
and now run that find line from the command prompt again.
If you do the diff on those two before and after make install, and do some sed'ing on it, you can easily get the exact list of files that a program has just installed.

If you don't know how to use sed, you can edit the diff in some editor.

Anyway, this is the list of my ffmpeg install:

Code: Select all

/usr/share/ffmpeg
/usr/share/ffmpeg/examples
/usr/share/ffmpeg/examples/demuxing_decoding.c
/usr/share/ffmpeg/examples/Makefile
/usr/share/ffmpeg/examples/filtering_video.c
/usr/share/ffmpeg/examples/transcoding.c
/usr/share/ffmpeg/examples/metadata.c
/usr/share/ffmpeg/examples/transcode_aac.c
/usr/share/ffmpeg/examples/scaling_video.c
/usr/share/ffmpeg/examples/decoding_encoding.c
/usr/share/ffmpeg/examples/resampling_audio.c
/usr/share/ffmpeg/examples/README
/usr/share/ffmpeg/examples/filter_audio.c
/usr/share/ffmpeg/examples/filtering_audio.c
/usr/share/ffmpeg/examples/muxing.c
/usr/share/ffmpeg/examples/avio_reading.c
/usr/share/ffmpeg/examples/remuxing.c
/usr/share/ffmpeg/libvpx-1080p.ffpreset
/usr/share/ffmpeg/libvpx-720p50_60.ffpreset
/usr/share/ffmpeg/libvpx-1080p50_60.ffpreset
/usr/share/ffmpeg/ffprobe.xsd
/usr/share/ffmpeg/libvpx-720p.ffpreset
/usr/share/ffmpeg/libvpx-360p.ffpreset
/usr/share/man/man3/libavfilter.3
/usr/share/man/man3/libavutil.3
/usr/share/man/man3/libavformat.3
/usr/share/man/man3/libswscale.3
/usr/share/man/man3/libavdevice.3
/usr/share/man/man3/libavcodec.3
/usr/share/man/man3/libswresample.3
/usr/share/man/man1/ffprobe-all.1
/usr/share/man/man1/ffmpeg-codecs.1
/usr/share/man/man1/ffmpeg-formats.1
/usr/share/man/man1/ffmpeg-devices.1
/usr/share/man/man1/ffserver.1
/usr/share/man/man1/ffprobe.1
/usr/share/man/man1/ffmpeg-all.1
/usr/share/man/man1/ffmpeg.1
/usr/share/man/man1/ffmpeg-scaler.1
/usr/share/man/man1/ffmpeg-bitstream-filters.1
/usr/share/man/man1/ffmpeg-utils.1
/usr/share/man/man1/ffmpeg-protocols.1
/usr/share/man/man1/ffmpeg-filters.1
/usr/share/man/man1/ffserver-all.1
/usr/share/man/man1/ffmpeg-resampler.1
/usr/bin/ffserver
/usr/bin/ffmpeg
/usr/bin/ffprobe
/usr/lib/libswresample.a
/usr/lib/libpostproc.a
/usr/lib/libavcodec.a
/usr/lib/libswscale.a
/usr/lib/pkgconfig/libavfilter.pc
/usr/lib/pkgconfig/libavutil.pc
/usr/lib/pkgconfig/libswresample.pc
/usr/lib/pkgconfig/libavcodec.pc
/usr/lib/pkgconfig/libavdevice.pc
/usr/lib/pkgconfig/libavformat.pc
/usr/lib/pkgconfig/libswscale.pc
/usr/lib/pkgconfig/libpostproc.pc
/usr/lib/libavutil.a
/usr/lib/libavformat.a
/usr/lib/libavfilter.a
/usr/lib/libavdevice.a
/usr/include/libavutil
/usr/include/libavutil/frame.h
/usr/include/libavutil/threadmessage.h
/usr/include/libavutil/xtea.h
/usr/include/libavutil/adler32.h
/usr/include/libavutil/mem.h
/usr/include/libavutil/channel_layout.h
/usr/include/libavutil/dict.h
/usr/include/libavutil/opt.h
/usr/include/libavutil/random_seed.h
/usr/include/libavutil/ffversion.h
/usr/include/libavutil/time.h
/usr/include/libavutil/file.h
/usr/include/libavutil/timecode.h
/usr/include/libavutil/murmur3.h
/usr/include/libavutil/common.h
/usr/include/libavutil/log.h
/usr/include/libavutil/base64.h
/usr/include/libavutil/eval.h
/usr/include/libavutil/replaygain.h
/usr/include/libavutil/error.h
/usr/include/libavutil/bprint.h
/usr/include/libavutil/intreadwrite.h
/usr/include/libavutil/cpu.h
/usr/include/libavutil/blowfish.h
/usr/include/libavutil/display.h
/usr/include/libavutil/intfloat_readwrite.h
/usr/include/libavutil/avassert.h
/usr/include/libavutil/audio_fifo.h
/usr/include/libavutil/audioconvert.h
/usr/include/libavutil/version.h
/usr/include/libavutil/parseutils.h
/usr/include/libavutil/buffer.h
/usr/include/libavutil/lzo.h
/usr/include/libavutil/bswap.h
/usr/include/libavutil/hash.h
/usr/include/libavutil/pixfmt.h
/usr/include/libavutil/avstring.h
/usr/include/libavutil/avconfig.h
/usr/include/libavutil/avutil.h
/usr/include/libavutil/md5.h
/usr/include/libavutil/imgutils.h
/usr/include/libavutil/fifo.h
/usr/include/libavutil/ripemd.h
/usr/include/libavutil/attributes.h
/usr/include/libavutil/crc.h
/usr/include/libavutil/samplefmt.h
/usr/include/libavutil/intfloat.h
/usr/include/libavutil/aes.h
/usr/include/libavutil/downmix_info.h
/usr/include/libavutil/mathematics.h
/usr/include/libavutil/macros.h
/usr/include/libavutil/rational.h
/usr/include/libavutil/lfg.h
/usr/include/libavutil/sha.h
/usr/include/libavutil/sha512.h
/usr/include/libavutil/old_pix_fmts.h
/usr/include/libavutil/stereo3d.h
/usr/include/libavutil/hmac.h
/usr/include/libavutil/timestamp.h
/usr/include/libavutil/pixdesc.h
/usr/include/libavcodec
/usr/include/libavcodec/avfft.h
/usr/include/libavcodec/vda.h
/usr/include/libavcodec/vdpau.h
/usr/include/libavcodec/avcodec.h
/usr/include/libavcodec/dv_profile.h
/usr/include/libavcodec/old_codec_ids.h
/usr/include/libavcodec/version.h
/usr/include/libavcodec/dxva2.h
/usr/include/libavcodec/xvmc.h
/usr/include/libavcodec/vaapi.h
/usr/include/libswresample
/usr/include/libswresample/version.h
/usr/include/libswresample/swresample.h
/usr/include/libpostproc
/usr/include/libpostproc/postprocess.h
/usr/include/libpostproc/version.h
/usr/include/libswscale
/usr/include/libswscale/swscale.h
/usr/include/libswscale/version.h
/usr/include/libavformat
/usr/include/libavformat/avformat.h
/usr/include/libavformat/version.h
/usr/include/libavformat/avio.h
/usr/include/libavfilter
/usr/include/libavfilter/buffersink.h
/usr/include/libavfilter/buffersrc.h
/usr/include/libavfilter/avcodec.h
/usr/include/libavfilter/version.h
/usr/include/libavfilter/avfilter.h
/usr/include/libavfilter/asrc_abuffer.h
/usr/include/libavfilter/avfiltergraph.h
/usr/include/libavdevice
/usr/include/libavdevice/version.h
/usr/include/libavdevice/avdevice.h
which I got in the above described fashion.

These are the two full codecs-an-all-support outputs for the OLD (the dbus and systemd still on), and the experimental, the NEW (no-systemd-dbus-etAlia) Debian of mine at this time:

Code: Select all

$ ls -ABRgo Deb_140912-ffmpeg-h_full_???.txt 
-rw-r--r-- 1 300104 Sep 12 21:59 Deb_140912-ffmpeg-h_full_NEW.txt
-rw-r--r-- 1 310469 Sep 12 22:02 Deb_140912-ffmpeg-h_full_OLD.txt
$
To cut this presentation shorter a little, the NEW is missing stuff, like libvorbis, amr, vp8.

But this still proves that this what I long for must be possible. And also: that it really is not blocked at the upstream, desire like mine, to live with pure programs, without the multiseated ones, in the case of FFmpeg.

We are of cause talking of the real FFmpeg, who the "obsolete" one (It was touted, in Debian, and members of Debian team have nothing to do with politics?... It was, for quite some time, touted, by some members of the Debian packaging team, those who get the wording that newbies read such as in aptitude --I was back then a newbie in Debian-- it was touted as obsolete. Yes, when I tried to install FFmpeg, I was told that it was obsolete and that I had to use aconv. So much about politics. From me, who have been Offtopic'd quite a few times for speaking my opinion).

Back to Mplayer install.

Without dbus/systemd and any of poetteringware (if you've just parachuted in here).

I'm tired. I'll try and just find the final config.log or somesuch...

No. It's the make. Which failed.

After ./configure line as (much further) above, I ran:

Code: Select all

make
[2]

and this is the output, shortened:

Code: Select all

help/help_create.sh help/help_mp-en.h UTF-8
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o command.o command.c

...[snip]...

cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o stream/stream_bd.o stream/stream_bd.c
stream/stream_bd.c: In function 'get_clipinf':
stream/stream_bd.c:416:39: warning: variable 'end_offset' set but not used [-Wunused-but-set-variable]
     int langmap_offset, index_offset, end_offset;
                                       ^

...[snip]...

libmpcodecs/vf_screenshot.c: In function 'draw_slice':
libmpcodecs/vf_screenshot.c:161:9: warning: passing argument 2 of 'sws_scale' from incompatible pointer type [enabled by default]
         sws_scale(vf->priv->ctx, src, stride, y, h, dst, dst_stride);
         ^
In file included from libmpcodecs/vf_screenshot.c:41:0:
/usr/include/libswscale/swscale.h:226:5: note: expected 'const uint8_t * const*' but argument is of type 'unsigned char **'
 int sws_scale(struct SwsContext *c, const uint8_t *const srcSlice[],
     ^
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o libmpdemux/demux_lavf.o libmpdemux/demux_lavf.c
libmpdemux/demux_lavf.c: In function 'demux_lavf_fill_buffer':
libmpdemux/demux_lavf.c:659:5: warning: 'destruct' is deprecated (declared at /usr/include/libavcodec/avcodec.h:1156) [-Wdeprecated-declarations]
     if(pkt.destruct == av_destruct_packet && !CONFIG_MEMALIGN_HACK){
     ^
libmpdemux/demux_lavf.c:659:5: warning: 'av_destruct_packet' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3612) [-Wdeprecated-declarations]
libmpdemux/demux_lavf.c:663:9: warning: 'destruct' is deprecated (declared at /usr/include/libavcodec/avcodec.h:1156) [-Wdeprecated-declarations]
         pkt.destruct= NULL;
         ^
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o stream/stream_ffmpeg.o stream/stream_ffmpeg.c
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o sub/av_sub.o sub/av_sub.c
cc -MMD -MP -Wundef -Wall -Wno-switch -Wno-parentheses -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Werror-implicit-function-declaration -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -fno-tree-vectorize -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4  -fpie -DPIC -D_REENTRANT  -I/usr/include/freetype2 -c -o libmpcodecs/vf_fspp.o libmpcodecs/vf_fspp.c
libmpcodecs/vf_fspp.c:51:32: fatal error: libavutil/internal.h: No such file or directory
 #include "libavutil/internal.h"
                                ^
compilation terminated.
Makefile:758: recipe for target 'libmpcodecs/vf_fspp.o' failed
make: *** [libmpcodecs/vf_fspp.o] Error 1
I surely can't leave a 309K entire in here, but I can tell you that:

Code: Select all

# grep -i alsa <the-file-containing-the-entire-output-of-that-make>
#
returns empty string.

To alsa only through the intermediary, the Poettering's own pulseaudio! Why?

It I am not mistaken. Why?...
EDIT: This is part of the latest edit. Somewhat mistaken. I was missing some alsa*dev or such packages.

Actually the error reported at the end doesn't have any alse in it either, and I don't know what it means, that:

Code: Select all

make: *** [libmpcodecs/vf_fspp.o] Error 1
But alsa is conspicuously missing. Don't know what to do.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

[1] I think I get it. I need to install some *alsa*dev or such packages. They are missing. This is the latest EDIT.

[2] Just to demonstrate a previous point for poeple needing to compile programs from upstream, and not apt-get them, the command was actually:

Code: Select all

make 2>&1 | tee /somewhere/mplayer_140912_`date +%H%M`_make.txt && find / -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt && make install 2>&1 | tee /somewhere/mplayer_140912_`date +%H%M`_make_install.txt && find / -name '*' 2>&1 | tee /somewhere/FIND_`date +%y%m%d_%H%M`_`hostname`.txt &
And then the diff get's me what it would install, but make failed, in this case. But that is my way to track what was installed.

The 2>&1 | tee I explained here:

How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php? ... 64#p552775

And I sadly keep misposting things, somewhat. I meant this for that topic not this. But I hope it's not such bad confusion. Just as I posted some talk which wasn't purely technical there, and meant it here. Sorry!

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 10:20
by timbgo
timbgo wrote:With mplayer goes also mencoder. And I use my old command line to capture DVB from an old TV card on whichever of the Debian boxes that I install the TV-card in (physically in the PCI-slot). If I were able to get that mencoder to do the work, that would be a major breakthrough.

Yes, getting mencoder to work on my no-dbus, no-systemd, no-policykit, no-pulseaudio, no-any-poetteringware, would be a major breakthrough, because it would without much doubt prove that potteringware is really just an overhead on top of real programs, that can perfectly, although not at all easily at the current state of affairs, be done away with.
I made it.
But give me time to pull myself together first.
It was costly in nerves. Looked impossible. It would have been almost easy if I had been informed, and no one is.

Rest first.

Miro

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 12:50
by keithpeter
adenukolnis wrote:You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends.

Code: Select all

keith@kona:~$ dpkg -l *dbus* | grep ii
ii  libdbus-1-3:i386      1.8.6-2      i386         simple interprocess messaging system (library)
ii  libdbus-glib-1-2:i386 0.102-1      i386         simple interprocess messaging system (GLib-based shared library)
keith@kona:~$ dpkg -l *systemd* | grep ii
keith@kona:~$
Managed to keep it down to just a couple of the libdbus libraries on the 'init agnostic' desktop (see signature link). The wpasupplicant package depends on one of these, and I need my wpa2 wifi! Dbus is in base so you have to remove it.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 16:20
by timbgo
keithpeter wrote:
adenukolnis wrote:You will not have much of a system at all without the libdbus package. I install it since so many packages have it listed as a depends.

Code: Select all

keith@kona:~$ dpkg -l *dbus* | grep ii
ii  libdbus-1-3:i386      1.8.6-2      i386         simple interprocess messaging system (library)
ii  libdbus-glib-1-2:i386 0.102-1      i386         simple interprocess messaging system (GLib-based shared library)
keith@kona:~$ dpkg -l *systemd* | grep ii
keith@kona:~$
Managed to keep it down to just a couple of the libdbus libraries on the 'init agnostic' desktop (see signature link). The wpasupplicant package depends on one of these, and I need my wpa2 wifi! Dbus is in base so you have to remove it.
But the quote doesn't contain (because it's in the signature) the page that put back the smile of on my face, as I've been recovering from some degree of exhaustion before my breakthrough (report still to be written):

An init agnostic old school desktop (Jessie)
http://sohcahtoa.org.uk/osd.html

On another note, I have to catch up with reading edbarx's thread:

The future with Systemd
http://forums.debian.net/viewtopic.php? ... 60#p552005

which also managed to slipped from my attention. Learned that it has grown much only from keithpeter's page above.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 16:40
by buntunub
As a long time Debian user, I have to say that I am floored by the efforts you folks are putting forth on this. I applaud you! It appears to me that there is widespread discontent with the Systemd Corporate takeover, and it begs the question... How was the decision for Debian to move to Systemd made? Was it done using the Debian guidelines on such things?.. I recall when the decision was made to move to GNOME3 that the reasoning foisted upon us all was that GNOME2 was going to be discontinued, and that may have been true, but is SysVInit being discontinued? If not, then WHY the wholesale move to Systemd?

Think on this. If Debian decided to stick with SysVInit, would that negatively impact Debian in any way? For instance, would dependancies become a problem in future Testing distros? I can see how that could become a problem in the very long term, but I do not think that is an excuse to abandoned the core Linux philosophy since its founding. Many big names in the Linux world have asked the questions, and to my knowledge, there has been no reasoned debate on the adoption of Systemd. There was just a dictatorial decision made on high. This is not the Debian way, and TBH, it is the Debian community that must bring this to heel.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 17:39
by edbarx
To add insult to injury, systemd was voted for, with the blessing of a casting vote! :shock:

systemd and similarly written software, is an attack on modularity, greatly harming the flexibility for which GNU/Linux is well known. systemd & co are clearly aimed at creating yet another Windows.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 18:36
by keithpeter
buntunub wrote:As a long time Debian user, I have to say that I am floored by the efforts you folks are putting forth on this.
In my case, just half a day's work and a couple of test installs on an old laptop. Edbarx and adenukolnis are doing a lot of mapping out and reading source code &c. I'm just testing their findings.

Keep an eye on the *BSD world, e.g OpenBSD, FreeBSD. They have no choice but to find a way out of this mud ball as they do not have the resources to fork whole desktop environments and sub-systems like dbus and even udev.
buntunub wrote:Many big names in the Linux world have asked the questions, and to my knowledge, there has been no reasoned debate on the adoption of Systemd.
Read Cathedral and Bazar (esr). I think the desktop environments started wiring systems together to make things slicker and allow plug and play. Then the systemd people sort of worked round what was there. The result is multiple intertwingling random walks. GNU/Linux does not have an overall design as such, just thousands of detailed decisions that edge one way then another, but which get 'frozen in' as we move forward. Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.

Interesting that the small projects (Slackware, *BSDs) are the ones taking an opinionated line on this based on overall architecture.
edbarx wrote:To add insult to injury, systemd was voted for, with the blessing of a casting vote! :shock:
Remember that we have 10 to 20 years of systemd because of the adoption in the EL world (RHEL, Centos, Oracle &c) with their 10 year support horizons. Irrespective of the Tech Committee's vote, systemd would be out there and upstream projects would be assuming its presence to some extent.

I think that the story is about supporting diversity and promoting modularity as ebarx and others keep saying.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 18:53
by edbarx
In 10 or 20 years, there will be developments, and the negative impact of projects like systemd, will be attenuated. GNU/Linux works much like biological systems: there is no centralised control, and yet, it worked for at least the time it existed. systemd and co. is an attempt at streamlining GNU/Linux, especially GNU desktops, but the great drawback of this approach is, this same strategy kills diversity at the core of the system. It also takes away modularity which allowed many diverse systems to be configured straight from the kernel upwards.

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 18:58
by goulo
keithpeter wrote:Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.
Gentoo! (or maybe you're not considering it "major"?)

If down the road I find systemd becoming required (or too difficult to avoid) on my Debian, I'll switch to Gentoo or one of the BSDs...

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-13 20:04
by keithpeter
goulo wrote:
keithpeter wrote:Debian was the last major distro to switch to systemd and is the only one that is preserving alternatives to my knowledge.
Gentoo! (or maybe you're not considering it "major"?)
Apologies! I should have said 'high volume' rather than 'major', just number of users no implied comment on 'quality' :oops: I mean't the likes of RHEL/Fedora and the clones, SLES/openSUSE, Debian/Ubuntu/downstream distros.

A new twist on the Old School Desktop: installing cups with --no-install-recommends brings a systemd library called libsystemd-daemon0 which itself seems to have no dependencies on anything other than libc. Adding xpdf and the splix drivers gives me printing functionality and the poppler tools (pdfunite &c) which I use a lot.

https://packages.debian.org/jessie/libsystemd-daemon0

Back to edbarx's points about modularity. Why is this package a direct dependency of CUPS and not a dependency of one of the core systemd libraries if it is needed when using a systemd based init? I'll try and track that one through...

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-15 01:04
by timbgo
Since the previous speakers talked a little of not-such-volume but the-most-diversity Gentoo GNU/Linux distribution, let me make good on a previous promise of mine.
timbgo wrote:Allow me to tell you that on Gentoo, quite a number of people decided to go without those multiseat[s].
Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-9 ... ight-.html
But we have a few developers there that openly care for the Fourth Amendment to the Constitution to the United States (such legislature is generally in all democratic countries' constitutions; for the less initiated in legalese, it's your right to privacy, secrecy, in your communications). Aarghh, this calls for a quote, and I can only promise I will try to be back to insert it here... wait...
Nope, haven't found the talk, but it's blueness, a Council Member https://wiki.gentoo.org/wiki/User:Blueness
( typoes corrected, quoted text cleaned a little )
And, since we have other academics around (keithpeter:

http://sohcahtoa.org.uk/
Keith Burnett
Teaching maths post-16 in Birmingham UK.

), let me tell you more about this guy (I couldn't talk like that of a Professor, or to a Professor back when I studied at the University of Zagreb in the late 1970s, and I like this change); oh dear, do I like Latin!:

Anthony G. Basile, Curriculum Vitae
http://opensource.dyc.edu/basile-cv

Here's Anthony defending privacy:

http://blogs.gentoo.org/blueness/2014/0 ... y-or-exit/

And next link is where you can best understand what eudev is.

In particular take notice of the discussion btwn ssuominen, the main implementer in Gentoo of udev (integrated with systemd, can't be separated from it, works only when systemd is in the system), and blueness, one of my heroes in the FOSS, the main developer of eudev, the free-from-systemd fork of udev, that just you-don't-ever-notice-it works.

eudev vs udev - current user perspectives
https://forums.gentoo.org/viewtopic-t-9 ... rt-25.html

I have been working on liberation-from-systemd-and-associates issues since I posted here last.

But I haven't yet started writing the planned report how I managed to get my box poetteringware-free and somewhat functional, because I went and read all on the other topic that edbarx started.

And do you think I didn't end up reading all that has been discussed anew on the systemd issue on debian-devel list?

I did, but only after having read other great blogs and webpages on the matter, and viewed a few very, very important videos (of course, I viewed them on a clone machine of my somewhat successful no-poetteringware Debian master machine), videos which are very much, although indirectly, on the subject (but from a broader view, from the big picture prospective).

What I will be able to share with you on the latter matters just above, just given a foretaste in this post you are now reading, is hard to tell. I've been reading, watching, thinking, weighing people's POVs, presentations, decisions (sic!) on this Debian-break-or-not, Debian-defeat-or-some-hope-left poetteringware-imposed-or-not issue for all this a day and more hours, and it's all so profoundly in my mind, but very unsorted...

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-15 06:53
by timbgo
GNU freedom software users and developers are a very mixed crowd.

Looking back, to me, if love of knowledge is anything to be admitted among the most noble of virtues a man can possess, I am glad to remember how my first encounter with Grsecurity/Pax twin pack of programs back some three years ago, was love at first sight, just like the hatred of the NSA's SELinux, sadly holding onto the majority of GNU/Linux installations of today, was a guts feeling right from the very first encounter.

I can not tell how happy I am that my Tips page:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616

has had more views in the few recent days than previously in months...

I can not tell for certain, there is more to a man's life than his own knowledge of himself, more to his words than his own mind, but I have a similarly good feelings and hopes, or gut aversion and hatred, about other programs of the realm of GNU/Linux, and at this point BSD family and other *nix have to be taken into considerations.

I have just started this my new post in this "How to avoid Stealth Installation of systemd" topic in Debian Forums talking of programs good and evil, almost morally so; but sure it' the developers that are such: it's the author's honesty or lack thereof which is reflected in his programs, just as it is the artist which is (spiritually) seen in his picture or heard in his music.

I started on morality, and lack of, in the truly honest and moral GNU ground, where things can grow; they really can't, no, in proprietary swamps and deserts; those are aberration, abomination under nice looks and guises. Only GNU/BSD/other-free-licenses, they are the sole ground for growth of meaningful human works, and the sole ground of defence in the global Orwellian society, post-Snowden time, which is ticking on us.

And I started on morality because I see the following articles as honest and moral, as truthful, the following articles which were written by someone whom my hero Professor from the previous post of mine in this topic recognized as true developer and chose his work for his newest flavor in Gentoo, this one:

Project:Hardened musl
https://wiki.gentoo.org/wiki/Project:Hardened_musl

I am talking about articles by Rich Felker, developer whose integrity reflects in his work:

http://www.musl-libc.org/

These are the articles:

Broken by design: systemd
http://ewontfix.com/14/

Systemd has 6 service startup notification types, and they're all wrong
http://ewontfix.com/15/

I have nothing to add there, since these people are a few classes away in FOSS than me. I am a poor user fighting for his chances to securely use my conputers, poor user forced into never-ending research and finding his own technical solutions, else would have been owned.

But I did learn a lot in my quest, and I can tell other users (and I always have newbies at heart) a piece of advice here and another one there, thankfully.

On the above Rich Felker's perfect diagnose on the sick systemd program, my advice even to newbies very fresh, is: give it a read, take the little that you currently can out of it, and come back once you have grown bigger in GNU/FLOSS, that next time you read the pages of true knowledge like those, more insight descends into your spirit.

Let's now talk more of morality and immorality, of honesty and truth in the GNU/FLOSS works and societies.

Can I go straight to what even the great honest spy (being a spy doesn't have to mean being dishonest; there are moral people in every walk of life), what even the great honest spy Edward Snowden didn't know about:

http://video.fosdem.org/2014/Janson/Sun ... eport.webm

And I want to use the opportunity that Debian provides in its Social Contract:

https://www.debian.org/social_contract
3. We will not hide problems
We will keep our entire bug report database open for public view at
all times. Reports that people file online will promptly become
visible to others.
and hope that I won't be accused of copyright breach (

Really? The Surveillance Engine Terminated All My Videos
http://forums.debian.net/viewtopic.php?f=3&t=113059

) for taking literally down the sermon by Poul-Heening Kamp, as I will listen to that video, link further above, entitled "NSA operation ORCHESTRA Annual Status Report" on my no-poetteringware Debian box. A note. PHK is in his speech impersonating, as if representing, the NSA, "us", "we", means them in the transcription below:
Poul-Heening Kamp wrote: ...So, this is our poster boy: the Debian random number generator.

This is really beautifully executed.

This is due to {ascend in a path} [a guess, is unintelligle], you know, this gets Valgrind to complain, and I can't see it does anything sensible. You should just remove it.

And they did.

So for two years all the Debians had lousy random numbers which made bruteforcing SSL and stuff, like that...: done.

You earned a pretty good bonus.

OpenSSL is the crown jewel.

OpenSSL is the standard library if you want crypto.

Getting SSL to work against all browsers and all that stuff without using OpenSSL is very very tricky.

Reading the OpenSSL manuals or source code, is not tricky, that's close to impossible.

And that's 300,000 lines of code, so good luck with that!

The documentation is deficient and misleading, and the defaults are deceptive. They don't do what you think they do.

This saves so much money in the collection, you have no idea.

So the overall status of the Operation Orchestra. It's a resounding success.

We spend less than a third of a percent of the NSA budget.

And it'd probably cost the collection cost by something like 50 %.

It's kept most of the Internet in plaitext, and it has never been exposed (in the press).

Edward Snowden has no papers on Orchestra at all.

...[snip]...
Pls., gentle reader, go ahead, and have a listen (the link is further above now). You will understand that all the FLOSS (the GNU/Linux, the BSD as well!, other *nix distros as well!) are pretty infiltrated.

But not taken over. Not yet! I dare hope, am almost confident they never will be.

So the page where I got the link to the 2014 FOSDEM (Free and open source software developers' European meeting) conference, the page below, has a flawed title, but what can you? You live with your mistakes as well as with your successes:

Julian Assange: Debian Is Owned By The NSA
https://igurublog.wordpress.com/2014/04 ... y-the-nsa/

(pls. also notice further in the page that Wikileaks was officially denying, and previously to reaching that point in the page I listened to Julian's in the World Hosting Days 2014, specifically for that line and couldn't really hear such explicit statement at all)

That page however is so plausible about the reasons our GNU/Linux generally being owned by some particular entity.. Of which further below.

First let me transcribe what Julian said by video link from his exile in Equadorian Embassy in London.

The video was posted on Youtbe channel: "Даниил Иваньков" (which is Cyrillic azbyka, in Latin alphabet: Danyil Ivañkov, approximately)
Julian Assange wrote: That's one of the amazing things about encryption, that somehow the Universe has permitted the type of mathematics, the type of physics which permits the resistance against unlimited coercive force: it doesn't matter how many soldiers, how many guns, how many nuclear weapons you have, if your encryption system is right, it can pass through the United States, it can effectively create a channel through a hostile country the way you can send, political... economic and political information, bringing two greater societies together, in this case Latin America and Europe.
...[snip]...
BBC Click Online presenter wrote: Now, one of the big topics here is open source and I'm wondering whether the fact that you have an open system that everyone knows how it works would make encryption more secure than a closed system.
Julian Assange wrote: Oh, we know from experience that it does seem to be the case, that there's a vast number of closed source snake oil encryption systems being spread around.

Now we know that Open Source is not entirely a solution, e.g. there was an encryption bug in the Debian's version of the SSH in the Random Number Generator which existed for years, and that was all open source.

Now it was eventually found and revealed, and it was found and revealed also because it was open source.

But the way things are done now is through backdoors. So these are backdoors designed to look like bugs.

And, you know, what is the security of the programmers who are involved in some of these open sources. Can you, when they do, I say, update their code, can you plant what looks like a bug, even a typo, that carries through?

Or, say, look at a... a system like Debian, these units, the various kinds of unit systems, look at all the packages they include. look at the upstream libraries, dependencies upon dependencies upon dependencies, and all you need to do is compromise one of those dependencies and there's a flow through and {these are getting back} [a guess, is unintelligle].

Modern systems are assembleges of incredible intellectual content which is being developed all over the world over the past ten years by many different players.

But there's an age now [a guess, is unintelligle] in CPUs, there's few, you know maybe three different securities layers in these systems.

But when you pull together thousands of packages altogether, it's pretty hard to actually resist the security compromises that are engineered by nation states.

It doesn't mean it's not worth trying, increasing the cost of owning the world.
...[snip]...

And I'd like to write more.

Don't worry, I have all the logs (taken with "... 2>&1 | tee ...", as explained previosly, and stowed away, and enough of history lines, to most likely reconstruct pretty much exactly how I succeeded in getting my no-poetteringware Debian to work).

But I might possibly first want to finish on these points about infiltration of "friends of NSA" into FOSS and also first give my review on the recent discussions on systemd on debian-devel, similarly to the first report of mine with which I started this topic. If I make all of that. It's really complex. All of it one and the same big picture, and that is what makes it all so much more harder to grasp and even harder yet to explain.

I might first need some rest. Of, if I can, normal duration. Or else go almost sleeplessly on after very short break. Don't know yet.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Re: How to avoid stealth installation of systemd?

Posted: 2014-09-16 12:51
by timbgo
PART 1

of my insight into debian-devel mail-list "Stealth Installation of systemd?" thread in September 2014, only under various retitles

this is (if I'm not Offtopic'd or banned from the forums, not that there's any reason for it, but I have been banned for too little or false reasons).

PART 2/and more? yet to be written.

Also, take heed of what I'll tell you now: I can access mostly anywhere on the internet now, except for I can't access the links below, such as:
https://lists.debian.org/debian-devel/2 ... 00087.html
and any starting with that string:
lists.debian.org/debian-devel/2014/09/msg
of course with the http and :// in front,
(and that state has been lasting for more than an hour on every connection).

which I anyway have all of them in Iceweasel cache, so I *can* write this post and hopefully the followup.

Just telling. Pls. do tell if the links don't point to the text reported.

################################################################################################
If anyone thinks that this:

How Covert Agents Infiltrate the Internet to Manipulate, Deceive, and Destroy Reputations
https://firstlook.org/theintercept/2014 ... ipulation/
by Glenn Greenwald

has nothing to do with these dictatorial changes in Debian Schlinux
( why schlinux? see here:
The future with Systemd
http://forums.debian.net/viewtopic.php? ... 05#p553351
)

than they are either autodeceiving or deliberately not telling the truth.

For the latter, and to minor extent for the former, there is one word in plain English. If I had to say it to myself about myself, like those should, I'd be ashamed. So I'm being considerate.

Have a look at this derising attitude:

https://lists.debian.org/debian-devel/2 ... 00087.html
Rens Houben wrote: In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell has been seen typing:
Svante Signell wrote: Some food for thought about systemd:
... I thought we'd all agreed to stop bringing up tired arguments that
nobody but the "systemd MUST DIE" crowd really wants to hear anymore.
Svante Signell wrote: You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/
"Open source Tea Party". That explains *so* much...
What does that explain, dear developer-and-systemd-impositioner on Debian users? Your sorrow for the United States not being under British Crown?

We could talk like that...
Rens Houben wrote:
Svante Signell wrote: Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
"If we keep systemd, people who want to boycott systemd will boycott
us." Seriously, can we stop with the circular arguments as well?
Yes, seriously, we will! Lots of users will *not* remain with systemd-only-Debian!
The circle will have an exit, and for many, dear developer-and-systemd-impositioner on Debian users.

Your only chances are hiding what is happening. But that is to greater users' outrage later! Everything comes out, eventually. Snowden, Assange, IgnorantGuru, are some of many. I hope we will know more on who and how has ruined g-NSA's Schlinux and Debian in particular.

And also read this:
Rens Houben wrote: On Mittwoch, 3. September 2014, Svante Signell wrote:
Svante Signell wrote: Some food for thought about systemd:
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
debian-devel@ is for the development of the Debian distribution, not for
ranting. Please take your rants elsewhere. It's tiring and a waste of your and
many other peoples time. But it wont change things. Code changes things in
Debian.
What ranting? You call this concerned call for reason ranting? Unbelievable.
So many users, it's true: only those that can phathom it despite of the corporate propaganda, wish for systemd-free Debian Jessie!

Despite the corporate, with all of their tentacles in Debian, propaganda, which turns around many and makes them dazed and confused as to what they even could remember and know because they learned it in previous experience, and which keeps so many plain ignorant on what is being planned with, really, their computers, but so many users' wish for systemd-free Debian Jessie, and there's a DD who cares, and you call his forsight of the certain outcome in case of sytemd-imposition, you call his few open words of care and caution ranting?

Look up the followups to that mail (not reporting those here). Rens Houben obtained even Swante's apology for having brought those links to DDs pseudo-corporate attention (because it's corporate in the shadows, Schmoogle/Red Hat/NSA, really looks like)! No, Swante, you had nothing to apologize for, and you should not have apologized.

And there was this explanation of, cough cough, Debian happy democracy happenings by Marco d'Itri.
https://lists.debian.org/debian-devel/2 ... 00095.html
Marco d'Itri wrote: On Sep 03, Svante Signell wrote:
Svante Signell wrote: Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.
And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.
And there Marco gives us the graph telling about (yes: as far as that complete post, eplanations afterwards come after) the democratic likes of Debian crowds:
Oh, you can't care for everybody's needs. You'll take all the fewer that witlessly or for their windoze mentality go for the systemd (my guess: less than say one in ten), and all the uninformed, the huge chunk of the Debian population now in systemd who are uninformed, and those are now in systemd because it was imposed on them, or soone is to be imposed, without them ever having given a choice, and which are probably around nine out of ten, and you keep disparaging, pushing aside, ignoring the mostly advanced and informed who are, my guess, maybe one in ten among the Debian users. (The ratios are very approximate guesses that I gave in this paragraph.)

And of all the mix, you couldn't care for whoever don't want systemd. It's systemd-or-die attitude.

Because I don't think there is any plausible denying that the thinking in among the Debian huge crowd are in their great majority against systemd, and there are also many who plain and open don't want to even stay with Debian if there is only systemd-Debian to be

And you can't accomodate for them?

How nice and clean of you! A great DD this one! Red Hat's and Schmoogle's will sure like this one!

Luckily, a DD whom I admire for his defence of FOSS and defence of Debian Social Contract, and a member of the Debian Technical Committee who voted against systemd as default in Debian, along with Ian Jackson, replied what was due to our dear Marco.

https://lists.debian.org/debian-devel/2 ... 00105.html
Steve Langasek wrote:
Marco d'Itri wrote: And I strongly encourage them to do this: we aim to be universal but we
cannot reasonably fit everybody's needs.

< link given above, not duplicated here >
Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

Code: Select all

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu dot com                       vorlon at debian dot org
If I have any hope left in the FOSS, it's people like Steve. And Cameron below.

Because there followed a great explanation, so pls. you people who are reading this, along with administrators who are assessing whether to maybe even throw me offtopic or ban my post, as you have done in the past, consider that I do not blame DDs as the community, just there is something wrong, probably corruption of some kind, some breaking of Debian Social Contract and Debian Free Software Guidelines, in the Debian hierarchy and in among the decision making high ranking Debianers...

And there followed a great explanation by Cameron Norman:
https://lists.debian.org/debian-devel/2 ... 00109.html
Cameron Norman wrote: El mié, 3 de sep 2014 a las 4:07 , Marco d'Itri escribió:
Marco d'Itri wrote: On Sep 03, Steve Langasek wrote:
Steve Langasek wrote: >
https://qa.debian.org/popcon-graph.php? ... beenhere=1
< link repeated for clarity, although already given further above, and it is by Marco, but quoting allowed only 3 deep >

Please stop using graphs showing how various teams have forced systemd onto users' systems as if it is somehow a democratic endorsement of the outcome.
I am not sure about how the concept of democracy applies to this, but the graph clearly shows that nobody is being forced to do anything and indeed about 4000 users choose to install systemd-shim and to not use systemd.
Ok, let me explain Steve's POV. Many packages depended on libpam-systemd before systemd-shim was ever in the archive, leading to systemd-sysv being installed by a normal dist-upgrade on Sid (and, although I am not sure, testing). The alternative was often to have GNOME or Network Manager removed, two very popular packages (and the latter quite important). Even after systemd-shim was uploaded to the archive (still at logind v204 here), libpam-systemd depended on "systemd-sysv | systemd-shim". This meant that users' systems would switch init systems on a normal dist-upgrade *unless* they manually intervened and knew which package they had to install to avoid that. Finally, systemd v208 was uploaded to unstable with an unconditional dependency on systemd-sysv. All of these actions led to users experiencing a change of init system before they had taken action to change init systems, which means that the graphs are not reliable in claiming that the majority of users wanted systemd as their init system.

I can not speak for Steve, but I recognize that some or all of those actions above were called for. The final one especially (systemd v208 upload), since their was ample warning and communication (something like one or two months I think), the move was a long time coming, and systemd was chosen as the default init system by then (not true for the other two actions).

I hope that helps you understand how the graph does not depict how many users elected to use systemd as their init system.

Best regards,
--
Cameron Norman
I understand most of it, and obviously systemd was imposed. It's use-systemd-or-die Debian decisioners telling us!

One of the really sincere and honest proposals also followed on the list.
Noel Torres wrote: On Wednesday, 3 de September de 2014 16:21:31 Svante Signell escribió:
Svante Signell wrote: [...]
should be allowed, and I'm trying to find out how many of debian users
and developers are interested in working together with me on such a
solution. Best would be to have an option in the installer (hidden by
[...]
I volunteer to test this, not for contributing (I am not a programmer), for a very simple reason: I do not want my long-running servers (and those of my clients) to be rebooted for something that should be so simple as upgrading a service or applying some non-kernel security patch.

I may have (I agree I have) some conservative thinking. I've been well against network-manager messing my interfaces
I also live without that windozed and windows-looking piece of software-maybe-spyware (don't know). A Linux user should know how to issue "ifconfig eth0", and having direcories or files (can't remember now, I've lived without it since 2013) in /etc with spaces in their names, that was more than I could bear.
and I'm against systemd as well, but I really think the Unix way, when properly implemented, is the way to go. And if it does not work, make it work instead of building a dinosaur and force dependencies into it (and yes, I'm pointing at you, Gnome Debian packagers, both for network-manager and systemd).

In resume: count on me to test and check and report bugs and triage.
Miroslav Rovis
Zagreb, Croatia,
http://www.CroatiaFidelis.hr