Refracta Development, Scripts, etc.
Post a reply

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 10:53 am

Code:
root@jessie-sysv:/home/user# aptitude -s install avidemux
The following NEW packages will be installed:
  avidemux avidemux-common{a} avidemux-plugins{a} avidemux-qt{a}
  libaften0{a} libqt4-opengl{a} libqt4-script{a} libqt4-scripttools{a}
  libqtgui4{a} libtwolame0{a}
The following packages are RECOMMENDED but will NOT be installed:
  lame mjpegtools twolame
0 packages upgraded, 10 newly installed, 0 to remove and 1 not upgraded.
Need to get 11.1 MB of archives. After unpacking 36.1 MB will be used.
Do you want to continue? [Y/n/?]


I had to upgrade first, because it wanted a newer qdbus. And I had to pin and hold bsdutils before I could upgrade. 'apt-get dist-upgrade' failed with this error:
Code:
Errors were encountered while processing:
/var/cache/apt/archives/libjpeg-progs_1%3a9a-2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

And then 'aptitude full-upgrade' worked with this solution:
Code:
The following packages have unmet dependencies:
libjpeg-turbo-progs : Conflicts: libjpeg-progs but 1:9a-2 is to be installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     libjpeg-turbo-progs         



Accept this solution? [Y/n/q/?]
The following packages will be REMOVED:
  libjpeg-turbo-progs{a}
The following packages will be upgraded:
  libjpeg-progs
The following partially installed packages will be configured:
<snip big list>

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 2:38 pm

Had the libjpeg-turbo-progs problem (nothing to do with avidemux) already but don't remember how it got sorted. Always best to stay dist-upgraded unless there is a good reason not to. Watch out with deb-multimedia packages, there can be compatibility issues you must manually fix (has been known to break vlc)

Just done dpkg-buildpackage on util-linux 2.25.1-5 Debian source. Changed a few things first in debian/rules to remove systemd support/dependency and a few other files with systemd references (use grep -r to find them).

19 debs produced.. including bsdutils (minus libsystemd0 dep) which is now installed. No problems seen so far.

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 3:12 pm

dzz wrote:19 debs produced.. including bsdutils (minus libsystemd0 dep) which is now installed. No problems seen so far.


Only another 30,000 to go. Maybe we can recruit some help and do them all, make a whole new repo and call it Ebian (debian without the d).

Kidding aside, I hope you're going to share these with us.

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 3:31 pm

dzz wrote:Watch out with deb-multimedia packages, there can be compatibility issues you must manually fix (has been known to break vlc)

Yes, have been there, done that. Have very few dmo packages installed. avidemux has it's own internal ffmpeg so that reduces the conflicts.

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 6:04 pm

http://exegnulinux.net/refracta/experim ... emd.tar.gz

has cups, dbus, util-linux, pulseaudio built without systemd support/dependency. They are unfinished (needs at least version-renaming) and not properly tested. They might break or break something else.

This is a lot of work and my experience in dealing with source compilation is only slightly greater than zero; this is a "quick fix" for now only. However I will be very surprised if others, of much greater capability, are not soon on the case of similar to what has begun here.

There are not 30, never mind 30,000 essential packages with systemd dependencies (discounting gnome). So far it seems (mostly) these dependencies are introduced in Debian rules and patches. This is current Debian policy, not the fault of upstream maintainers of cups, xfce and others.

Re: Going with the systemd flow . . . or not?

Wed Oct 22, 2014 9:11 pm

dzz wrote:... this is a "quick fix" for now only. However I will be very surprised if others, of much greater capability, are not soon on the case of similar to what has begun here.

There are not 30, never mind 30,000 essential packages with systemd dependencies (discounting gnome). So far it seems (mostly) these dependencies are introduced in Debian rules and patches. This is current Debian policy, not the fault of upstream maintainers of cups, xfce and others.


I registered to just say thank you. The work you and all the people in this thread are doing gives me hope. I will be referring back to this thread often to make sure I have the latest info (and .isos) on Refracta, Antix, and others who are inclined to resist the coup. (I'm investigating Gentoo and Slack as well, though there be much pessimism about the long term, just under the surface of their speech.)

I hope you're right, about the 'others' seeing the need. I'm very motivated to support such efforts, financially and technically, to the best of my limited ability. Keep us posted.

Re: Going with the systemd flow . . . or not?

Thu Oct 23, 2014 6:31 pm

FWIW, evident in their latest release ( grml32-full_2014.10-rc1.iso ) grml.org is still avoiding systemd

Re: Going with the systemd flow . . . or not?

Fri Oct 24, 2014 1:29 pm

Did an update/upgrade yesterday. Let aptitude do it, because it gave me a clear choice to keep bsdutils at the current version, instead of upgrading it. Well, it couldn't upgrade it, because I've got "*systemd*" pinned. Thought I'd try to repackage it without the systemd dep. This is what I got with 'apt-get build-dep util-linux'

E: Build-Depends dependency for util-linux cannot be satisfied because package dh-systemd has no candidate version


So I commented out my systemd pin and tried again (with -s). And of course, it wants to install systemd. Do I need to start with the upstream tarball, or do I just need to sacrifice an installation to the systemd gods for this purpose?

Re: Going with the systemd flow . . . or not?

Fri Oct 24, 2014 5:10 pm

I didn't think much and haven't used Debian in a while:
1) I guess that "apt-get build-dep" does not care for the entries in debian/control, but get the info online
2) I would install the dependencies from the cli, whatever "dpkg-buildpackage" complains about
3) I would take care to also remove systemd entries in BuildDeps, not only in Deps (debian/control file)
4) I think build-deps only matter for building, but are not needed to run/use an app. So one could install them for building, remove them after that is done.
5) I don't think the upstream tarball is needed

apt-rdepends util-linux | grep systemd
gives no output.

I chrooted to my debian-installation and neither can install nor remove any apps (aka: the deps). Something with ruby.
I will try to boot the installation later and try what i said above.

Just shooting in the dark, partly pointing out the obvious
Good luck.
Last edited by nadir on Fri Oct 24, 2014 5:15 pm, edited 1 time in total.

Re: Going with the systemd flow . . . or not?

Fri Oct 24, 2014 5:13 pm

pbuilder is a bit weird, i agree.
With the problem at hand it really might be a good option
(or just a simple chroot).
Not sure how well the pbuilder how-to at the debian wiki, page diaspora is. Should be a good one, try it,perhaps. The one at the ubuntu wiki isn't that bad neither.
Post a reply