Under Ubuntu Linux, what is the recommended technique to upgrade Geany as newer versions are released?
All I've been able to find online is info on how to do an initial install, and some upgrade suggestions that didn't work.
I've put a ton of time into customizing my install, and I for sure don't want to screw up and have an "upgrade trick" wipe all that out.
I am only in interested in installing stable code, not bleeding edge development versions.
Thanks in advance!
Mike
REF: Ubuntu 20.04, Geany 1.36
Hi Mike,
On Mon, 9 Nov 2020 at 10:45, Mike McCauley mlmccauley50@gmail.com wrote:
Under Ubuntu Linux, what is the recommended technique to upgrade Geany as newer versions are released?
All I've been able to find online is info on how to do an initial install, and some upgrade suggestions that didn't work.
Thats because there is no such thing as an "upgrade" of Geany, a new install replaces the old install (unless specially built to not do that, which (AFAIK) no distros do).
I've put a ton of time into customizing my install, and I for sure don't want to screw up and have an "upgrade trick" wipe all that out.
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
I am only in interested in installing stable code, not bleeding edge development versions.
Distro versions are usually releases so thats as stable as it gets. That doesn't mean that there are no issues with a release, but by the time it has percolated through most distro systems it should be fairly stable so long as its the latest micro point release for the platform (1.37.0 for Linux, 1.37.1 for Windows as this is written).
If you want to upgrade bypassing the distro system, you can build yourself with a different prefix so it doesn't overwrite an existing version, thats how developers maintain multiple versions.
Cheers Lex
Thanks in advance!
Mike
REF: Ubuntu 20.04, Geany 1.36
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
I think what the OP was asking was something like this:
- Ubuntu 20.04
- Geany 1.36 from the Ubuntu distro, installed with apt install geany
- Now 1.37.1 is available. It will be a long time before this hits the Ubuntu repo. What is the best way to install it now, keeping my settings?
I'd be interested in the answer to this question myself. The reply from Lex didn't really answer that question, IMHO.
- Woody
On Sun, Nov 8, 2020 at 7:21 PM Lex Trotman elextr@gmail.com wrote:
Hi Mike,
On Mon, 9 Nov 2020 at 10:45, Mike McCauley mlmccauley50@gmail.com wrote:
Under Ubuntu Linux, what is the recommended technique to upgrade Geany as newer versions are released?
All I've been able to find online is info on how to do an initial install, and some upgrade suggestions that didn't work.
Thats because there is no such thing as an "upgrade" of Geany, a new install replaces the old install (unless specially built to not do that, which (AFAIK) no distros do).
I've put a ton of time into customizing my install, and I for sure don't want to screw up and have an "upgrade trick" wipe all that out.
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
I am only in interested in installing stable code, not bleeding edge development versions.
Distro versions are usually releases so thats as stable as it gets. That doesn't mean that there are no issues with a release, but by the time it has percolated through most distro systems it should be fairly stable so long as its the latest micro point release for the platform (1.37.0 for Linux, 1.37.1 for Windows as this is written).
If you want to upgrade bypassing the distro system, you can build yourself with a different prefix so it doesn't overwrite an existing version, thats how developers maintain multiple versions.
Cheers Lex
Thanks in advance!
Mike
REF: Ubuntu 20.04, Geany 1.36
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Mon, 9 Nov 2020 at 14:09, Woodrow Stool woodrow.stool@gmail.com wrote:
I think what the OP was asking was something like this:
Ubuntu 20.04
Geany 1.36 from the Ubuntu distro, installed with apt install geany
Now 1.37.1 is available. It will be a long time before this hits the Ubuntu repo. What is the best way to install it now, keeping my settings?
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
Ok, maybe saying "upgrade" might be confusing after having said there is no such thing, read that as "install". But otherwise its as stated, installing won't touch your local config, just go ahead and install it.
If you want a version newer than the distro has, you need to build it yourself, see the HACKING file, and also since the processes and tools are standard for open source C software, there should be help on the web for details. Since distros vary slightly you may need to find where your distro put the old Geany to set the prefix. Or you may decide to put it somewhere totally different, just don't forget to set your PATH.
Installing _will_ overwrite the system config files which are the defaults. As I said, if you have modified system files then you have done a "bad thing" (TM) because they will get overwritten by the next install, so I hope nobody has done that. Just in case somebody has, you need to copy the changed settings into a local config first or they will be overwritten, how and what files depends on what you changed.
I'd be interested in the answer to this question myself. The reply from Lex didn't really answer that question, IMHO.
As I said, its standard processes and tools for building open source software and the HACKING file provides more information.
Cheers Lex
- Woody
On Sun, Nov 8, 2020 at 7:21 PM Lex Trotman elextr@gmail.com wrote:
Hi Mike,
On Mon, 9 Nov 2020 at 10:45, Mike McCauley mlmccauley50@gmail.com wrote:
Under Ubuntu Linux, what is the recommended technique to upgrade Geany as newer versions are released?
All I've been able to find online is info on how to do an initial install, and some upgrade suggestions that didn't work.
Thats because there is no such thing as an "upgrade" of Geany, a new install replaces the old install (unless specially built to not do that, which (AFAIK) no distros do).
I've put a ton of time into customizing my install, and I for sure don't want to screw up and have an "upgrade trick" wipe all that out.
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
I am only in interested in installing stable code, not bleeding edge development versions.
Distro versions are usually releases so thats as stable as it gets. That doesn't mean that there are no issues with a release, but by the time it has percolated through most distro systems it should be fairly stable so long as its the latest micro point release for the platform (1.37.0 for Linux, 1.37.1 for Windows as this is written).
If you want to upgrade bypassing the distro system, you can build yourself with a different prefix so it doesn't overwrite an existing version, thats how developers maintain multiple versions.
Cheers Lex
Thanks in advance!
Mike
REF: Ubuntu 20.04, Geany 1.36
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Thanks for the clarification Lex. Actually this ends up being my bad - I recalled there was a .deb file on the Geany site, but checking now I see it is source for Linux and installers for MacOS and Windows. There was a PPA somewhere that had .deb versions of the latest releases, I'll have to check my notes and recall where that was.
So let me ask you a hypothetical question - assuming a .deb distribution comes to light, what do you expect would happen if I sudo dpkg -i geany-something.deb with 1.36 already installed? Do I need to delete 1.36 first? Same goes with building from source - delete the old version first?
Thanks again for all your help, and thanks very much to all those contributors that made Geany happen.
- Woody
On Sun, Nov 8, 2020 at 8:47 PM Lex Trotman elextr@gmail.com wrote:
On Mon, 9 Nov 2020 at 14:09, Woodrow Stool woodrow.stool@gmail.com wrote:
I think what the OP was asking was something like this:
Ubuntu 20.04
Geany 1.36 from the Ubuntu distro, installed with apt install geany
Now 1.37.1 is available. It will be a long time before this hits the
Ubuntu repo. What is the best way to install it now, keeping my settings?
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
Ok, maybe saying "upgrade" might be confusing after having said there is no such thing, read that as "install". But otherwise its as stated, installing won't touch your local config, just go ahead and install it.
If you want a version newer than the distro has, you need to build it yourself, see the HACKING file, and also since the processes and tools are standard for open source C software, there should be help on the web for details. Since distros vary slightly you may need to find where your distro put the old Geany to set the prefix. Or you may decide to put it somewhere totally different, just don't forget to set your PATH.
Installing _will_ overwrite the system config files which are the defaults. As I said, if you have modified system files then you have done a "bad thing" (TM) because they will get overwritten by the next install, so I hope nobody has done that. Just in case somebody has, you need to copy the changed settings into a local config first or they will be overwritten, how and what files depends on what you changed.
I'd be interested in the answer to this question myself. The reply from
Lex didn't really answer that question, IMHO.
As I said, its standard processes and tools for building open source software and the HACKING file provides more information.
Cheers Lex
- Woody
On Sun, Nov 8, 2020 at 7:21 PM Lex Trotman elextr@gmail.com wrote:
Hi Mike,
On Mon, 9 Nov 2020 at 10:45, Mike McCauley mlmccauley50@gmail.com
wrote:
Under Ubuntu Linux, what is the recommended technique to upgrade Geany as newer versions are released?
All I've been able to find online is info on how to do an initial install, and some upgrade suggestions that didn't work.
Thats because there is no such thing as an "upgrade" of Geany, a new install replaces the old install (unless specially built to not do that, which (AFAIK) no distros do).
I've put a ton of time into customizing my install, and I for sure
don't
want to screw up and have an "upgrade trick" wipe all that out.
An upgrade won't touch any customising you did in your local configure directories, but if you are one of those people who customised the system files then yes it will overwrite them. In that case you need to copy the changes to a non-system configuration first and don't touch system files again.
I am only in interested in installing stable code, not bleeding edge development versions.
Distro versions are usually releases so thats as stable as it gets. That doesn't mean that there are no issues with a release, but by the time it has percolated through most distro systems it should be fairly stable so long as its the latest micro point release for the platform (1.37.0 for Linux, 1.37.1 for Windows as this is written).
If you want to upgrade bypassing the distro system, you can build yourself with a different prefix so it doesn't overwrite an existing version, thats how developers maintain multiple versions.
Cheers Lex
Thanks in advance!
Mike
REF: Ubuntu 20.04, Geany 1.36
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Mon, 9 Nov 2020 at 14:54, Woodrow Stool woodrow.stool@gmail.com wrote:
Thanks for the clarification Lex. Actually this ends up being my bad - I recalled there was a .deb file on the Geany site, but checking now I see it is source for Linux and installers for MacOS and Windows. There was a PPA somewhere that had .deb versions of the latest releases, I'll have to check my notes and recall where that was.
Its not been updated for 1.37 yet https://launchpad.net/~geany-dev/+archive/ubuntu/ppa note despite the implications of the name, its also maintained by an external packager (the same one as debian), not the project devs.
So let me ask you a hypothetical question - assuming a .deb distribution comes to light, what do you expect would happen if I sudo dpkg -i geany-something.deb with 1.36 already installed? Do I need to delete 1.36 first?
Remember the distro specific package files are made by people outside the project who are experts in the intricacies of doing that, but its my amateur understanding that apt and debs take care of all that if its installing a new version over an old version.
Same goes with building from source - delete the old version first?
Won't hurt to uninstall (not simply delete stuff, especially in system directories), but probably not needed going from 1.36 to 1.37. Note the only difference between 1.37 and 1.37.1 is only relevant to windows, not linux, so don't sweat the x.x.1.
Cheers Lex
Thanks again for all your help, and thanks very much to all those contributors that made Geany happen.
- Woody
I have successfully installed 1.36 on Debian Buster, and similar procedures might be relevant for Ubuntu. In Buster, 1.33 is in the repos, but I was alarmed to find that debugger-plugin had been dropped.
After a few false starts, I ended up with the following to build 1.36(GTK-2): 1. Save all my system and local config 2. Purge existing geany. 3. ~$ ./configure 4. ~$ make 5. ~$ sudo -s make install
The Geany documentation for step 5 says 6. ~$ sudo make install On Debian that failed because of path problems locating ldconfig.
After installing the plugins, debugger did not immediately show up in the plugin list in spite of restart. But it did the next day - may have required a reboot.
Anyway, the debugger is working fine and an improvement on what we had before!
Hope this is of some use.
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 09/11/2020 05:08, Lex Trotman wrote:
On Mon, 9 Nov 2020 at 14:54, Woodrow Stool woodrow.stool@gmail.com wrote:
Thanks for the clarification Lex. Actually this ends up being my bad - I recalled there was a .deb file on the Geany site, but checking now I see it is source for Linux and installers for MacOS and Windows. There was a PPA somewhere that had .deb versions of the latest releases, I'll have to check my notes and recall where that was.
Its not been updated for 1.37 yet https://launchpad.net/~geany-dev/+archive/ubuntu/ppa note despite the implications of the name, its also maintained by an external packager (the same one as debian), not the project devs.
So let me ask you a hypothetical question - assuming a .deb distribution comes to light, what do you expect would happen if I sudo dpkg -i geany-something.deb with 1.36 already installed? Do I need to delete 1.36 first?
Remember the distro specific package files are made by people outside the project who are experts in the intricacies of doing that, but its my amateur understanding that apt and debs take care of all that if its installing a new version over an old version.
Same goes with building from source - delete the old version first?
Won't hurt to uninstall (not simply delete stuff, especially in system directories), but probably not needed going from 1.36 to 1.37. Note the only difference between 1.37 and 1.37.1 is only relevant to windows, not linux, so don't sweat the x.x.1.
Cheers Lex
Thanks again for all your help, and thanks very much to all those contributors that made Geany happen.
- Woody
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
As far as I know, nothing special. But in Debian Buster: --------------------------------------------------------- ~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz ---------------------------------------------------------
The error message I got was: --------------------------------------------------------- /home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127 --------------------------------------------------------
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote:
- ~$ sudo make install
On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote:
- ~$ sudo make install
On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
I do not think I have modified $PATH from system settings: -------------------------------------------------------- ~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games --------------------------------------------------------
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 00:24, Lex Trotman wrote:
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote:
- ~$ sudo make install
On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Wed, 11 Nov 2020 at 21:31, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
I do not think I have modified $PATH from system settings:
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Your "whereis" puts ldconfig in /sbin/ but thats not in your PATH, thats the problem. I don't use debian, so I don't know why your PATH is so limited. By default my Mint has:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Cheers Lex
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 00:24, Lex Trotman wrote:
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote:
- ~$ sudo make install
On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
The best I can do is to report that several Debian users have come across this kind of problem. For example, someone asked: "Why is it so bad to have /usr/sbin in PATH?" The answer given in the forums was "Because sbin contains programs and scripts only executable by root".
Debian used to support gksu to get root access from a virtual terminal, but that is dropped in Buster.
Anyway, sudo -s is useful to know!
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 11:38, Lex Trotman wrote:
On Wed, 11 Nov 2020 at 21:31, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
I do not think I have modified $PATH from system settings:
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Your "whereis" puts ldconfig in /sbin/ but thats not in your PATH, thats the problem. I don't use debian, so I don't know why your PATH is so limited. By default my Mint has:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Cheers Lex
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 00:24, Lex Trotman wrote:
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote:
- ~$ sudo make install
On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Le 11/11/2020 à 22:21, Geoff Kaniuk a écrit :
The best I can do is to report that several Debian users have come across this kind of problem. For example, someone asked: "Why is it so bad to have /usr/sbin in PATH?" The answer given in the forums was "Because sbin contains programs and scripts only executable by root".
This makes sense, but what's weird is that you don't have it when under root with sudo:
$ sudo env | grep PATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Basically your sudo probably doesn't reset enough of the environment, which makes it harder to use and less secure (keeping PATH for example is dangerous as it might trick you into running a program you didn't expect, if someone hijacked your PATH).
I don't think I altered my sudo configuration, so I'm not sure why you do have what you have (but I'm under Debian, not Ubuntu), but e.g. my /etc/sudoers contain this (among other things):
Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Anyway, you're not alone with such a configuration that doesn't reset most of the environment (you can find similar problems on the Web), and that causes issues. I'm still not sure where that comes from, as I'm almost positive I never touched this myself (and I checked on another machine as well) so that it'd be Debian's default. I'm not sure what Ubuntu does, but it kind of sounds odd to me they would not have env_reset be the default, or include sbin the sudo's path.
I'd recommend you to triple check whether your sudo config is as you want it, and if you don't know, make sure it's Ubuntu's default. Do *NOT* trust the bits I pasted, as it's a highly sensitive configuration, only use sources you trust and know what they are doing (e.g. the manual, Debian/Ubuntu's maintainer, and… that's about what I'd trust). If you're using all the expected defaults from Ubuntu, then I'd check if they document how to do run admin commands like that.
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path; it's a hack for Ubuntu's broken ldconfig configuration anyway, so it should not trigger anywhere else and we can thus use Ubuntu's ldconfig path. I'd rather avoid that if possible so the hack is less specific and could work on other problematic setups, but well, yout can't always get what you want.
Regards, Colomban
Debian used to support gksu to get root access from a virtual terminal, but that is dropped in Buster.
Anyway, sudo -s is useful to know!
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 11:38, Lex Trotman wrote:
On Wed, 11 Nov 2020 at 21:31, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
I do not think I have modified $PATH from system settings:
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Your "whereis" puts ldconfig in /sbin/ but thats not in your PATH, thats the problem. I don't use debian, so I don't know why your PATH is so limited. By default my Mint has:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Cheers Lex
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 00:24, Lex Trotman wrote:
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote:
On 09.11.20 14:17, Geoff Kaniuk wrote: > 6. ~$ sudo make install > On Debian that failed because of path problems locating ldconfig.
This is unexpected for me. Running Debian for >10 years now and never seen that need before. Do you have any special sh-configuration?
.f _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Sun, 15 Nov 2020 at 00:21, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 11/11/2020 à 22:21, Geoff Kaniuk a écrit :
The best I can do is to report that several Debian users have come across this kind of problem. For example, someone asked: "Why is it so bad to have /usr/sbin in PATH?" The answer given in the forums was "Because sbin contains programs and scripts only executable by root".
This makes sense, but what's weird is that you don't have it when under root with sudo:
$ sudo env | grep PATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Basically your sudo probably doesn't reset enough of the environment, which makes it harder to use and less secure (keeping PATH for example is dangerous as it might trick you into running a program you didn't expect, if someone hijacked your PATH).
I don't think I altered my sudo configuration, so I'm not sure why you do have what you have (but I'm under Debian, not Ubuntu), but e.g. my /etc/sudoers contain this (among other things):
Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Anyway, you're not alone with such a configuration that doesn't reset most of the environment (you can find similar problems on the Web), and that causes issues. I'm still not sure where that comes from, as I'm almost positive I never touched this myself (and I checked on another machine as well) so that it'd be Debian's default. I'm not sure what Ubuntu does, but it kind of sounds odd to me they would not have env_reset be the default, or include sbin the sudo's path.
I'd recommend you to triple check whether your sudo config is as you want it, and if you don't know, make sure it's Ubuntu's default. Do *NOT* trust the bits I pasted, as it's a highly sensitive configuration, only use sources you trust and know what they are doing (e.g. the manual, Debian/Ubuntu's maintainer, and… that's about what I'd trust). If you're using all the expected defaults from Ubuntu, then I'd check if they document how to do run admin commands like that.
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path;
Can we? AFAICT all ldconfig invocations are generated by autofools, and seem to be of the form "finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'" so it doesn't expect sbin in PATH anyway.
Cheers Lex
it's a hack for Ubuntu's broken ldconfig configuration anyway, so it should not trigger anywhere else and we can thus use Ubuntu's ldconfig path. I'd rather avoid that if possible so the hack is less specific and could work on other problematic setups, but well, yout can't always get what you want.
Regards, Colomban
Debian used to support gksu to get root access from a virtual terminal, but that is dropped in Buster.
Anyway, sudo -s is useful to know!
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 11:38, Lex Trotman wrote:
On Wed, 11 Nov 2020 at 21:31, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
I do not think I have modified $PATH from system settings:
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Your "whereis" puts ldconfig in /sbin/ but thats not in your PATH, thats the problem. I don't use debian, so I don't know why your PATH is so limited. By default my Mint has:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Cheers Lex
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 11/11/2020 00:24, Lex Trotman wrote:
Whats your PATH?
On Wed, 11 Nov 2020 at 09:07, Geoff Kaniuk geoff@kaniuk.co.uk wrote:
As far as I know, nothing special. But in Debian Buster:
~$ whereis ldconfig ldconfig: /sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz
The error message I got was:
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
There is some more information in the Debian forums: http://forums.debian.net/viewtopic.php?f=17&t=147179
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 10/11/2020 19:50, Frank Lanitz wrote: > On 09.11.20 14:17, Geoff Kaniuk wrote: >> 6. ~$ sudo make install >> On Debian that failed because of path problems locating ldconfig. > > This is unexpected for me. Running Debian for >10 years now and never > seen that need before. Do you have any special sh-configuration? > > .f > _______________________________________________ > Users mailing list > Users@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Le 14/11/2020 à 23:16, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 00:21, Colomban Wendling […]
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path;
Can we? AFAICT all ldconfig invocations are generated by autofools, and seem to be of the form "finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'" so it doesn't expect sbin in PATH anyway.
Not that one:
Le 11/11/2020 à 00:06, Geoff Kaniuk a écrit :
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
This is our Ubuntu hack `fix-ubuntu-libdir` that you can find in src/Makefile.am.
On Sun, 15 Nov 2020 at 20:11, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 14/11/2020 à 23:16, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 00:21, Colomban Wendling […]
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path;
Can we? AFAICT all ldconfig invocations are generated by autofools, and seem to be of the form "finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'" so it doesn't expect sbin in PATH anyway.
Not that one:
Le 11/11/2020 à 00:06, Geoff Kaniuk a écrit :
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
This is our Ubuntu hack `fix-ubuntu-libdir` that you can find in src/Makefile.am.
Ok, so why not do exactly as autotools does, adding /sbin to path?
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
Le 15/11/2020 à 11:28, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 20:11, Colomban Wendling
This is our Ubuntu hack `fix-ubuntu-libdir` that you can find in src/Makefile.am.
Ok, so why not do exactly as autotools does, adding /sbin to path?
Sounds like a good idea if libtool is doing this already. I made a tentative PR: https://github.com/geany/geany/pull/2661 Geoff, could you test this and see if it does fix the issue? thanks!
Regards, Colomban
My plan was to wait until 1.38 is released and then re-install Geany with GTK3. It would be a big distraction for me as I have a good working Geany at the moment and am busy with projects.
For the record I have double checked my paths and they are the debian defaults: --------------------------------------------------------------- ~$ sudo -i ~# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games ---------------------------------------------------------------
I have only a very superficial knowledge of autotools, but have located all the instances of ldconfig in Geany 1.36 source. I see how the paths for ldconfig are set up in config.status, libtool, configure, libtol.m4. The ubuntu fix is only in Makefile.am, Makefile, Makefile.in. Is it possible for some distro to put ldconfig in some location not involving sbin?
I was wondering if one could discover where ldconfig was located by invoking 'whereis' in the autotools, and then prefixing the path to ldconfig. Maybe this is what Lex meant by hard coding? But in this way one is not making any assumptions about the location of ldconfig.
I really do appreciate the work you are doing here - thanks!
Geoff
33 Ashbury Close, Cambridge CB1 3RW 01223 710582
On 15/11/2020 23:00, Colomban Wendling via Users wrote:
Le 15/11/2020 à 11:28, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 20:11, Colomban Wendling
This is our Ubuntu hack `fix-ubuntu-libdir` that you can find in src/Makefile.am.
Ok, so why not do exactly as autotools does, adding /sbin to path?
Sounds like a good idea if libtool is doing this already. I made a tentative PR: https://github.com/geany/geany/pull/2661 Geoff, could you test this and see if it does fix the issue? thanks!
Regards, Colomban _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
I like the freudian slip! autofools. 🤓
On Sun, Nov 15, 2020 at 2:11 AM Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Le 14/11/2020 à 23:16, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 00:21, Colomban Wendling […]
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path;
Can we? AFAICT all ldconfig invocations are generated by autofools, and seem to be of the form "finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'" so it doesn't expect sbin in PATH anyway.
Not that one:
Le 11/11/2020 à 00:06, Geoff Kaniuk a écrit :
/home# make install ... /bin/bash: line 3: ldconfig: command not found make[4]: *** [Makefile:1660: fix-ubuntu-libdir] Error 127
This is our Ubuntu hack `fix-ubuntu-libdir` that you can find in src/Makefile.am. _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
I wasn't convinced that it was a slip. ;)
John Y.
On Sun, Nov 15, 2020 at 3:10 PM David Topham dtopham@gmail.com wrote:
I like the freudian slip! autofools. 🤓
On Sun, Nov 15, 2020 at 2:11 AM Colomban Wendling < lists.ban@herbesfolles.org> wrote:
Le 14/11/2020 à 23:16, Lex Trotman a écrit :
On Sun, 15 Nov 2020 at 00:21, Colomban Wendling […]
All this said, for the problem at hand if it's indeed problematic with stock Ubuntu setups, maybe we could go the sad way and hardcode ldconfig's path;
Can we? AFAICT all ldconfig invocations are generated by autofools, and seem to be of the form "finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'" so it doesn't expect sbin in PATH anyway.