Re: [gentoo-user] segfault in gedit / glib
> > The segfault message would exist in the dmesg/journalctl. Please open a > user shell in Gnome and type "gedit ", substituting a text file for > . Press enter. Does this segfault and if so is there anything else > printed? > > The journalctl message is; Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip 7f7c2550ba74 sp 7fff66834850 error 4 in libglib-2.0.so.0.5200.3[7f7c254c+114000] the gedit message is; Segmentation fault (core dumped)
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On Friday, 29 December 2017 16:45:33 GMT Wols Lists wrote: > (Plus, of course, so much development is done for the American market, > so they don't realise how hard it is to get a change like A4 to stick :-( Damned colonials. It's like the baseball "world series": no-one outside north America plays it - in fact, in this country it's a girls' school game. No-one outside north America uses letter-size paper either. They're in a small minority. Anyone might think they were the only people on the planet. Sheesh (to coin a phrase). -- Regards, Peter.
Re: [gentoo-user] Kernel 4.14.7 no longer switches to VT7
On 21/12/2017 17:41, Jörg Schaible wrote: > Hi, > > after the update and installation of gentoo-sources-4.14.7 my two machines no > longer switch to SDDM on > VT7, it stays on VT1. However, I can switch manually using CTRL-ALT-7 to SDDM > and login as usual. If I boot > with the last stable kernel 4.12.12 anything is back to normal and the login > screen of SDDM appears directly > while the rest of the modules is loaded in background. > > Both machines have older Radeon chips (REDWOOD and CEDAR) and I managed to > load also their firmware > with the new kernel 4.14.7, but there's still no automatic switch to VT7 > anymore. > > I found nothing obvious in /var/log/messages, dmesg or Xorg.0.log. What may > cause this weird behavior? > > Cheers, > Jörg > > It's probably a dodgy kernel point bersion, 4.14 is problematic. Alice Ferrazzi posted this to gentoo-dev earlier today: =start quote= Hello, We have recently started the stabilization of gentoo-sources-4.14.8. Very soon we received reports regarding broken e1000e driver [1] and moved to gentoo-sources-4.14.8-r1. Since then we keep receiving new problems related to 4.14.x kernel: - IPSec is broken [2] - Change in 4.14.9 broke nVIDIA driver [3] - Colors on console are broken with some Radeon HD cards [4] - BUG report on boot [5] - Unbootable system with CONFIG_MCORE2 [6] - ...more bugs [7] While not all issues are present in gentoo-sources-4.14.8-r1 we are concerned about the current stability/quality of the 4.14.x branch in general and don't feel comfortable recommending 4.14.x branch for general use at the moment. But that's what a stable USE flag means for most Gentoo users. So, for now, we have decided to drop gentoo-sources-4.14.x stable keywords. We will keep watching 4.14 branch and once the stability/quality matches our requirements we will restart stabilization. Keep in mind: We are only dropping stable USE flags. If gentoo-sources-4.14.x works for you and you want to keep it, just keyword the package on your own! = end quote= If you want to fix the bugs, then by all means soldier on. But if your intent is to have a working system that boots, probably drop using 4.14.x and go back to say 4.12.x ? -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: depclean confusion
Am Tue, 19 Dec 2017 23:43:35 +0200 schrieb Nikos Chantziaras: > On 19/12/17 23:18, Walter Dnes wrote: >>Finishing off an install, and running "emerge --depclean" >> >> = > Assigning files to packages... >> * In order to avoid breakage of link level dependencies, one or more >> * packages will not be removed. This can be solved by rebuilding the >> * packages that pulled them in. >> * >> * sys-libs/db-5.3.28-r2 pulled in by: >> * sys-apps/iproute2-4.14.1-r1 needs libdb-5.3.so * > Adding lib providers to graph... >> = >> >> 1) I've rebuilt iproute2 >> >> [ebuild R] sys-apps/iproute2-4.14.1-r1::gentoo USE="-atm -berkdb >> -iptables -ipv6 -minimal (-selinux)" 0 KiB > > Unmerge it anyway and then rebuild iproute2. It seems like an automagic > dep. It should not be using db when the berkdb USE flag is not set. > Since it does, it's a bug. This is most of the times caused by configure scripts auto-detecting the presence of certain libs. Such behavior should be disabled and indicates a missing explicit disable/enable in the ebuild. You should report it. > However, rebuilding it after unmerging db should fix it. > > With that being said, do a "quickpkg sys-libs/db" first to get a tarball > backup, just to be safe if you need to restore it. -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] segfault in gedit / glib
On Fri, Dec 29, 2017 at 3:07 AM, Adam Carter wrote: > > > On Fri, Dec 29, 2017 at 4:59 PM, P Levine wrote: > >> On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter >> wrote: >> >>> System is ~amd64. If i try to open a text file in gnome via double >>> click, i get; >>> $ journalctl -b | grep segf >>> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip >>> 7f7c2550ba74 sp 7fff66834850 error 4 in >>> libglib-2.0.so.0.5200.3[7f7c254c+114000] >>> >>> The following work; >>> Open gedit first, then open the file >>> Use right click -> Open With Other Application and chose LibreOffice >>> writer. >>> >>> I've rebuild glib and gedit. Are there any clues on the issue in this >>> trace? >>> >>> $ strace gedit >>> >>> >> >> Try opening the file via gedit in a user shell and see if segfaults and >> if there is any other output. >> > > The "Segmentation fault (core dumped)" from above is the only non-strace > output (or have I misunderstood your instruction?) > The segfault message would exist in the dmesg/journalctl. Please open a user shell in Gnome and type "gedit ", substituting a text file for . Press enter. Does this segfault and if so is there anything else printed?
[gentoo-user] Re: Kernel 4.14.7 no longer switches to VT7
Am Thu, 21 Dec 2017 15:41:26 + schrieb Jörg Schaible: > Hi, > > after the update and installation of gentoo-sources-4.14.7 my two > machines no longer switch to SDDM on VT7, it stays on VT1. However, I > can switch manually using CTRL-ALT-7 to SDDM and login as usual. If I > boot with the last stable kernel 4.12.12 anything is back to normal and > the login screen of SDDM appears directly while the rest of the modules > is loaded in background. > > Both machines have older Radeon chips (REDWOOD and CEDAR) and I managed > to load also their firmware with the new kernel 4.14.7, but there's > still no automatic switch to VT7 anymore. > > I found nothing obvious in /var/log/messages, dmesg or Xorg.0.log. What > may cause this weird behavior? If I remember right (many months ago), I fixed it by changing one line in /etc/sddm.conf: [X11] ServerArguments=-nolisten tcp -keeptty This is where the magic happens You may want to add or remove that parameter... -- Regards, Kai Replies to list-only preferred.
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On 29/12/17 16:13, Alan McKinnon wrote: > The only "correct" place for papersize nowadays is in whatever the user > is using to get something to print. And there are lots of those. > Something like CUPS ought to make it all so much easier but I find CUPS > just makes my life insanely difficult. So I mail my docs to my wife and > she prints them from Windows for me Exactly! I think the problem is all the layers of indirection and pipes. If you *pipe* a print job, it is very difficult to pass metadata such as papersize along. So the only place the printing back end can get this information from is the defaults. And if you've got something like a photo-printer when half the time the paper is different from the default, you're up a gum tree ... and of course you can't have the app change the defaults because you can't guarantee that by the time that job hits the printer some other app hasn't come along and changed them to something different ... It would be fine, of course, if all apps used the CUPS printer dialog, but my experience is that a lot of cross-platform apps use their own because CUPS isn't there for a lot of their target market ... on Windows they can guarantee the windows dialog, on Apple they can guarantee CUPS, but on linux? It's *usually* - but not always - there so they need to be able to cope if it's missing, so they just assume it isn't ... (Plus, of course, so much development is done for the American market, so they don't realise how hard it is to get a change like A4 to stick :-( Cheers, Wol
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On 29/12/2017 16:30, Peter Humphrey wrote: > On Friday, 29 December 2017 13:57:31 GMT Alan Mackenzie wrote: > >> I think the bug is that "A4" has to be set in so many places, where "so >> many" means more than one. In a well designed printing system, there >> would be just one place to set it. > > And that would have to be /etc/papersize, no? No, not really. IIRC that comes from ages back in time when lpd was all the rage and really refers to the computer *driving* the printer, not the computer *using* the printer Nowadays you can have as many printers as you want (even printers that are not physical objects, like pdf) and each printer can have as many different page sizes as it has trays. The only "correct" place for papersize nowadays is in whatever the user is using to get something to print. And there are lots of those. Something like CUPS ought to make it all so much easier but I find CUPS just makes my life insanely difficult. So I mail my docs to my wife and she prints them from Windows for me > >>> I'm posting this here to save others time, should they come across the >>> same problem. >> >> I've been luckier with printing, but thanks all the same. Who knows >> when I might no longer be so lucky. > > Indeed. > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On Friday, 29 December 2017 14:30:43 GMT Peter Humphrey wrote: > > I think the bug is that "A4" has to be set in so many places, where "so > > many" means more than one. In a well designed printing system, there > > would be just one place to set it. > > And that would have to be /etc/papersize, no? Well, /etc/papersize should be sourced when seeking a default setting, unless $PAPERSIZE, or $PAPERCONF is set. In any case, cups should be able to change the printer's default setting to a different size. Also various applications should be able to select a different size when submitting individual print jobs, or we would have trouble printing labels, envelopes, photographs and what have you. What should not really happen is setting defaults for the OS, the printer and the application and then ALL OF THEM being ignored by Brother's lpdwrapper script. Or am I asking too much by companies who shy away from publishing openprinting code. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On Friday, 29 December 2017 13:57:31 GMT Alan Mackenzie wrote: > I think the bug is that "A4" has to be set in so many places, where "so > many" means more than one. In a well designed printing system, there > would be just one place to set it. And that would have to be /etc/papersize, no? > > I'm posting this here to save others time, should they come across the > > same problem. > > I've been luckier with printing, but thanks all the same. Who knows > when I might no longer be so lucky. Indeed. -- Regards, Peter.
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
Hello, Mick. On Fri, Dec 29, 2017 at 13:51:01 +, Mick wrote: > On Thursday, 28 December 2017 06:14:23 GMT taii...@gmx.com wrote: > > For the record I would also like to add that using the duplexer on some > > poorly designed printers cuts off the bottom or top of the page without > > any type of notification. > Debugging cups and trying all conceivable combos of settings didn't get me > anywhere. Then I decided to start looking around the brother driver files > installed under /opt/brother/Printers/hl3140cw/, where I found ./inf/ > brhl3140cwrc and ./inf/brhl3140cwfunc both specifying Letter instead of A4 as > paper size. > So, I've set "PageSize=A4" in brhl3140cwrc and it now prints correctly > aligned > pages once more. > I'm not sure if this is the default path for these files across distros, or > if > some symlink from /usr/libexec/cups/filter/ or /usr/share/cups/model/ is not > working as it should. In any case, the bug seems to be that using the cups > GUI interface doesn't have any effect on the driver configuration files which > are by default set to PageSize=Letter and also messes up the created ppd file > used by cups. I think the bug is that "A4" has to be set in so many places, where "so many" means more than one. In a well designed printing system, there would be just one place to set it. > I'm posting this here to save others time, should they come across the same > problem. I've been luckier with printing, but thanks all the same. Who knows when I might no longer be so lucky. > -- > Regards, > Mick -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: [was: What can cause printer to crop top of page?] /etc/papersize is ignored
On Thursday, 28 December 2017 06:14:23 GMT taii...@gmx.com wrote: > For the record I would also like to add that using the duplexer on some > poorly designed printers cuts off the bottom or top of the page without > any type of notification. Debugging cups and trying all conceivable combos of settings didn't get me anywhere. Then I decided to start looking around the brother driver files installed under /opt/brother/Printers/hl3140cw/, where I found ./inf/ brhl3140cwrc and ./inf/brhl3140cwfunc both specifying Letter instead of A4 as paper size. So, I've set "PageSize=A4" in brhl3140cwrc and it now prints correctly aligned pages once more. I'm not sure if this is the default path for these files across distros, or if some symlink from /usr/libexec/cups/filter/ or /usr/share/cups/model/ is not working as it should. In any case, the bug seems to be that using the cups GUI interface doesn't have any effect on the driver configuration files which are by default set to PageSize=Letter and also messes up the created ppd file used by cups. I'm posting this here to save others time, should they come across the same problem. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] help installing Gentoo on Asus Transformer T101HA
On venerdì 29 dicembre 2017 03:40:46 CET Daniel Frey wrote: > On 12/28/17 12:36, Stefano Crocco wrote: > > Hello to everyone, > > I'm trying to install Gentoo on an Asus Transformer T101HA and there are > > some issues I'd need help with. > > > > First of all, I must say that many things worked fairly easily. I > > performed > > the installation from a SysrescueCD USB stick where almost everything, > > including WiFi and touchscreen, worked out of the box (aside from having > > to > > find out how to rotate the screen, both in X and in framebuffer). > > > > After installing everything (of course, compiling all packages on my > > desktop machine), there are still some things which don't work. One is > > the touch screen but, given that it worked using the SysrescueCD stick, > > I'm not worried too much about it (besides, I'm not planning to use it > > much). > > > > The most troublesome issues, right now, are the sound card and the SD card > > reader. Both of them simply don't seem to exist: they didn't work with the > > SysrescueCD stick, I can't find any mention of either of them in the > > output of dmesg, lspci and lsusb and Google gave pratically no answer. > > I'm starting to think neither of them is supported with Linux but I > > haven't been able to find any definitive information about this. I tried > > activating all kernel options I could find which seemed vaguely related > > to them, but to no effect. > > > > Unfortunately, I haven't been able even to find out the exact models of > > the > > cards. All I know is that (according to Windows 10) the sound card is an > > Intel SSt Audio Device (WDM), while the codec is a Realtek I2S Audio > > Codec. I have no information at all on the SD card reader. The > > motherboard, according to lshw, is a T101HA by AUSTeK. > > > > I attach my last version of the kernel config (using gentoo-sources-4.14.9 > > which, I just found out, now seems to be masked). > > > > I'd be glad for any hint about these issues. I spent all of this afternoon > > trying to solve them and I can't really think what else I could try. > > > > Thanks in advance > > > > Stefano > > Hmm, after googling it seems some of those Transformer models are not > linux friendly. There are reports of no driver for the SD card reader > and models earlier than yours needed firmware to use the sound card. > > You might be able to use hints from: > > https://wiki.debian.org/InstallingDebianOn/Asus/T100TA > > to get the sound working, even though the model is older than yours. > > Dan Thanks for the answer. Unfortunately, the hints on the page you linked didn't work. The firmware on that page is already included in linux-firmware (unless I'm missing something, of course). I tried compiling it in the kernel, but with no result. I believe the problem is something other than missing firmware, because I see no messages about failures to load firmware in dmes. I just noticed there are some audio-related messages in dmesg which I hadn't noticed before: [drm] HDaudio controller not detected, using LPE audio instead cht-bsw-rt5645: ASoC: CODEC DAI snd-soc-dummy-dai not registered cht-bsw-rt5645: snd_soc_register_card failed -517 I don't know whether they're significant or they're spurious messages caused by my including every possible sound card drivers in the kernel. I fear you're right about this Transformer not being linux friendly: I just found out that it doesn't recognize the power button, either. I think right now I need a break from this machine: I've alread spent about three days working on it and I have other things to do. I'll try to rebuild a kernel from scratch in a few days; in the meanwhile I'll use it as it is. Thanks again Stefano
Re: [gentoo-user] segfault in gedit / glib
On Fri, Dec 29, 2017 at 4:59 PM, P Levine wrote: > On Thu, Dec 28, 2017 at 9:01 PM, Adam Carter > wrote: > >> System is ~amd64. If i try to open a text file in gnome via double click, >> i get; >> $ journalctl -b | grep segf >> Dec 29 12:17:32 phat kernel: gedit[1177]: segfault at 7f7c0d36e880 ip >> 7f7c2550ba74 sp 7fff66834850 error 4 in >> libglib-2.0.so.0.5200.3[7f7c254c+114000] >> >> The following work; >> Open gedit first, then open the file >> Use right click -> Open With Other Application and chose LibreOffice >> writer. >> >> I've rebuild glib and gedit. Are there any clues on the issue in this >> trace? >> >> $ strace gedit >> >> > > Try opening the file via gedit in a user shell and see if segfaults and if > there is any other output. > The "Segmentation fault (core dumped)" from above is the only non-strace output (or have I misunderstood your instruction?)
