[gentoo-user] Old Firefox ebuild?

[gentoo-user] Old Firefox ebuild?

[Ian Zimmerman]

Does anyone have a copy of the firefox 38.x ebuild around?

The latest update wiped it out, and now if I take the plunge to the
current versions (i.e. at least 45.x) and I find then insufferable, I
have no way back :-(

btw I do make regular backups, but not of anything under /usr.  This
will teach me.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Old Firefox ebuild?

[Mick]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

On Friday 14 Oct 2016 11:02:57 Ian Zimmerman wrote:
> Does anyone have a copy of the firefox 38.x ebuild around?

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/


> The latest update wiped it out, and now if I take the plunge to the
> current versions (i.e. at least 45.x) and I find then insufferable, I
> have no way back :-(
> 
> btw I do make regular backups, but not of anything under /usr.  This
> will teach me.

You could use 'emerge --buildpkg y' to build binary packages you can revert 
to, in case an update/upgrade breaks anything important.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Holger Hoffstätte]

On Fri, 14 Oct 2016 11:02:57 -0700, Ian Zimmerman wrote:

> Does anyone have a copy of the firefox 38.x ebuild around?

- go to https://gitweb.gentoo.org/repo/gentoo.git/log/www-client/firefox
- find the revision before the one that deleted 38.8
- select the "tree" view (above the path)
- copy everything you need

> btw I do make regular backups, but not of anything under /usr.  This

So in other words you don't make backups..

-h

Re: [gentoo-user] Old Firefox ebuild?

[Alexey Mishustin]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

Hello.

2016-10-14 21:02 GMT+03:00 Ian Zimmerman <itz@primate.net>:
> Does anyone have a copy of the firefox 38.x ebuild around?

Attached.

> The latest update wiped it out, and now if I take the plunge to the
> current versions (i.e. at least 45.x) and I find then insufferable,

Agree!

>I
> have no way back :-(
>
> btw I do make regular backups, but not of anything under /usr.  This
> will teach me.
>
> --
> Please *no* private Cc: on mailing lists and newsgroups
> Personal signed mail: please _encrypt_ and sign
> Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
>

-- 
Regards,
Alex

[-- Attachment #2: firefox-38.8.0.ebuild --]
[-- Type: application/octet-stream, Size: 11386 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI="5"
VIRTUALX_REQUIRED="pgo"
WANT_AUTOCONF="2.1"
MOZ_ESR=1

# This list can be updated with scripts/get_langs.sh from the mozilla overlay
# No official support as of fetch time
# csb
MOZ_LANGS=( af ar as ast be bg bn-BD bn-IN br bs ca cs cy da de el en
en-GB en-US en-ZA eo es-AR es-CL es-ES es-MX et eu fa fi fr fy-NL ga-IE gd
gl gu-IN he hi-IN hr hu hy-AM id is it ja kk km kn ko lt lv mai mk ml mr
nb-NO nl nn-NO or pa-IN pl pt-BR pt-PT rm ro ru si sk sl son sq sr sv-SE ta te
th tr uk vi xh zh-CN zh-TW )

# Convert the ebuild version to the upstream mozilla version, used by mozlinguas
MOZ_PV="${PV/_alpha/a}" # Handle alpha for SRC_URI
MOZ_PV="${MOZ_PV/_beta/b}" # Handle beta for SRC_URI
MOZ_PV="${MOZ_PV/_rc/rc}" # Handle rc for SRC_URI

if [[ ${MOZ_ESR} == 1 ]]; then
	# ESR releases have slightly version numbers
	MOZ_PV="${MOZ_PV}esr"
fi

# Patch version
PATCH="${PN}-38.0-patches-04"
MOZ_HTTP_URI="http://archive.mozilla.org/pub/${PN}/releases"

MOZCONFIG_OPTIONAL_WIFI=1
MOZCONFIG_OPTIONAL_JIT="enabled"

inherit check-reqs flag-o-matic toolchain-funcs eutils gnome2-utils mozconfig-v6.38 multilib pax-utils fdo-mime autotools virtualx mozlinguas

DESCRIPTION="Firefox Web Browser"
HOMEPAGE="http://www.mozilla.com/firefox"

KEYWORDS="~alpha amd64 ~arm ~arm64 ~ia64 ppc ppc64 x86 ~amd64-linux ~x86-linux"

SLOT="0"
LICENSE="MPL-2.0 GPL-2 LGPL-2.1"
IUSE="bindist egl hardened +minimal pgo selinux +gmp-autoupdate test"
RESTRICT="!bindist? ( bindist )"

# More URIs appended below...
SRC_URI="${SRC_URI}
	https://dev.gentoo.org/~anarchy/mozilla/patchsets/${PATCH}.tar.xz
	https://dev.gentoo.org/~axs/mozilla/patchsets/${PATCH}.tar.xz
	https://dev.gentoo.org/~polynomial-c/mozilla/patchsets/${PATCH}.tar.xz"

ASM_DEPEND=">=dev-lang/yasm-1.1"

# Mesa 7.10 needed for WebGL + bugfixes
RDEPEND="
	>=dev-libs/nss-3.21.1
	>=dev-libs/nspr-4.10.10
	selinux? ( sec-policy/selinux-mozilla )"

DEPEND="${RDEPEND}
	pgo? (
		>=sys-devel/gcc-4.5 )
	amd64? ( ${ASM_DEPEND}
		virtual/opengl )
	x86? ( ${ASM_DEPEND}
		virtual/opengl )"

# No source releases for alpha|beta
if [[ ${PV} =~ alpha ]]; then
	CHANGESET="8a3042764de7"
	SRC_URI="${SRC_URI}
		https://dev.gentoo.org/~nirbheek/mozilla/firefox/firefox-${MOZ_PV}_${CHANGESET}.source.tar.bz2"
	S="${WORKDIR}/mozilla-aurora-${CHANGESET}"
elif [[ ${PV} =~ beta ]]; then
	S="${WORKDIR}/mozilla-release"
	SRC_URI="${SRC_URI}
		${MOZ_HTTP_URI}/${MOZ_PV}/source/firefox-${MOZ_PV}.source.tar.bz2"
else
	SRC_URI="${SRC_URI}
		${MOZ_HTTP_URI}/${MOZ_PV}/source/firefox-${MOZ_PV}.source.tar.bz2"
	if [[ ${MOZ_ESR} == 1 ]]; then
		S="${WORKDIR}/mozilla-esr${PV%%.*}"
	else
		S="${WORKDIR}/mozilla-release"
	fi
fi

QA_PRESTRIPPED="usr/$(get_libdir)/${PN}/firefox"

BUILD_OBJ_DIR="${S}/ff"

pkg_setup() {
	moz_pkgsetup

	# Avoid PGO profiling problems due to enviroment leakage
	# These should *always* be cleaned up anyway
	unset DBUS_SESSION_BUS_ADDRESS \
		DISPLAY \
		ORBIT_SOCKETDIR \
		SESSION_MANAGER \
		XDG_SESSION_COOKIE \
		XAUTHORITY

	if ! use bindist; then
		einfo
		elog "You are enabling official branding. You may not redistribute this build"
		elog "to any users on your network or the internet. Doing so puts yourself into"
		elog "a legal problem with Mozilla Foundation"
		elog "You can disable it by emerging ${PN} _with_ the bindist USE-flag"
	fi

	if use pgo; then
		einfo
		ewarn "You will do a double build for profile guided optimization."
		ewarn "This will result in your build taking at least twice as long as before."
	fi
}

pkg_pretend() {
	# Ensure we have enough disk space to compile
	if use pgo || use debug || use test ; then
		CHECKREQS_DISK_BUILD="8G"
	else
		CHECKREQS_DISK_BUILD="4G"
	fi
	check-reqs_pkg_setup
}

src_unpack() {
	unpack ${A}

	# Unpack language packs
	mozlinguas_src_unpack
}

src_prepare() {
	# Apply our patches
	EPATCH_SUFFIX="patch" \
	EPATCH_FORCE="yes" \
	EPATCH_EXCLUDE="8011_bug1194520-freetype261_until_moz43.patch
			8010_bug114311-freetype26.patch" \
	epatch "${WORKDIR}/firefox"

	# Allow user to apply any additional patches without modifing ebuild
	epatch_user

	# Enable gnomebreakpad
	if use debug ; then
		sed -i -e "s:GNOME_DISABLE_CRASH_DIALOG=1:GNOME_DISABLE_CRASH_DIALOG=0:g" \
			"${S}"/build/unix/run-mozilla.sh || die "sed failed!"
	fi

	# Ensure that our plugins dir is enabled as default
	sed -i -e "s:/usr/lib/mozilla/plugins:/usr/lib/nsbrowser/plugins:" \
		"${S}"/xpcom/io/nsAppFileLocationProvider.cpp || die "sed failed to replace plugin path for 32bit!"
	sed -i -e "s:/usr/lib64/mozilla/plugins:/usr/lib64/nsbrowser/plugins:" \
		"${S}"/xpcom/io/nsAppFileLocationProvider.cpp || die "sed failed to replace plugin path for 64bit!"

	# Fix sandbox violations during make clean, bug 372817
	sed -e "s:\(/no-such-file\):${T}\1:g" \
		-i "${S}"/config/rules.mk \
		-i "${S}"/nsprpub/configure{.in,} \
		|| die

	# Don't exit with error when some libs are missing which we have in
	# system.
	sed '/^MOZ_PKG_FATAL_WARNINGS/s@= 1@= 0@' \
		-i "${S}"/browser/installer/Makefile.in || die

	# Don't error out when there's no files to be removed:
	sed 's@\(xargs rm\)$@\1 -f@' \
		-i "${S}"/toolkit/mozapps/installer/packager.mk || die

	eautoreconf

	# Must run autoconf in js/src
	cd "${S}"/js/src || die
	eautoconf

	# Need to update jemalloc's configure
	cd "${S}"/memory/jemalloc/src || die
	WANT_AUTOCONF= eautoconf
}

src_configure() {
	MOZILLA_FIVE_HOME="/usr/$(get_libdir)/${PN}"
	MEXTENSIONS="default"
	# Google API keys (see http://www.chromium.org/developers/how-tos/api-keys)
	# Note: These are for Gentoo Linux use ONLY. For your own distribution, please
	# get your own set of keys.
	_google_api_key=AIzaSyDEAOvatFo0eTgsV_ZlEzx0ObmepsMzfAc

	####################################
	#
	# mozconfig, CFLAGS and CXXFLAGS setup
	#
	####################################

	mozconfig_init
	mozconfig_config

	# It doesn't compile on alpha without this LDFLAGS
	use alpha && append-ldflags "-Wl,--no-relax"

	# Add full relro support for hardened
	use hardened && append-ldflags "-Wl,-z,relro,-z,now"

	use egl && mozconfig_annotate 'Enable EGL as GL provider' --with-gl-provider=EGL

	# Setup api key for location services
	echo -n "${_google_api_key}" > "${S}"/google-api-key
	mozconfig_annotate '' --with-google-api-keyfile="${S}/google-api-key"

	mozconfig_annotate '' --enable-extensions="${MEXTENSIONS}"
	mozconfig_annotate '' --disable-mailnews

	# Other ff-specific settings
	mozconfig_annotate '' --with-default-mozilla-five-home=${MOZILLA_FIVE_HOME}

	# Allow for a proper pgo build
	if use pgo; then
		echo "mk_add_options PROFILE_GEN_SCRIPT='\$(PYTHON) \$(OBJDIR)/_profile/pgo/profileserver.py'" >> "${S}"/.mozconfig
	fi

	echo "mk_add_options MOZ_OBJDIR=${BUILD_OBJ_DIR}" >> "${S}"/.mozconfig

	# Finalize and report settings
	mozconfig_final

	if [[ $(gcc-major-version) -lt 4 ]]; then
		append-cxxflags -fno-stack-protector
	fi

	# workaround for funky/broken upstream configure...
	emake -f client.mk configure
}

src_compile() {
	if use pgo; then
		addpredict /root
		addpredict /etc/gconf
		# Reset and cleanup environment variables used by GNOME/XDG
		gnome2_environment_reset

		# Firefox tries to use dri stuff when it's run, see bug 380283
		shopt -s nullglob
		cards=$(echo -n /dev/dri/card* | sed 's/ /:/g')
		if test -z "${cards}"; then
			cards=$(echo -n /dev/ati/card* /dev/nvidiactl* | sed 's/ /:/g')
			if test -n "${cards}"; then
				# Binary drivers seem to cause access violations anyway, so
				# let's use indirect rendering so that the device files aren't
				# touched at all. See bug 394715.
				export LIBGL_ALWAYS_INDIRECT=1
			fi
		fi
		shopt -u nullglob
		addpredict "${cards}"

		CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)" \
		MOZ_MAKE_FLAGS="${MAKEOPTS}" SHELL="${SHELL:-${EPREFIX%/}/bin/bash}" \
		Xemake -f client.mk profiledbuild || die "Xemake failed"
	else
		CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)" \
		MOZ_MAKE_FLAGS="${MAKEOPTS}" SHELL="${SHELL:-${EPREFIX%/}/bin/bash}" \
		emake -f client.mk realbuild
	fi

}

src_install() {
	MOZILLA_FIVE_HOME="/usr/$(get_libdir)/${PN}"
	DICTPATH="\"${EPREFIX}/usr/share/myspell\""

	cd "${BUILD_OBJ_DIR}" || die

	# Pax mark xpcshell for hardened support, only used for startupcache creation.
	pax-mark m "${BUILD_OBJ_DIR}"/dist/bin/xpcshell

	# Add our default prefs for firefox
	cp "${FILESDIR}"/gentoo-default-prefs.js-1 \
		"${BUILD_OBJ_DIR}/dist/bin/browser/defaults/preferences/all-gentoo.js" \
		|| die

	# Set default path to search for dictionaries.
	echo "pref(\"spellchecker.dictionary_path\", ${DICTPATH});" \
		>> "${BUILD_OBJ_DIR}/dist/bin/browser/defaults/preferences/all-gentoo.js" \
		|| die

	echo "pref(\"extensions.autoDisableScopes\", 3);" >> \
		"${BUILD_OBJ_DIR}/dist/bin/browser/defaults/preferences/all-gentoo.js" \
		|| die

	local plugin
	use gmp-autoupdate || for plugin in \
	gmp-gmpopenh264 ; do
		echo "pref(\"media.${plugin}.autoupdate\", false);" >> \
			"${BUILD_OBJ_DIR}/dist/bin/browser/defaults/preferences/all-gentoo.js" \
			|| die
	done

	MOZ_MAKE_FLAGS="${MAKEOPTS}" \
	emake DESTDIR="${D}" install

	# Install language packs
	mozlinguas_src_install

	local size sizes icon_path icon name
	if use bindist; then
		sizes="16 32 48"
		icon_path="${S}/browser/branding/aurora"
		# Firefox's new rapid release cycle means no more codenames
		# Let's just stick with this one...
		icon="aurora"
		name="Aurora"
	else
		sizes="16 22 24 32 256"
		icon_path="${S}/browser/branding/official"
		icon="${PN}"
		name="Mozilla Firefox"
	fi

	# Install icons and .desktop for menu entry
	for size in ${sizes}; do
		insinto "/usr/share/icons/hicolor/${size}x${size}/apps"
		newins "${icon_path}/default${size}.png" "${icon}.png"
	done
	# The 128x128 icon has a different name
	insinto "/usr/share/icons/hicolor/128x128/apps"
	newins "${icon_path}/mozicon128.png" "${icon}.png"
	# Install a 48x48 icon into /usr/share/pixmaps for legacy DEs
	newicon "${icon_path}/content/icon48.png" "${icon}.png"
	newmenu "${FILESDIR}/icon/${PN}.desktop" "${PN}.desktop"
	sed -i -e "s:@NAME@:${name}:" -e "s:@ICON@:${icon}:" \
		"${ED}/usr/share/applications/${PN}.desktop" || die

	# Add StartupNotify=true bug 237317
	if use startup-notification ; then
		echo "StartupNotify=true"\
			 >> "${ED}/usr/share/applications/${PN}.desktop" \
			|| die
	fi

	# Required in order to use plugins and even run firefox on hardened.
	if use jit; then
		pax-mark m "${ED}"${MOZILLA_FIVE_HOME}/{firefox,firefox-bin,plugin-container}
	else
		pax-mark m "${ED}"${MOZILLA_FIVE_HOME}/plugin-container
	fi

	if use minimal; then
		rm -r "${ED}"/usr/include "${ED}${MOZILLA_FIVE_HOME}"/{idl,include,lib,sdk} \
			|| die "Failed to remove sdk and headers"
	fi

	# very ugly hack to make firefox not sigbus on sparc
	# FIXME: is this still needed??
	use sparc && { sed -e 's/Firefox/FirefoxGentoo/g' \
					 -i "${ED}/${MOZILLA_FIVE_HOME}/application.ini" \
					|| die "sparc sed failed"; }

	# revdep-rebuild entry
	insinto /etc/revdep-rebuild
	echo "SEARCH_DIRS_MASK=${MOZILLA_FIVE_HOME}" >> ${T}/10firefox
	doins "${T}"/10${PN} || die
}

pkg_preinst() {
	gnome2_icon_savelist
}

pkg_postinst() {
	# Update mimedb for the new .desktop file
	fdo-mime_desktop_database_update
	gnome2_icon_cache_update
}

pkg_postrm() {
	gnome2_icon_cache_update
}

Re: [gentoo-user] Old Firefox ebuild?

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Friday, October 14, 2016 11:02:57 AM Ian Zimmerman wrote:
> Does anyone have a copy of the firefox 38.x ebuild around?
> 
> The latest update wiped it out, and now if I take the plunge to the
> current versions (i.e. at least 45.x) and I find then insufferable, I
> have no way back :-(
> 
> btw I do make regular backups, but not of anything under /usr.  This
> will teach me.

Portage tree is now under git, so you should be able to do a git clone of it, 
jump back to a point in history where the ebuild you like is still present, 
and grab it from there.

-- 
:wq

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Ian Zimmerman]

On 2016-10-14 19:16, Mick wrote:

> > Does anyone have a copy of the firefox 38.x ebuild around?
> 
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/

I think this will work for me, thank you!  However, I don't understand
why those versions precisely are there (which means they have been
checked into cvs, I guess) and not others?  For instance, the exact
version I'm running now, 38.8.0, is not there, and neither are the 45.x
and up which already invaded my portage tree.

> You could use 'emerge --buildpkg y' to build binary packages you can
> revert to, in case an update/upgrade breaks anything important.

Yes, and I should really learn more about binary packages in gentoo.
But still, it isn't much different from listing the files with equery f
and making a tarball.  Without a way to rebuild from source I feel as if
I were standing on 1 leg ...

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: Old Firefox ebuild?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Fri, 14 Oct 2016 12:15:54 -0700, Ian Zimmerman wrote:

> I think this will work for me, thank you!  However, I don't understand
> why those versions precisely are there (which means they have been
> checked into cvs, I guess) and not others?  For instance, the exact
> version I'm running now, 38.8.0, is not there, and neither are the 45.x
> and up which already invaded my portage tree.

The ebuilds used to install existing packages are all in /var/db/pkg.
 
> > You could use 'emerge --buildpkg y' to build binary packages you can
> > revert to, in case an update/upgrade breaks anything important.  
> 
> Yes, and I should really learn more about binary packages in gentoo.
> But still, it isn't much different from listing the files with equery f
> and making a tarball.

The packages portage creates also contain package metadata, as stored
in /var/db/pkg

> Without a way to rebuild from source I feel as if
> I were standing on 1 leg ...

If you have the disk space, adding buildpkg to FEATURES will ensure you
always have a crutch available...


-- 
Neil Bothwick

Am I ignorant or apathetic? I don't know and don't care!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Ian Zimmerman]

On 2016-10-14 18:29, Holger Hoffstätte wrote:

> On Fri, 14 Oct 2016 11:02:57 -0700, Ian Zimmerman wrote:
> 
> > Does anyone have a copy of the firefox 38.x ebuild around?
> 
> - go to https://gitweb.gentoo.org/repo/gentoo.git/log/www-client/firefox
> - find the revision before the one that deleted 38.8
> - select the "tree" view (above the path)
> - copy everything you need

Thanks!

> > btw I do make regular backups, but not of anything under /usr.  This
> 
> So in other words you don't make backups..

Do you really backup every file on your system, including those that you
can recreate by other means?

How long does an incremental backup take you?

What device do you use to store the backups?

Curious.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

[gentoo-user] Re: Old Firefox ebuild?

[Kai Krakow]

Am Fri, 14 Oct 2016 18:05:14 -0700
schrieb Ian Zimmerman <itz@primate.net>:

> On 2016-10-14 18:29, Holger Hoffstätte wrote:
> 
> > On Fri, 14 Oct 2016 11:02:57 -0700, Ian Zimmerman wrote:
> >   
> > > Does anyone have a copy of the firefox 38.x ebuild around?  
> > 
> > - go to
> > https://gitweb.gentoo.org/repo/gentoo.git/log/www-client/firefox
> > - find the revision before the one that deleted 38.8
> > - select the "tree" view (above the path)
> > - copy everything you need  
> 
> Thanks!
> 
> > > btw I do make regular backups, but not of anything under /usr.
> > > This  
> > 
> > So in other words you don't make backups..  
> 
> Do you really backup every file on your system, including those that
> you can recreate by other means?

Yes, with the exception of /usr/portage/{distfiles,packages}
and /{var/,}tmp.

> How long does an incremental backup take you?

15 Minutes.

> What device do you use to store the backups?

XFS partition with borgbackup. Retention stored on disk is 3 months
meanwhile (1 months of daily backups, 5 weekly backups, rest is
monthly). Borgbackup compressed 30 TB worth of backups into 1.8 TB.

It's an internal hard disk for performance reasons. I'm currently not
duplicating the backup disk to external storage, but if I would I'd
mirror the borgbackup archive with rsync.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Old Firefox ebuild?

[Kai Krakow]

Am Sat, 15 Oct 2016 05:27:16 +0200
schrieb Kai Krakow <hurikhan77@gmail.com>:

> XFS partition with borgbackup. Retention stored on disk is 3 months
> meanwhile (1 months of daily backups, 5 weekly backups, rest is
> monthly). Borgbackup compressed 30 TB worth of backups into 1.8 TB.

Sorry, wrong numbers: 1 month daily, 12 weekly backups, rest will be
monthly.

The backup source is my btrfs subvol 0. I can put the systemd units for
backup to github if you're interested.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Backup [Was: Old Firefox ebuild?]

[Ian Zimmerman]

On 2016-10-15 05:42, Kai Krakow wrote:

> The backup source is my btrfs subvol 0. I can put the systemd units
> for backup to github if you're interested.

I'm not a systemd fan, so they wouldn't help me, but thanks for
offering.

My priorities are different, and there are constraints resulting from my
priorities as well as others.

I am mostly worried about physical catastrophic damage (I live in
earthquake country) and losing my personal data, which could not be
recreated.  So it has to be offsite, and because it's personal data it
has to be encrypted.  And I cannot make the trip to where it's stored
every day.

Given the time (including the trip) it takes to restore, I don't see the
point of backing up static files which can be reinstalled from the
distribution.  Of course, I'm still learning gentoo and so it was easy
for me to make the mistake of forgetting that files under /usr/portage
aren't really in that catagory.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Backup [Was: Old Firefox ebuild?]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Fri, 14 Oct 2016 22:35:27 -0700, Ian Zimmerman wrote:

> Given the time (including the trip) it takes to restore, I don't see the
> point of backing up static files which can be reinstalled from the
> distribution.  Of course, I'm still learning gentoo and so it was easy
> for me to make the mistake of forgetting that files under /usr/portage
> aren't really in that catagory.

mv /usr/portage /var/
Change PORTDIR in make.conf to suit
Problem solved.


-- 
Neil Bothwick

If you use envelopes, why not encryption ?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Backup [Was: Old Firefox ebuild?]

[Rich Freeman]

On Sat, Oct 15, 2016 at 1:35 AM, Ian Zimmerman <itz@primate.net> wrote:
> On 2016-10-15 05:42, Kai Krakow wrote:
>
>> The backup source is my btrfs subvol 0. I can put the systemd units
>> for backup to github if you're interested.
>
> I'm not a systemd fan, so they wouldn't help me, but thanks for
> offering.

I'd be curious to see them; whether you use systemd or not units are
pretty trivial to read and make use of in scripts, cron entries, etc.

I just use snapper to manage snapshots if all I'm worried about is
casual deletion of files.  Since I don't fully trust btrfs I also keep
a full rsnapshot (basically an rsync wrapper) of my btrfs volumes on a
local ext4.

>
> My priorities are different, and there are constraints resulting from my
> priorities as well as others.
>
> I am mostly worried about physical catastrophic damage (I live in
> earthquake country) and losing my personal data, which could not be
> recreated.  So it has to be offsite, and because it's personal data it
> has to be encrypted.  And I cannot make the trip to where it's stored
> every day.
>
> Given the time (including the trip) it takes to restore, I don't see the
> point of backing up static files which can be reinstalled from the
> distribution.  Of course, I'm still learning gentoo and so it was easy
> for me to make the mistake of forgetting that files under /usr/portage
> aren't really in that catagory.
>

++

What I really consider my "backups" are stored encrypted on amazon s3
using duplicity (which I highly recommend for this purpose).
Basically it amounts to /etc, and /home, with a number of exclusions
(media and cache).  For media I care about like photos I include new
stuff in m duplicity backups, but as I accumulate reasonable chunks of
it I make a separate backup and store it offsite, and remove that
chunk from my duplicity backup.  This prevents the daily-updated
backup pool from getting insanely large, while still maintaining an
offsite copy (since these files don't change over time).

I'd never spend the money to be doing cloud backup of /usr (other than
/usr/local).  I have all my static configuration backed up, so I could
just restore that onto a stage 3 and run emerge -uDN world to get all
of that back.

If I did have an offsite server somewhere where storage costs weren't
a big deal then I'd probably be setting up replicas using
btrfs+zfs-send/receive.  You can do that at minimal cost with
incrementals, and I could probably do the first clone on the local
LAN.

-- 
Rich

[gentoo-user] Re: Backup [Was: Old Firefox ebuild?]

[Kai Krakow]

Am Sat, 15 Oct 2016 07:22:06 -0400
schrieb Rich Freeman <rich0@gentoo.org>:

> On Sat, Oct 15, 2016 at 1:35 AM, Ian Zimmerman <itz@primate.net>
> wrote:
> > On 2016-10-15 05:42, Kai Krakow wrote:
> >  
> >> The backup source is my btrfs subvol 0. I can put the systemd units
> >> for backup to github if you're interested.  
> >
> > I'm not a systemd fan, so they wouldn't help me, but thanks for
> > offering.  
> 
> I'd be curious to see them; whether you use systemd or not units are
> pretty trivial to read and make use of in scripts, cron entries, etc.

https://gist.github.com/kakra/7637555528a54a0c7aaca6f68338418c

My system automatically sleeps after 2 hours, so I'm using WakeSystem
to wake it up at night for backup.

/mnt/btrfs-pool is my pool. I also create the list of subvolumes on the
backup drive to more easily recreate all subvolumes before restoring the
backup.

My initial backup took around 24 hours, successive backups run 15
minutes. I'm using bcache for both my system storage and backup storage
to speed up the process but it includes Eric Wheelers ionice patches to
reduce SSD wear and improve overall performance:

"bcache: introduce per-process ioprio-based bypass/writeback hints"

Also, you can change the environment settings to support encrypted
backups. I'm not using them as I only use trusted storage and don't
want to bother keeping the crypt key in a safe place.

If I reintroduce duplicating to a remote location, I'd simply rsync the
backup archive to a remote location with an additional ExecStartPost
line. My diff is around 500 MB to 2 GB per day. (my external USB disk
died, I'll get a NAS sometime later instead)

Actually, I'm doing this with a remote location which is rsync'ed to my
local backup every night.

> I just use snapper to manage snapshots if all I'm worried about is
> casual deletion of files.  Since I don't fully trust btrfs I also keep
> a full rsnapshot (basically an rsync wrapper) of my btrfs volumes on a
> local ext4.

That is why I chose borgbackup. But I prefer XFS as a more reliable and
faster file system for backup storage. Also, I used the systemd
automounter so it won't be mounted all the time but just on demand.

> > My priorities are different, and there are constraints resulting
> > from my priorities as well as others.
> >
> > I am mostly worried about physical catastrophic damage (I live in
> > earthquake country) and losing my personal data, which could not be
> > recreated.  So it has to be offsite, and because it's personal data
> > it has to be encrypted.  And I cannot make the trip to where it's
> > stored every day.
> >
> > Given the time (including the trip) it takes to restore, I don't
> > see the point of backing up static files which can be reinstalled
> > from the distribution.  Of course, I'm still learning gentoo and so
> > it was easy for me to make the mistake of forgetting that files
> > under /usr/portage aren't really in that catagory.
> >  
> 
> ++
> 
> What I really consider my "backups" are stored encrypted on amazon s3
> using duplicity (which I highly recommend for this purpose).

Borgbackup supports strong encryption. I'm pretty sure you could even
manage storing to amazon s3 directly.

> Basically it amounts to /etc, and /home, with a number of exclusions
> (media and cache).  For media I care about like photos I include new
> stuff in m duplicity backups, but as I accumulate reasonable chunks of
> it I make a separate backup and store it offsite, and remove that
> chunk from my duplicity backup.  This prevents the daily-updated
> backup pool from getting insanely large, while still maintaining an
> offsite copy (since these files don't change over time).

Borgbackup supports cache tags to exclude cache directories. I placed
some of them manually in e.g. $HOME/.cache. Borgbackup deduplication
makes full backup snapshots insanely small: 30 TB of backups are stored
in 1.8 TB for me. So it also detects file moves which rsync doesn't
(and deduplicity probably also doesn't).

> I'd never spend the money to be doing cloud backup of /usr (other than
> /usr/local).  I have all my static configuration backed up, so I could
> just restore that onto a stage 3 and run emerge -uDN world to get all
> of that back.

I figured that reinstallation plus restoring is much more time
consuming than just simply put it back. Reinstalling Gentoo from
scratch will take me 3-4 days until everything is back in place
normally. Restoring my data from borgbackup takes around 24 hours last
time I had to do it.

Restoring onto a stage3 may also introduce orphan files because you are
overwriting what the package manager thinks is installed. And by the
way: How big could /usr be usually (excluding portage)? Maybe a few
tiny gigabytes. It's a tiny fragment of my complete backup.

Instead, I'm using a tiny USB stick with an sdcard and a rescue system
that I keep updated from time to time (simply by booting a
systemd-nspawn container from it). That USB stick is just as small as
the Logitech nano receivers (the sdcard is inserted within the
connector), so I keep it plugged in all the time. This installation
also includes a script to recreate my btrfs including it's subvolumes,
and then restore the backup upon that. It also works as a backup for
my /boot partition as it essentially has a copy of that (to be
bootable).

> If I did have an offsite server somewhere where storage costs weren't
> a big deal then I'd probably be setting up replicas using
> btrfs+zfs-send/receive.  You can do that at minimal cost with
> incrementals, and I could probably do the first clone on the local
> LAN.

I'd take a look at borgbackups remote capabilities also. I'm backing up
some remote machines by simply using the prebuilt single binary from
the website (so versions easily stay in sync). Borgbackup uses ssh
tunnels for transferring data and a remote cache for speeding up delta
transfers. It's much much faster than rsync. I never tried btrfs
send/receive and it's probably still less space efficient than
borgbackup.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Backup [Was: Old Firefox ebuild?]

[Ian Zimmerman]

On 2016-10-15 09:14, Neil Bothwick wrote:

> mv /usr/portage /var/
> Change PORTDIR in make.conf to suit
> Problem solved.

but ... quoting man make.conf:

    PORTDIR = [path]

              Defines the location of main repository. This variable is
              deprecated in favor of settings in repos.conf. If you
              change this, you must update your
              /etc/portage/make.profile symlink accordingly.  Defaults
              to /usr/portage.

So, 2 warnings ... looks dangerous after all.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: Backup [Was: Old Firefox ebuild?]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Sat, 15 Oct 2016 12:22:49 -0700, Ian Zimmerman wrote:

> > mv /usr/portage /var/
> > Change PORTDIR in make.conf to suit
> > Problem solved.  
> 
> but ... quoting man make.conf:
> 
>     PORTDIR = [path]
> 
>               Defines the location of main repository. This variable is
>               deprecated in favor of settings in repos.conf. If you
>               change this, you must update your
>               /etc/portage/make.profile symlink accordingly.  Defaults
>               to /usr/portage.
> 
> So, 2 warnings ... looks dangerous after all.

Not really warnings, just advice. Yes, you should really use the new way
of setting it. Then run eselect profile to reset your profile symlink.

All you are doing is moving the portage tree to a filesystem that you
backup and telling portage abut it. There's nothing dangerous about it
and you won't stop your system working even if you get it wrong. I do
that on all my Gentoo boxes as I don't want dynamic data in /usr. 


-- 
Neil Bothwick

... Taglines: and How They Affect Women. Next On Oprah.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Old Firefox ebuild?

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On 161014-21:39+0300, Alexey Mishustin wrote:
> Hello.
> 
> 2016-10-14 21:02 GMT+03:00 Ian Zimmerman <itz@primate.net>:
> > Does anyone have a copy of the firefox 38.x ebuild around?
> 
> Attached.
> 
> > The latest update wiped it out, and now if I take the plunge to the
> > current versions (i.e. at least 45.x) and I find then insufferable,
> 
> Agree!
>
I may agree too, if some facts fall into place. Read on.

I was wondering how safe is running Firefox 38.x at this day and age?

If you look up:
http://arstechnica.com/security/2016/09/mozilla-checks-if-firefox-is-affected-by-same-malware-vulnerability-as-tor/
( continued and improved from:
https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at-mass-scale-bd68e9eb1e95#.ctpp9u5fl )
and especially the Jacob Appelbaum's:
https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
So if you recall (some of the readers must have read those) the issues
there, and how badly Firefox was exposed and pretty often, then my query
is how do you assess how secure Firefox 38.x that you install might be?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-user] Old Firefox ebuild?

[Alexey Mishustin]

2016-10-16 2:41 GMT+03:00 Miroslav Rovis <miro.rovis@croatiafidelis.hr>:
> On 161014-21:39+0300, Alexey Mishustin wrote:
>> Hello.
>>
>> 2016-10-14 21:02 GMT+03:00 Ian Zimmerman <itz@primate.net>:
>> > Does anyone have a copy of the firefox 38.x ebuild around?
>>
>> Attached.
>>
>> > The latest update wiped it out, and now if I take the plunge to the
>> > current versions (i.e. at least 45.x) and I find then insufferable,
>>
>> Agree!
>>
> I may agree too, if some facts fall into place. Read on.
>
> I was wondering how safe is running Firefox 38.x at this day and age?
>
> If you look up:
> http://arstechnica.com/security/2016/09/mozilla-checks-if-firefox-is-affected-by-same-malware-vulnerability-as-tor/
> ( continued and improved from:
> https://hackernoon.com/tor-browser-exposed-anti-privacy-implantation-at-mass-scale-bd68e9eb1e95#.ctpp9u5fl )
> and especially the Jacob Appelbaum's:
> https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
> So if you recall (some of the readers must have read those) the issues
> there, and how badly Firefox was exposed and pretty often, then my query
> is how do you assess how secure Firefox 38.x that you install might be?
>
> Regards!

Yeah, it's an usual dilemma: old version is vulnerable, new version sucks.

From my point of view, if there's a MITM, then Firefox is not the only problem.

Besides ruining the cookies management (should one install an addon
now? like Cookies Manager+?), new versions of Firefox succeeded to
hang all the OS, when I was working with Google maps (never been with
older versions).

-- 
Regards,
Alex

[gentoo-user] Re: Old Firefox ebuild?

[Martin Vaeth]

Ian Zimmerman <itz@primate.net> wrote:
> Does anyone have a copy of the firefox 38.x ebuild around?

As others already noted: It is not a good idea to use
an ebuild which was removed for security reasons.

My recommendation: Use palemoon (from the palemoon overlay)

Re: [gentoo-user] Re: Old Firefox ebuild?

[Alexey Mishustin]

2016-10-16 13:34 GMT+03:00 Martin Vaeth <martin@mvath.de>:
> Ian Zimmerman <itz@primate.net> wrote:
>> Does anyone have a copy of the firefox 38.x ebuild around?
>
> As others already noted: It is not a good idea to use
> an ebuild which was removed for security reasons.
>
> My recommendation: Use palemoon (from the palemoon overlay)

I see, this product is enough old. Why isn't it in the main tree?

-- 
Regards,
Alex

Re: [gentoo-user] Re: Old Firefox ebuild?

[waltdnes]

On Sun, Oct 16, 2016 at 10:34:12AM +0000, Martin Vaeth wrote
> Ian Zimmerman <itz@primate.net> wrote:
> > Does anyone have a copy of the firefox 38.x ebuild around?
> 
> As others already noted: It is not a good idea to use
> an ebuild which was removed for security reasons.
> 
> My recommendation: Use palemoon (from the palemoon overlay)

  I build my own.  It can be installed entirely, including browser and
libraries in /usr/local/palemoon or /opt/palemoon, or even in
$HOME/palemoon.  "Updates" consist of...

rm -rf <location>/palemoon
tar -C <location> -xvjf <tarball_name>.bz2

# If <location> is /usr/local or /opt
ln -sf <location>/palemoon/palemoon /usr/bin/palemoon

# If <location> is in your home directory
ln -sf <location>/palemoon/palemoon $HOME/bin/palemoon


  The Pale Moon for linux support sub-forum is at...
https://forum.palemoon.org/viewforum.php?f=37

  The Tycho beta forum (upcoming version 27) is at
https://forum.palemoon.org/viewforum.php?f=56

  Ask on the linux sub-forum forum if you need help building it.  One
advantage of "roll-your-own" is being able to delete/disable stuff that
is standard on the mainstream build.  There are a whole slew of
"--enable" and "--disable" options.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-user] Re: Old Firefox ebuild?

[Martin Vaeth]

waltdnes@waltdnes.org <waltdnes@waltdnes.org> wrote:
>
>   I build my own.

I would never recommend installing something without
the package manager's sandbox. And be it just because of
possible bugs in the makefile which might cause files
(unintentionally) ending on the wrong place.

> There are a whole slew of "--enable" and "--disable" options.

Yet another reason to use an ebuild!  You set the USE-flags once,
and for updates you will have the same things enabled/disabled.
Fortunately, the palemoon ebuild is well done and passes most
configure options as USE-flags, but if it is not enough for you,
you can of course still use EXTRA_ECONF or roll your own ebuild.
In any case this is better than installing "behind the package
manager's back".

Re: [gentoo-user] Re: Old Firefox ebuild?

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On 161016-10:34+0000, Martin Vaeth wrote:
> Ian Zimmerman <itz@primate.net> wrote:
> > Does anyone have a copy of the firefox 38.x ebuild around?
> My recommendation: Use palemoon (from the palemoon overlay)

Martin, I learned of Palemoon only from you, back in the Gentoo Forums.
And I tend to believe (haven't installed it yet) that Palemoon is a sane
project.

However, there is one thing missing in Palemoon, for me, and I was
curious if you could tell me about it.

Here my non-replied-to topic at the Palemoon Forum, in the Technical
Chat:

Tracking protection and NSS SSL secrets logging (two security
questions)?
https://forum.palemoon.org/viewtopic.php?f=26&t=12544

I'm very happy to be able to read the network wherever I go. It's
astounding experience...

Thinking about browsers, the last thing I would go for is, of course,
anyhing Google anyways, but it's only Google's Chrom{e,ium}, IE and
Firefox that do the SSL secrets logging (note: I don't know if Opera
does it).

Do you know if Palemoon can do SSL secrets logging? Anyone else knows?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Ian Zimmerman]

On 2016-10-16 10:34, Martin Vaeth wrote:

> Ian Zimmerman <itz@primate.net> wrote:
> > Does anyone have a copy of the firefox 38.x ebuild around?
> 
> As others already noted: It is not a good idea to use
> an ebuild which was removed for security reasons.
> 
> My recommendation: Use palemoon (from the palemoon overlay)

A sensible recommendation, thanks.

Can palemoon work with recent firefox extensions, though?  I use only
very few, but without them the cure will be worse than the disease:

Adblock Plus
Request Policy Continued

and, just slightly less important:

Proxy Switcher

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: Old Firefox ebuild?

[Wolfgang Mueller]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Sun, Oct 16, 2016 at 17:04:29 -0700, Ian Zimmerman wrote:
> Can palemoon work with recent firefox extensions, though?  I use only
> very few, but without them the cure will be worse than the disease:
> 
> Adblock Plus
> Request Policy Continued
> 
> and, just slightly less important:
> 
> Proxy Switcher

Usually, recent Firefox extensions still work with Pale Moon.

Pale Moon maintains their own direct fork of Adblock Plus (called
Adblock Latitude[1]), so that will definitely work.

I just installed Request Policy Continued and it seems to work fine.
Proxy Switcher could not be installed (claims the Firefox version is too
old), but it may still work if you manually edit the extension manifest.
I do that myself with vimperator (although current versions have stopped
working altogether).

You might find an alternative for Proxy Switcher here[2], plus more
about extension incompatibility here[3].

[1] - https://addons.palemoon.org/extensions/privacy-and-security/adblock-latitude/
[2] - https://addons.palemoon.org/extensions/all-extensions/
[3] - https://addons.palemoon.org/resources/incompatible/

-- 
Wolfgang Mueller / vehk.de / GPG 0xc543cfce9465f573

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Ian Zimmerman]

On 2016-10-16 10:34, Martin Vaeth wrote:

> My recommendation: Use palemoon (from the palemoon overlay)

Oh man!  THANK YOU!  pale moon is the best thing in my digital life since
gentoo :-)  I can only wonder why it is not more widely known or used by
hackers?

There seems to be a little glitch in the packaging:  when I emerge
pale moon first (before unmerging firefox and company), pale moon ends up
linked against shared libraries from the nss and nspr packages (in
/usr/lib64), instead of the bundled ones in /usr/lib64/palemoon.

Unmerging firefox first and then --depcleaning works around it.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: Old Firefox ebuild?

[Andy Mender]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Thanks for the Palemoon recommendation. I emerged it yesterday and I am
already very happy with it. I too will probably not use Firefox anymore.

~Andy

On 18 Oct 2016 21:59, "Ian Zimmerman" <itz@primate.net> wrote:

On 2016-10-16 10:34, Martin Vaeth wrote:

> My recommendation: Use palemoon (from the palemoon overlay)

Oh man!  THANK YOU!  pale moon is the best thing in my digital life since
gentoo :-)  I can only wonder why it is not more widely known or used by
hackers?

