Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
Le 22/07/2018 à 00:10, Mike Gilbert a écrit : On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie wrote: Hello, Gentoo. Right at the moment, I feel a lot of sympathy with Alan Grimes, and need a lot of restraint in avoiding the use of swear words in describing some Gentoo developer. ... nullmailer installs a file /usr/sbin/sendmail. This masks out the correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I installed by hand, not using emerge) because /usr/sbin is before /usr/bin in $PATH. ... But what's the proper method to tell my gentoo system that I don't want crud like nullmailer installed? How can I guard myself against such presumptiousness on the part of the Gentoo devs in the future? You must have installed a package that depends on virtual/mta, presumably because it needs to send emails. Had you installed qmail using portage, the virtual/mta dep would have been satisfied by it, and nullmailer would not have been installed in the first place. However, you didn't do that, and so portage had no idea qmail was installed. A possible workaround would be to add mail-mta/netqmail to package.provided on your system. However, there's still no guarantee that your custom-built qmail software will work with other packages provided by Gentoo. Regarding your accusations: Gentoo developers cannot anticipate every possible thing you might do on your system, especially when you start installing custom programs in paths that are traditionally managed by our package manager. Using portage you can customize your system extensively, without needing to custom build your own software. If that's not good enough for you, go build a Linux from Scratch system and enjoy the lack of any package management or support whatsoever. I was also surprised to see the installation of a mta in an emerge update, so I masked virtual/mta to see why this dependency was pulled. It turns out that app-crypt/gnupg depends on virtual/mta since version 2.2.6. Now the question is, why does gpg need a mta?
Re: [gentoo-user] Dhclient and buggy ISP
On Fri, Jul 20, 2018 at 11:41:22PM +0100 , Mick wrote: > On Friday, 20 July 2018 08:58:53 BST Matti Nykyri wrote: > > Hey > > > > I have a following with Telia ISP and their dhcp-server... I'm using > > dhclient to get dynamic IP from ISP and also to update DDNS. When > I am not familiar with dhclient, although whenever I used it in various > distros it just worked. Have you tried using dhcpcd instead? > -- > Regards, > Mick I second Mick's suggestion. I use dhcpcd (with ddclient for dynamic dns) on my home server, which seems to work well enough. -- Roger Welsh fpr: 2FCB 9E31 EA77 CDEC A3AE 5DD7 D54C C777 553A 180D signature.asc Description: PGP signature
[gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.
On 2018-07-21 23:04, Grant Edwards wrote: > Manually installing things in /usr/bin or /usr/sbin will often cause > problems because Portage assumes that it controls those directories. > > So don't do that: you should manually install things in /usr/local. > > Or, install qmail using portage, so that the system knows you have an > MTA. If you don't like the default qmail ebuild for some reason, you > can use your own. > > Or, tell Portage you have an MTA by adding an appropriate line to > /etc/portage/profie/package.provided. See portage(5). > > Or, don't use Gentoo if you don't want to do things the way Gentoo > does things. I agree than one should not normally install hand-compiled programs in the normal directories controlled by portage. I can see how the case of MTA can tempt someone into violating that rule, though: unlike most of all other cases where a program is called by other programs, the path to /usr/sbin/sendmail is usually hardcoded, and there is no well known environment variable either (like EDITOR or PAGER). mutt has a runtime configuration option for the MTA but that's unusual. In fact, I myself am guilty of the corresponding sin on my Debian server: I want to run the latest version of my pet MTA, exim, and with the features I choose, so hand compiling is the only way. And this week it backfired on me too: I carelessly installed some package that depended on a MTA - and boom, /usr/sbin/sendmail, which had been a symlink to /opt/exim/bin/exim, was overwritten by something like nullmailer. The /usr/sbin/sendmail convention is one of the parts of Unix that, honestly, sucks. With repeated and prolonged exposure one can get irritated enough to turn Poettering :-P On Gentoo the best way is to make your own package from your favorite MTA _and_ your own virtual/mta, and make both available in a local repo. Recently I discovered dma[1] which IMHO is the _best_ lightweight MTA for client machines, so now I have a Gentoo package for it. [1] https://github.com/corecode/dma/ -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
[gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.
On 2018-07-21, Alan Mackenzie wrote: > What has happened is that somebody decided to add virtual/mta-1 > surreptitiously to the default software set in Gentoo. This > installs something called nullmailer, which I don't need, didn't ask > for, and fouls up my mail transmission. > > nullmailer installs a file /usr/sbin/sendmail. This masks out the > correct /usr/bin/sendmail (which is a symbolic link to s/qmail, > which I installed by hand, not using emerge) because /usr/sbin is > before /usr/bin in $PATH. Manually installing things in /usr/bin or /usr/sbin will often cause problems because Portage assumes that it controls those directories. So don't do that: you should manually install things in /usr/local. Or, install qmail using portage, so that the system knows you have an MTA. If you don't like the default qmail ebuild for some reason, you can use your own. Or, tell Portage you have an MTA by adding an appropriate line to /etc/portage/profie/package.provided. See portage(5). Or, don't use Gentoo if you don't want to do things the way Gentoo does things. > Is this worth a bug report? No. It's not a bug its a user error. There are a half-dozen different ways to do the right thing, but you chose the wrong thing. -- Grant
Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On 21.07.2018 23:03, Alan Mackenzie wrote: > But what's the proper method to tell my gentoo system that I don't > want crud like nullmailer installed? Install an MTA using emerge, or let Gentoo know that you have installed qmail manually. When you work around portage, you are responsible to keep Gentoo happy in terms of dependencies. Gentoo did not "foul up", you just tried to be a tricksy fellow, unaware of the consequences. ;-) -Ralph
Re: [gentoo-user] Heads up: Gentoo fouls up mail transport agent.
On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie wrote: > Hello, Gentoo. > > Right at the moment, I feel a lot of sympathy with Alan Grimes, and need > a lot of restraint in avoiding the use of swear words in describing some > Gentoo developer. > > ... > > nullmailer installs a file /usr/sbin/sendmail. This masks out the > correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I > installed by hand, not using emerge) because /usr/sbin is before > /usr/bin in $PATH. > > ... > > But what's the proper method to tell my gentoo system that I don't want > crud like nullmailer installed? How can I guard myself against such > presumptiousness on the part of the Gentoo devs in the future? You must have installed a package that depends on virtual/mta, presumably because it needs to send emails. Had you installed qmail using portage, the virtual/mta dep would have been satisfied by it, and nullmailer would not have been installed in the first place. However, you didn't do that, and so portage had no idea qmail was installed. A possible workaround would be to add mail-mta/netqmail to package.provided on your system. However, there's still no guarantee that your custom-built qmail software will work with other packages provided by Gentoo. Regarding your accusations: Gentoo developers cannot anticipate every possible thing you might do on your system, especially when you start installing custom programs in paths that are traditionally managed by our package manager. Using portage you can customize your system extensively, without needing to custom build your own software. If that's not good enough for you, go build a Linux from Scratch system and enjoy the lack of any package management or support whatsoever.
[gentoo-user] Heads up: Gentoo fouls up mail transport agent.
Hello, Gentoo. Right at the moment, I feel a lot of sympathy with Alan Grimes, and need a lot of restraint in avoiding the use of swear words in describing some Gentoo developer. What has happened is that somebody decided to add virtual/mta-1 surreptitiously to the default software set in Gentoo. This installs something called nullmailer, which I don't need, didn't ask for, and fouls up my mail transmission. nullmailer installs a file /usr/sbin/sendmail. This masks out the correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I installed by hand, not using emerge) because /usr/sbin is before /usr/bin in $PATH. It appears that nullmailer was installed on 2018-06-15. Up until recently, things seemed to work; mutt seems to bind itself to the sendmail it finds at (mutt's) installation time. However, mutt-1.10.1 was released in the last couple of days. It bound itself to the imposter sendmail. So, when I sent mail from mutt, nullmailer simply swallowed it up, without forwarding it to its destination (nullmailer not being configured). There were no signs of this lack of action anywhere to be seen. SO, WATCH OUT, FELLOW GENTOOERS! The temporary solution was to rename /usr/sbin/sendmail, and to reinstall mutt. That's how I'm able to send this mail. This has cost me ~two hours of time, so far. But what's the proper method to tell my gentoo system that I don't want crud like nullmailer installed? How can I guard myself against such presumptiousness on the part of the Gentoo devs in the future? Is this worth a bug report? -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] [OT] MBR + GPT + GRUB
On Saturday, 21 July 2018 19:47:25 BST Jack wrote: > On 2018.07.21 13:46, Mick wrote: > > Hi All, > > > > A slightly off-topic question arising from a different distro, which > > may > > replicate itself on Gentoo. > > > > I installed Mint-Linux, in a VM. The host PC MoBo has a legacy BIOS > > system. > > I used a GPT scheme to create partitions on the virtual disk. The > > first 1M on > > the virtual disk was left empty by gdisk. I thought GRUB can use > > this for its > > core image. Note, I did not create a partition in this 1MB empty > > space at the > > start of the disk. > > > > While running the Mint Installer I got a warning from its partition > > manager > > telling me I had not specified a BIOS_grub partition and the > > installation may > > fail. I ignored the warning and continued with the installation, > > which > > completed successfully. > > > > A few weeks later I ran an update which among other packages updated > > grub2- > > common. An ncurses menu popped up warning me: > > > > "The GRUB boot loaders was previously installed to a disk that is no > > longer > > present, or whose unique identifier has changed for some reason". > > > > It offered to install in /dev/vda, /dev/vda1, or /dev/vda2. I > > selected /dev/ > > vda which represents the virtual disk. It failed to install in > > /dev/vda > > because the device did not contain a BIOS_grub partition. > > > > I tried 'grub-install --force' and --boot-directory options, but in > > all cases > > it failed to install. At the end I had to create a new 1M partition > > with > > gdisk and set its type to ef02 (BIOS boot partition), before grub > > would > > install its core image successfully. > > > > > > QUESTIONS: > > > > Why/how the initial installation succeeded without an ef02 partition, > > but a > > grub package update would not proceed without it? Where did the Mint > > installer store the grub core image to be able to continue with the > > installation? > > Are you sure this wasn't fallout from the recent grub problems in the > Mint ISO? (https://blog.linuxmint.com/?p=3620) I thought I got the > link to that on this list, but I can't find the relevant message, so > I'm not sure where I saw it. However, it seems like the issue was that > installing Mint messed up Grub and left the PC unbootable. > > Jack Thanks Jack, I posted this blog entry on another thread, but the GRUB problem described there breaks EFI installations when the live session is connected to the Internet. Mine installed fine at the time. So, I don't think the blog entry is related to my case above. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] MBR + GPT + GRUB
On 2018.07.21 13:46, Mick wrote: Hi All, A slightly off-topic question arising from a different distro, which may replicate itself on Gentoo. I installed Mint-Linux, in a VM. The host PC MoBo has a legacy BIOS system. I used a GPT scheme to create partitions on the virtual disk. The first 1M on the virtual disk was left empty by gdisk. I thought GRUB can use this for its core image. Note, I did not create a partition in this 1MB empty space at the start of the disk. While running the Mint Installer I got a warning from its partition manager telling me I had not specified a BIOS_grub partition and the installation may fail. I ignored the warning and continued with the installation, which completed successfully. A few weeks later I ran an update which among other packages updated grub2- common. An ncurses menu popped up warning me: "The GRUB boot loaders was previously installed to a disk that is no longer present, or whose unique identifier has changed for some reason". It offered to install in /dev/vda, /dev/vda1, or /dev/vda2. I selected /dev/ vda which represents the virtual disk. It failed to install in /dev/vda because the device did not contain a BIOS_grub partition. I tried 'grub-install --force' and --boot-directory options, but in all cases it failed to install. At the end I had to create a new 1M partition with gdisk and set its type to ef02 (BIOS boot partition), before grub would install its core image successfully. QUESTIONS: Why/how the initial installation succeeded without an ef02 partition, but a grub package update would not proceed without it? Where did the Mint installer store the grub core image to be able to continue with the installation? Are you sure this wasn't fallout from the recent grub problems in the Mint ISO? (https://blog.linuxmint.com/?p=3620) I thought I got the link to that on this list, but I can't find the relevant message, so I'm not sure where I saw it. However, it seems like the issue was that installing Mint messed up Grub and left the PC unbootable. Jack
[gentoo-user] [OT] MBR + GPT + GRUB
Hi All, A slightly off-topic question arising from a different distro, which may replicate itself on Gentoo. I installed Mint-Linux, in a VM. The host PC MoBo has a legacy BIOS system. I used a GPT scheme to create partitions on the virtual disk. The first 1M on the virtual disk was left empty by gdisk. I thought GRUB can use this for its core image. Note, I did not create a partition in this 1MB empty space at the start of the disk. While running the Mint Installer I got a warning from its partition manager telling me I had not specified a BIOS_grub partition and the installation may fail. I ignored the warning and continued with the installation, which completed successfully. A few weeks later I ran an update which among other packages updated grub2- common. An ncurses menu popped up warning me: "The GRUB boot loaders was previously installed to a disk that is no longer present, or whose unique identifier has changed for some reason". It offered to install in /dev/vda, /dev/vda1, or /dev/vda2. I selected /dev/ vda which represents the virtual disk. It failed to install in /dev/vda because the device did not contain a BIOS_grub partition. I tried 'grub-install --force' and --boot-directory options, but in all cases it failed to install. At the end I had to create a new 1M partition with gdisk and set its type to ef02 (BIOS boot partition), before grub would install its core image successfully. QUESTIONS: Why/how the initial installation succeeded without an ef02 partition, but a grub package update would not proceed without it? Where did the Mint installer store the grub core image to be able to continue with the installation? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] oracle-jdk-bin-11
Hi, is someone aware of the existence of an ebuild for Java 11 e.g. somewhere in the overlays? Or has someone already crafted one and is willing to share it? Cheers, Jörg
