Hi,
I wonder why we're having a GIT binary package installed on the TracSVN VM
which causes broken dependencies.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Thu, Oct 26, 2017 at 11:13:04AM +0000, Martin Spott wrote:
Hi,
I wonder why we're having a GIT binary package installed on the TracSVN VM
which causes broken dependencies.
My fault, git-1.8 was needed for Gitea-1.2:
https://github.com/go-gitea/git/pull/48
Rather than building it manually I downloaded a .deb package from
a newer Debian distribution. Feel free to revert to the official
packages if you think it'll be safer (I migth not be able for the next month):
it was "git" and "bash-completions" that I installed that way.
--strk;
Sandro Santilli wrote:
On Thu, Oct 26, 2017 at 11:13:04AM +0000, Martin Spott wrote:
I wonder why we're having a GIT binary package installed on the TracSVN VM
which causes broken dependencies.My fault, git-1.8 was needed for Gitea-1.2:
https://github.com/go-gitea/git/pull/48Rather than building it manually I downloaded a .deb package from
a newer Debian distribution. Feel free to revert to the official
packages if you think it'll be safer
I didn't mean to revert the GIT package (because then I'm responsble for
fixing the Gitea stuff which I know very little about 
and moreover I
don't generally object against installing packages from compatible distros.
But if we do so, then I'd prefer not to forcibly break dependencies - as I
wrote earlier - but instead properly install the required packages as well.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Wed, Nov 01, 2017 at 01:24:26PM +0000, Martin Spott wrote:
Sandro Santilli wrote:
> On Thu, Oct 26, 2017 at 11:13:04AM +0000, Martin Spott wrote:>> I wonder why we're having a GIT binary package installed on the TracSVN VM
>> which causes broken dependencies.
>
> My fault, git-1.8 was needed for Gitea-1.2:
> https://github.com/go-gitea/git/pull/48
>
> Rather than building it manually I downloaded a .deb package from
> a newer Debian distribution. Feel free to revert to the official
> packages if you think it'll be saferI didn't mean to revert the GIT package (because then I'm responsble for
fixing the Gitea stuff which I know very little about
I didn't upgrade Gitea anymore so the old packages would not break
anything.
and moreover I
don't generally object against installing packages from compatible distros.
But if we do so, then I'd prefer not to forcibly break dependencies - as I
wrote earlier - but instead properly install the required packages as well.
I'm a big lame when it comes to do this part of the work.
Maybe "aptitude" would be smart enough to do it on its own, what do
you think ? Isn't it fun to be stuck on a Debian old-old-old-stable ? 
PS: your name often comes out as "the one and only capable of
upgrading distributions on osuosl VMs"... is that true ?
--strk;
Sandro Santilli wrote:
I didn't upgrade Gitea anymore so the old packages would not break
anything.
Ok, I've reverted the "git" package to the one shipped with the distro.
PS: your name often comes out as "the one and only capable of
upgrading distributions on osuosl VMs"... is that true ?
I don't know, but maybe I'm the only one who tried
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Hi Martin,
On Sun, 05. Nov 2017 at 20:42:08 +0000, Martin Spott wrote:
> PS: your name often comes out as "the one and only capable of
> upgrading distributions on osuosl VMs"... is that true ?I don't know, but maybe I'm the only one who tried
because you have console access?
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
Jürgen E. Fischer wrote:
On Sun, 05. Nov 2017 at 20:42:08 +0000, Martin Spott wrote:
> PS: your name often comes out as "the one and only capable of
> upgrading distributions on osuosl VMs"... is that true ?I don't know, but maybe I'm the only one who tried
because you have console access?
No, not at all, I used a regular root shell to run these dist-upgrades.
Every primary admin could do so as well.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Hi Martin,
On Sun, 05. Nov 2017 at 21:20:35 +0000, Martin Spott wrote:
> because you have console access?
No, not at all, I used a regular root shell to run these dist-upgrades.
Every primary admin could do so as well.
You don't have console access?
If the dist-upgrade includes a kernel upgrade and a reboot I'd be uncomfortable
w/o console access in case the boot fails...
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
On Sun, Nov 05, 2017 at 11:19:45PM +0100, Jürgen E. Fischer wrote:
Hi Martin,
On Sun, 05. Nov 2017 at 21:20:35 +0000, Martin Spott wrote:
> > because you have console access?> No, not at all, I used a regular root shell to run these dist-upgrades.
> Every primary admin could do so as well.You don't have console access?
If the dist-upgrade includes a kernel upgrade and a reboot I'd be uncomfortable
w/o console access in case the boot fails...
Indeed, but I think you can synchronize with people in #osuosl
to request their intervention in case of drama. They are friendly !
--strk;
On 11/05/2017 02:42 PM, Sandro Santilli wrote:
On Sun, Nov 05, 2017 at 11:19:45PM +0100, Jürgen E. Fischer wrote:
Hi Martin,
On Sun, 05. Nov 2017 at 21:20:35 +0000, Martin Spott wrote:
because you have console access?
No, not at all, I used a regular root shell to run these dist-upgrades.
Every primary admin could do so as well.You don't have console access?
If the dist-upgrade includes a kernel upgrade and a reboot I'd be uncomfortable
w/o console access in case the boot fails...Indeed, but I think you can synchronize with people in #osuosl
to request their intervention in case of drama. They are friendly !--strk;
+1 coordinate with #osuosl
There is however a non standard part of the upgrade process that Martin
figured out at some point, related to the boot partition. I think more
people are capable of it if we understood what needs to be done.
Thanks,
Alex