There seems to be a little glitch in the packaging:  when I emerge
pale moon first (before unmerging firefox and company), pale moon ends up
linked against shared libraries from the nss and nspr packages (in
/usr/lib64), instead of the bundled ones in /usr/lib64/palemoon.

Unmerging firefox first and then --depcleaning works around it.

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

[-- Attachment #2: Type: text/html, Size: 1564 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Martin Vaeth]

Andy Mender <andymenderunix@gmail.com> wrote:
> linked against shared libraries from the nss and nspr packages (in
> /usr/lib64), instead of the bundled ones in /usr/lib64/palemoon.

If you know this from an ldd output only, this is misleading:
It's shared libraries, i.e. palemoon will actually use those
corresponding to the LDPATH when the binary is started;
I suppose LDPATH is set appropriately from some starting wrapper.

Re: [gentoo-user] Re: Old Firefox ebuild?

[Andy Mender]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On 21 October 2016 at 14:10, Martin Vaeth <martin@mvath.de> wrote:

> Andy Mender <andymenderunix@gmail.com> wrote:
> > linked against shared libraries from the nss and nspr packages (in
> > /usr/lib64), instead of the bundled ones in /usr/lib64/palemoon.
>
> If you know this from an ldd output only, this is misleading:
> It's shared libraries, i.e. palemoon will actually use those
> corresponding to the LDPATH when the binary is started;
> I suppose LDPATH is set appropriately from some starting wrapper


I think you've accidentally taken someone else's words as mine when
replying.
I never wrote anything about shared libraries.

Best regards,
Andy Mender

[-- Attachment #2: Type: text/html, Size: 1135 bytes --]

[gentoo-user] Re: Old Firefox ebuild?

[Ian Zimmerman]

On 2016-10-21 15:09, Andy Mender wrote:

> On 21 October 2016 at 14:10, Martin Vaeth <martin@mvath.de> wrote:
> 
> > Andy Mender <andymenderunix@gmail.com> wrote:
> > > linked against shared libraries from the nss and nspr packages (in
> > > /usr/lib64), instead of the bundled ones in /usr/lib64/palemoon.
> >
> > If you know this from an ldd output only, this is misleading:
> > It's shared libraries, i.e. palemoon will actually use those
> > corresponding to the LDPATH when the binary is started;
> > I suppose LDPATH is set appropriately from some starting wrapper
> 
> 
> I think you've accidentally taken someone else's words as mine when
> replying.
> I never wrote anything about shared libraries.

I wrote that.

Indeed I'd used ldd, but only as a corroborating step; the primary
problem was that portage refused to remove the nspr and nss libraries
(ie. "preserved" them), thinking (rightly or wrongly I don't know) that
pale moon was dependent upon them.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

[gentoo-user] transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Ian Zimmerman]

On 2016-10-15 22:03, Neil Bothwick wrote:

> >     PORTDIR = [path]
> > 
> >               Defines the location of main repository. This variable is
> >               deprecated in favor of settings in repos.conf. If you
> >               change this, you must update your
> >               /etc/portage/make.profile symlink accordingly.  Defaults
> >               to /usr/portage.
> > 
> > So, 2 warnings ... looks dangerous after all.
> 
> Not really warnings, just advice. Yes, you should really use the new way
> of setting it. Then run eselect profile to reset your profile symlink.
> 
> All you are doing is moving the portage tree to a filesystem that you
> backup and telling portage abut it. There's nothing dangerous about it
> and you won't stop your system working even if you get it wrong. I do
> that on all my Gentoo boxes as I don't want dynamic data in /usr. 

So I have done this, but now every portage operation gives me:

!!! Section 'x-portage' in repos.conf has location attribute
set to nonexistent directory: '/usr/portage'

There is no [x-portage] section in /etc/portage/repos.conf/gentoo.conf,
the file I modified to point to the new location.  My modification was:

< location = /usr/portage
> location = /var/lib/portage/ports

and this was in the [gentoo] section.

Apart from that file, there is also
/usr/share/portage/config/repos.conf, but I thought this was just a
template for the one in /etc.  The original contents were the same,
ie. location = /usr/portage, and _no_ [x-portage] section.

I am confused, just as I feared would happen :-(

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

On Wed, 26 Oct 2016 11:40:59 -0700, Ian Zimmerman wrote:

> > All you are doing is moving the portage tree to a filesystem that you
> > backup and telling portage abut it. There's nothing dangerous about it
> > and you won't stop your system working even if you get it wrong. I do
> > that on all my Gentoo boxes as I don't want dynamic data in /usr.   
> 
> So I have done this, but now every portage operation gives me:
> 
> !!! Section 'x-portage' in repos.conf has location attribute
> set to nonexistent directory: '/usr/portage'
> 
> There is no [x-portage] section in /etc/portage/repos.conf/gentoo.conf,
> the file I modified to point to the new location.  My modification was:
> 
> < location = /usr/portage
> > location = /var/lib/portage/ports  
> 
> and this was in the [gentoo] section.
> 
> Apart from that file, there is also
> /usr/share/portage/config/repos.conf, but I thought this was just a
> template for the one in /etc.  The original contents were the same,
> ie. location = /usr/portage, and _no_ [x-portage] section.
> 
> I am confused, just as I feared would happen :-(

I never saw anything like this when making the change. Try

$ grep -r x-portage /etc/portage /var/lib/portage /usr/share/portage

to see if you can find any mention of x-portage. Also try

$ grep -r usr/portage /etc/portage /var/lib/portage /usr/share/portage

but that will get some hits from /usr/share/portage.
AIUI /usr/share/portage/repos.conf sets the defaults, which are
overridden by the file in /etc. That's how it happens here.


-- 
Neil Bothwick

Drop your carrier .. we have you surrounded

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Bill Kenworthy]

On 27/10/16 02:40, Ian Zimmerman wrote:
> On 2016-10-15 22:03, Neil Bothwick wrote:
> 
>>>     PORTDIR = [path]
>>>
>>>               Defines the location of main repository. This variable is
>>>               deprecated in favor of settings in repos.conf. If you
>>>               change this, you must update your
>>>               /etc/portage/make.profile symlink accordingly.  Defaults
>>>               to /usr/portage.
>>>
>>> So, 2 warnings ... looks dangerous after all.
>>
>> Not really warnings, just advice. Yes, you should really use the new way
>> of setting it. Then run eselect profile to reset your profile symlink.
>>
>> All you are doing is moving the portage tree to a filesystem that you
>> backup and telling portage abut it. There's nothing dangerous about it
>> and you won't stop your system working even if you get it wrong. I do
>> that on all my Gentoo boxes as I don't want dynamic data in /usr. 
> 
> So I have done this, but now every portage operation gives me:
> 
> !!! Section 'x-portage' in repos.conf has location attribute
> set to nonexistent directory: '/usr/portage'
> 
> There is no [x-portage] section in /etc/portage/repos.conf/gentoo.conf,
> the file I modified to point to the new location.  My modification was:
> 
> < location = /usr/portage
>> location = /var/lib/portage/ports
> 
> and this was in the [gentoo] section.
> 
> Apart from that file, there is also
> /usr/share/portage/config/repos.conf, but I thought this was just a
> template for the one in /etc.  The original contents were the same,
> ie. location = /usr/portage, and _no_ [x-portage] section.
> 
> I am confused, just as I feared would happen :-(
> 

No its not a template - portage reads it and throws a wobbly.  I just
copy /etc/portage/repos.d/gentoo.conf over it (or whatever you are using
on your system).  I think its supposed to be a default fallback, and it
all workd regardless even with the error.

BillK

[gentoo-user] Re: transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Ian Zimmerman]

On 2016-10-26 21:39, Neil Bothwick wrote:

> $ grep -r x-portage /etc/portage /var/lib/portage /usr/share/portage

Nothing.

> AIUI /usr/share/portage/repos.conf sets the defaults, which are
> overridden by the file in /etc. That's how it happens here.

Even making /usr/share/portage/repos.conf a symlink to
/etc/portage/repos.conf/gentoo.conf, and adding an extra x-portage
section to the latter with a duplicated "location = " setting changed
nothing.  This looks like a bug.  Any portage devs here?

OTOH, just making /usr/portage itself a symlink to the new location
seems to work fine; portage even resolves the symlink in all its
messages.  --sync works too.

When you moved your tree, have you in fact removed /usr/portage, or have
you left it in place but empty?

Do you use any overlays? (I do.)

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

Re: [gentoo-user] Re: transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Wed, 26 Oct 2016 18:16:47 -0700, Ian Zimmerman wrote:

> When you moved your tree, have you in fact removed /usr/portage, or have
> you left it in place but empty?

I removed it entirely.
 
> Do you use any overlays? (I do.)

Yes I do, but they aren't under $PORTDIR so they wouldn't be affected.


-- 
Neil Bothwick

There are two hard things in computer science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-user] Re: transplant /usr/portage [Was: Backup] [Was: Old Firefox ebuild?]

[Fernando Rodriguez]

On 10/26/2016 09:16 PM, Ian Zimmerman wrote:
> On 2016-10-26 21:39, Neil Bothwick wrote:
> 
>> $ grep -r x-portage /etc/portage /var/lib/portage /usr/share/portage
> 
> Nothing.
> 
>> AIUI /usr/share/portage/repos.conf sets the defaults, which are
>> overridden by the file in /etc. That's how it happens here.
> 
> Even making /usr/share/portage/repos.conf a symlink to
> /etc/portage/repos.conf/gentoo.conf, and adding an extra x-portage
> section to the latter with a duplicated "location = " setting changed
> nothing.  This looks like a bug.  Any portage devs here?
> 
> OTOH, just making /usr/portage itself a symlink to the new location
> seems to work fine; portage even resolves the symlink in all its
> messages.  --sync works too.

Do you have a crossdev overlay?
If so it's ebuilds are symlinks to the main portage tree so you need
to fix them manually or rebuild all your crossdev packages.

> 
> When you moved your tree, have you in fact removed /usr/portage, or have
> you left it in place but empty?
> 
> Do you use any overlays? (I do.)
> 


-- 

Fernando Rodriguez