Re: [gentoo-user] hylafaxplus-5.5.5 not working
On 03/08/2017 10:50 PM, the...@sys-concept.com wrote: > After upgrade my hylafaxplus-5.5.5 is not working, fax line is not > responding. > > Whey I try to sent a fax, /sbin/faxq is hanging-up (CPU usage 100%) > > hylafaxplus-5.5.5 is the only version in portage. They removed all other > versions :-/ I've tried to downgrade to hylafaxplus-5.5.4-r1 but I'm getting a patch error: --- >>> Failed to emerge net-misc/hylafaxplus-5.5.4-r1, Log file: >>> '/var/tmp/portage/net-misc/hylafaxplus-5.5.4-r1/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.40, 0.30, 0.23 * Package:net-misc/hylafaxplus-5.5.4-r1 * Repository: Local * USE:abi_x86_64 amd64 elibc_glibc kernel_linux ldap pam userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> cfg-update-1.8.2-r1: Creating checksum index... * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/net-misc/hylafaxplus/files/ldconfig-patch * ( ldconfig-patch ) * ERROR: net-misc/hylafaxplus-5.5.4-r1::Local failed (prepare phase): * Cannot find $EPATCH_SOURCE! * * Call stack: * ebuild.sh, line 115: Called src_prepare * environment, line 2516: Called epatch '/usr/local/portage/net-misc/hylafaxplus/files/ldconfig-patch' * environment, line 774: Called die * The specific snippet of code: * die "Cannot find \$EPATCH_SOURCE!"; * -- How do I get that "$EPATCH_SOURCE!" Thanks for any help! --- Thelma
[gentoo-user] hylafaxplus-5.5.5 not working
After upgrade my hylafaxplus-5.5.5 is not working, fax line is not responding. Whey I try to sent a fax, /sbin/faxq is hanging-up (CPU usage 100%) hylafaxplus-5.5.5 is the only version in portage. They removed all other versions :-/ -- Thelma
Re: [gentoo-user] Helvetica fonts
On Wed, 8 Mar 2017 13:56:10 -0700, Thelma (the...@sys-concept.com) wrote about "Re: [gentoo-user] Helvetica fonts" (in <9a5a-731b-79c8-11c5-843caf8c5...@sys-concept.com>): [snip] > The "Tbird_msg.pdf" you attached and other pdf files that I downloaded > from different places are using: DejaVuSans.ttf font as well but they > look much, much nicer than the one I create using my Firefox. I don't think any particular font is the problem. I think it is the font selection that is causing issues. > XFT_DEBUG=1 flpsed Tbird_msg.pdf > XFT_DEBUG=1 > XftFontInfoFill: /usr/share/fonts/dejavu/DejaVuSans.ttf: 0 (14 pixels) What does the Xfont debug trace say about your problem documents? -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: [gentoo-user] [Off-Topic] arch-openrc
On Wed, Mar 8, 2017 at 4:06 PM, Daniel Frey wrote: > On 03/08/2017 11:08 AM, Rich Freeman wrote: >> And a parting bit of trivia: The overwhelming majority of >> Gentoo-based installations use upstart as their service manager, >> despite it not even being in the Gentoo repository. >> > > This I find interesting, what data source is this based off of? > ChromeOS. It is a Gentoo derivative, and uses upstart as its service manager. And it gets installed on more new laptops than OSX. Yes, the #1 desktop Linux distro is a Gentoo derivative. Take that Canonical. :) -- Rich
Re: [gentoo-user] [Off-Topic] arch-openrc
On 03/08/2017 11:08 AM, Rich Freeman wrote: > And a parting bit of trivia: The overwhelming majority of > Gentoo-based installations use upstart as their service manager, > despite it not even being in the Gentoo repository. > This I find interesting, what data source is this based off of? Dan
Re: [gentoo-user] [Off-Topic] arch-openrc
On Wednesday 08 Mar 2017 14:08:00 Rich Freeman wrote: > On Wed, Mar 8, 2017 at 1:50 PM, Mick wrote: > > Well what do you know?! Alternative to monolithic stack solutions now > > exist as alternatives for other distros too: > > > > https://sourceforge.net/projects/archopenrc/ > > > > PS. I do not wish to kick off a flame war on this topic, enough electrons > > have been wasted in past rants. Just to inform those who may be > > interested in this. > > Interesting. It looks like they bundle all their openrc scripts in > the openrc package. I was curious about this since the right place to > put scripts is one of those things that tends to come up in debate. > > In Gentoo openrc, systemd, and anything else keep their scripts in the > packages they go with. > > Pros: > - You don't end up with scripts for packages you don't use. > - The openrc/systemd/runit/upstart/etc packages don't get bumped 3 > times per week when any script changes anywhere (IMO the biggest > driver) > - If upstream provides the scripts (common for systemd, less so for > openrc but it may happen) then make install can take care of them > > Cons: > - You do end up with scripts for service managers you don't use > (assuming you don't mask them). > - Individual package maintainers have to be at least somewhat > concerned with these scripts even if they don't use the service > manager they apply to. > > I think the Gentoo way is better because of the elimination of bumps. > However, Arch is much more strongly in the systemd camp (as I > understand it), so I suspect there would be more resistance there to > maintaining openrc scripts inside individual packages. So, openrc > ended up having to bundle them all in one package. The Gentoo > approach took a Council decision as some package maintainers objected > to the inclusion of systemd units. Other than the initial debate IMO > it has gone smoothly since. > > And a parting bit of trivia: The overwhelming majority of > Gentoo-based installations use upstart as their service manager, > despite it not even being in the Gentoo repository. Ha! I didn't know this. I thought upstart was a *buntu feature only. Yes, the gentoo way of package-provided openrc scripts makes more sense to me too, especially for gentoo where no two systems are alike. On binary distros it may be easier for repos to provide a big openrc package with all their scripts bundled in there, but if you want to deviate from the vanilla distro then you're on your own. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Helvetica fonts
On 03/08/2017 11:32 AM, David W Noon wrote: > On Tue, 7 Mar 2017 16:39:55 -0700, Thelma (the...@sys-concept.com) wrote > about "Re: [gentoo-user] Helvetica fonts" (in > <9082ed1b-ccad-31e6-36ff-33feb2d0c...@sys-concept.com>): > > [snip] >> The two PFD documents that I created using both versions of Firefox: >> www-client/firefox >> www-client/firefox-bin >> >> from pdfinfo: >> Producer: cairo 1.9.5 (using Firefox) >> Producer: pdfTeX-1.40.16 (using Firefox) >> >> Both files are having problem viewing fonts using "flpsed". > > I have created a PDF of your message to which this message is replying. > I used Thunderbird, which uses cairo-1.9.5 also. See if the attached > document renders correctly with flpsed. If it does, the culprit will > likely be pdfTeX-1.40.16. If it looks ugly, it could well be Cairo -- > but given Cairo's purpose, that seems unlikely. > The "Tbird_msg.pdf" you attached and other pdf files that I downloaded from different places are using: DejaVuSans.ttf font as well but they look much, much nicer than the one I create using my Firefox. XFT_DEBUG=1 flpsed Tbird_msg.pdf XFT_DEBUG=1 XftFontInfoFill: /usr/share/fonts/dejavu/DejaVuSans.ttf: 0 (14 pixels) -- Thelma
Re: [gentoo-user] Helvetica fonts
On 03/08/2017 01:29 PM, James Cloos wrote: >> "t" == thelma writes: > > t> Which package contain "Helvetica" font? > t> I'm using "flpsed" and apparently it is using Helvetica font, which > t> "eselect fontconfig list" is not showing anything that resemble "helvet" > t> "eix helvet" is not showing anything either. > > t> The fonts in "flpsed" display are very rugged/pixelated, it is hard to > t> look at them. > > I read a number of posts in this thread; few had anything useful to say... > > First of all, FL_HELVETICA is a #define from fltk. > > Cf http://www.fltk.org/doc-1.1/enumerations.html > > So with which USE flags have you compiled fltk? > > If you have eix installed, eix fltk will show them. > > You probably want the xft and/or cairo flags enabled. > > If you have xft, fltk will use fontconfig and client-side fonts. > > And then running: > > :; fc-match helvetica > > will show you which font fontconfig will use when asked for helvetica. > > Also, try this: > > :; XFT_DEBUG=1 flpsed > > If fltk uses xft, then that will show you which fonts it selected. > > If nothing prints than fltk is compiled to use server-side fonts. > Which you probably prefer to avoid. > > -JimC Thank you Jim for the input. Yes, fltk is compiled with: cairo xfl eix fltk Installed versions: 1.3.3-r3(1)(01:43:37 PM 03/07/2017)(cairo opengl threads xft xinerama -debug -doc -examples -games -static-libs) fc-match helvetica Helvetica.pfa: "Helvetica" "Regular" XFT_DEBUG=1 flpsed invoice_5566.pdf XFT_DEBUG=1 XftFontInfoFill: /usr/share/fonts/dejavu/DejaVuSans.ttf: 0 (14 pixels) So I have Helvetica but flpsed is using DejaVuSans.ttf, question is why? -- Regards Thelma
Re: [gentoo-user] Helvetica fonts
> "t" == thelma writes: t> Which package contain "Helvetica" font? t> I'm using "flpsed" and apparently it is using Helvetica font, which t> "eselect fontconfig list" is not showing anything that resemble "helvet" t> "eix helvet" is not showing anything either. t> The fonts in "flpsed" display are very rugged/pixelated, it is hard to t> look at them. I read a number of posts in this thread; few had anything useful to say... First of all, FL_HELVETICA is a #define from fltk. Cf http://www.fltk.org/doc-1.1/enumerations.html So with which USE flags have you compiled fltk? If you have eix installed, eix fltk will show them. You probably want the xft and/or cairo flags enabled. If you have xft, fltk will use fontconfig and client-side fonts. And then running: :; fc-match helvetica will show you which font fontconfig will use when asked for helvetica. Also, try this: :; XFT_DEBUG=1 flpsed If fltk uses xft, then that will show you which fonts it selected. If nothing prints than fltk is compiled to use server-side fonts. Which you probably prefer to avoid. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-user] [Off-Topic] arch-openrc
On Wed, Mar 8, 2017 at 1:50 PM, Mick wrote: > Well what do you know?! Alternative to monolithic stack solutions now exist > as alternatives for other distros too: > > https://sourceforge.net/projects/archopenrc/ > > PS. I do not wish to kick off a flame war on this topic, enough electrons have > been wasted in past rants. Just to inform those who may be interested in > this. Interesting. It looks like they bundle all their openrc scripts in the openrc package. I was curious about this since the right place to put scripts is one of those things that tends to come up in debate. In Gentoo openrc, systemd, and anything else keep their scripts in the packages they go with. Pros: - You don't end up with scripts for packages you don't use. - The openrc/systemd/runit/upstart/etc packages don't get bumped 3 times per week when any script changes anywhere (IMO the biggest driver) - If upstream provides the scripts (common for systemd, less so for openrc but it may happen) then make install can take care of them Cons: - You do end up with scripts for service managers you don't use (assuming you don't mask them). - Individual package maintainers have to be at least somewhat concerned with these scripts even if they don't use the service manager they apply to. I think the Gentoo way is better because of the elimination of bumps. However, Arch is much more strongly in the systemd camp (as I understand it), so I suspect there would be more resistance there to maintaining openrc scripts inside individual packages. So, openrc ended up having to bundle them all in one package. The Gentoo approach took a Council decision as some package maintainers objected to the inclusion of systemd units. Other than the initial debate IMO it has gone smoothly since. And a parting bit of trivia: The overwhelming majority of Gentoo-based installations use upstart as their service manager, despite it not even being in the Gentoo repository. -- Rich
[gentoo-user] [Off-Topic] arch-openrc
Well what do you know?! Alternative to monolithic stack solutions now exist as alternatives for other distros too: https://sourceforge.net/projects/archopenrc/ PS. I do not wish to kick off a flame war on this topic, enough electrons have been wasted in past rants. Just to inform those who may be interested in this. -- Regards, Mick
Re: [gentoo-user] Helvetica fonts
On Tue, 7 Mar 2017 16:39:55 -0700, Thelma (the...@sys-concept.com) wrote about "Re: [gentoo-user] Helvetica fonts" (in <9082ed1b-ccad-31e6-36ff-33feb2d0c...@sys-concept.com>): [snip] > The two PFD documents that I created using both versions of Firefox: > www-client/firefox > www-client/firefox-bin > > from pdfinfo: > Producer: cairo 1.9.5 (using Firefox) > Producer: pdfTeX-1.40.16 (using Firefox) > > Both files are having problem viewing fonts using "flpsed". I have created a PDF of your message to which this message is replying. I used Thunderbird, which uses cairo-1.9.5 also. See if the attached document renders correctly with flpsed. If it does, the culprit will likely be pdfTeX-1.40.16. If it looks ugly, it could well be Cairo -- but given Cairo's purpose, that seems unlikely. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Tbird_msg.pdf Description: Adobe PDF document
[gentoo-user] emerge option "--color=n" not working WAS: Need coaching with emerge failure logs
On 170228-20:07-0500, Harry Putnam wrote: > Miroslav Rovis writes: > > > On 170226-09:42-0500, Harry Putnam wrote: > >> Stroller writes: > > ... > >> > >> > Example at the beginning: [32;01m * > >> > Example from the end: * > >> > > >> > Output to the terminal these would show the text in different colours, > >> > but the output was redirected to a textfile or mishandled in a > >> > copy-paste operation (not sure if screen or tmux does this?). I just checked out again on --color=n (I expect it is the same as --color n), mentioned below: > >> > Running emerge with `--color n` would have made this log much more > >> > readable. Its size already makes it hard to search. ... > >> > >> Just so you know... I did try that. [--color n] The resulting log > >> looked exactly the same. ... > > > > This is hard to believe. I just tried, and either: > > > > --color n > > > > or: > > > > --color=n > > > > added to the emerge line, worked. > > > > Are you looking at the Terminal output? If so that is not what I > posted. > > I did mention that yes `--color n' kills the color in terminal output. At first it worked in the terminal, and in the logs, this time around, here. > Read the whole paragraph you quote 1 sentence from above. > > This is the end of that para: > > ". . . . . . . . . . . . . . . . . . . . . . . . I don't expect > anyone would have noticed the comment... but it does seem a bit off > that I see no differernce here. That is, no difference in the actual > log emerge creates. I do see the difference in the terminal output." This time around, and it was a lot of emerge'ing, after a couple of dozen emerge'ing of various packages, while that '--color=n' option had, at start of using it, removed color from the terminal and from the logs... after a couple of dozen emerge'ing of various packages it stopped removing color, completely stopped, in the terminal and in the logs. This is a bug, and if this is how others have it too, than this needs to be reported to bugzilla. I would do it, but I'm a little unwell at this time, can't do it, don't know if I'll be able to do it later. Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Emerge @system causing gcc downgrade
> On 7 Mar 2017, at 16:14, White, Phil wrote: > > OK - talking this through is helping. I *have* done something strange here. > The currently installed version is 4.9.4 (from gcc --version), except that > portage believes that 5.4.0 is installed. Could you `grep -i gcc /var/lib/portage/world*` please? A copy of the whole world file(s) would be great, in fact, ideally as plain text attachments. Also, any chance you could set your mailer to send only plain text emails to the list? Cheers, Stroller.
