Re: [gentoo-user] Gummiboot -> efibootmgr

2016-08-24 Thread Peter Humphrey
On Wednesday 24 Aug 2016 11:57:04 Mike Gilbert wrote:
> On Tue, Aug 23, 2016 at 5:15 AM, Peter Humphrey  
wrote:
> > On Monday 22 Aug 2016 21:08:56 Neil Bothwick wrote:
> >> On Mon, 22 Aug 2016 15:59:41 +, J. Roeleveld wrote:
> >> > I really don't understand the urgency in treecleaning gummiboot.
> >> > Like grub1, it will still work in 10 years time...
> >> 
> >> I agree, just copy it to a local overlay.
> > 
> > How would I manage the distfile, which at present is in dev.gentoo.org?
> > I
> > assume it will disappear from there when gummiboot is deleted. Should I
> > create a files directory for it under
> > /usr/local/portage/sys-boot/gummiboot? What would I do then with
> > SRC_URI in the ebuild?
> 
> The file is in my personal devspace, and I will not be removing it for
> the foreseeable future.
> 
> Also, if you are looking for a gummiboot replacement, please have a
> look at me comments on the related bug report.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=556734#c16

Interesting; thanks Mike. I'll have a look at that tomorrow.

-- 
Rgds
Peter




Re: [gentoo-user] Gummiboot -> efibootmgr

2016-08-24 Thread Mike Gilbert
On Tue, Aug 23, 2016 at 5:15 AM, Peter Humphrey  wrote:
> On Monday 22 Aug 2016 21:08:56 Neil Bothwick wrote:
>> On Mon, 22 Aug 2016 15:59:41 +, J. Roeleveld wrote:
>> > I really don't understand the urgency in treecleaning gummiboot.
>> > Like grub1, it will still work in 10 years time...
>>
>> I agree, just copy it to a local overlay.
>
> How would I manage the distfile, which at present is in dev.gentoo.org? I
> assume it will disappear from there when gummiboot is deleted. Should I
> create a files directory for it under /usr/local/portage/sys-boot/gummiboot?
> What would I do then with SRC_URI in the ebuild?

The file is in my personal devspace, and I will not be removing it for
the foreseeable future.

Also, if you are looking for a gummiboot replacement, please have a
look at me comments on the related bug report.

https://bugs.gentoo.org/show_bug.cgi?id=556734#c16



[gentoo-user] net-libs/webkit-gtk build failure

2016-08-24 Thread 刘洋
Hi list,

I got a failure when emerge webkit-gtk, but it seemd that only for
certain versions of this package.
2.4.11 and 2.4.11-r200 were okay except 2.10.9 or 2.12.3

Here is the last line of build.log.

[5415/5420] : && /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++   -O2
-march=native -pipe -fomit-frame-pointer -fno-strict-aliasing
-std=c++11  -Wl,-O1 -Wl,--as-needed -Wl,--no-keep-memory
-Wl,--reduce-memory-overheads @CMakeFiles/WebProcess.rsp  -o
bin/WebKitWebProcess  && :
[5416/5420] : && /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++   -O2
-march=native -pipe -fomit-frame-pointer -fno-strict-aliasing
-std=c++11  -Wl,-O1 -Wl,--as-needed -Wl,--no-keep-memory
-Wl,--reduce-memory-overheads @CMakeFiles/NetworkProcess.rsp  -o
bin/WebKitNetworkProcess  && :
[5417/5420] : && /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++   -O2
-march=native -pipe -fomit-frame-pointer -fno-strict-aliasing
-std=c++11  -Wl,-O1 -Wl,--as-needed -Wl,--no-keep-memory
-Wl,--reduce-memory-overheads @CMakeFiles/PluginProcess.rsp  -o
bin/WebKitPluginProcess  && :
FAILED: cd 
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/Source/WebKit2
&& CC=/usr/lib64/ccache/bin/x86_64-pc-linux-gnu-gcc
CFLAGS=-Wno-deprecated-declarations LDFLAGS=
LD_LIBRARY_PATH="/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/lib:"
/usr/bin/g-ir-scanner --quiet --warn-all --symbol-prefix=webkit
--identifier-prefix=WebKit --namespace=WebKit2 --nsversion=4.0
--include=GObject-2.0 --include=Gtk-3.0 --include=Soup-2.4
--include-uninstalled=/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/JavaScriptCore-4.0.gir
--library=webkit2gtk-4.0 --library=javascriptcoregtk-4.0
-L/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/lib
--no-libtool --pkg=gobject-2.0 --pkg=gtk+-3.0 --pkg=libsoup-2.4
--pkg-export=webkit2gtk-4.0
--output=/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/WebKit2-4.0.gir
--c-include="webkit2/webkit2.h" -DBUILDING_WEBKIT
-DWEBKIT2_COMPILATION
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/JavaScriptCore/ForwardingHeaders
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/DerivedSources
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/DerivedSources/webkit2gtk
-I/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/DerivedSources/ForwardingHeaders/webkit2gtk
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/DerivedSources/webkit2gtk/webkit2/WebKitEnumTypes.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkit-gtk-2.10.9_build/DerivedSources/webkit2gtk/webkit2/WebKitVersion.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitAuthenticationRequest.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitBackForwardList.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitBackForwardListItem.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitColorChooserRequest.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitCredential.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitContextMenu.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitContextMenuActions.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitContextMenuItem.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitCookieManager.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitDefines.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitDownload.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitEditingCommands.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitEditorState.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitError.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitFaviconDatabase.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitFileChooserRequest.h
/var/tmp/portage/net-libs/webkit-gtk-2.10.9/work/webkitgtk-2.10.9/Source/WebKit2/UIProcess/API/gtk/WebKitFindController.h

Re: [gentoo-user] Gummiboot -> efibootmgr

2016-08-24 Thread Peter Humphrey
On Tuesday 23 Aug 2016 21:00:47 Mick wrote:

> I have built a UEFI system with no initramfs (I don't need it), or
> systemd (I don't want it), or any assisting boot manager.  I have been
> happily using the EFI kernel stub and on the rare occasion I need to boot
> an alternative kernel I press F2 (or whatever it is) to get into BIOS and
> shift the boot order of the kernels I have stashed in /boot/EFI/BOOT/. 
> If the need has arisen to use a different kernel before I (re)boot, then
> I can also change the kernels' boot order using  efibootmgr from a
> terminal.  This has been going on for the last two years or so without
> any complaints from the users, or myself.  The only drawback is I can't
> boot sysrescuecd ISO straight off the boot menu without grub2 and
> friends.  Again, fingers X,  this is quite a rare occasion for this
> particular box.

It hadn't occurred to me that I could have more than one kernel in 
/boot/EFI/Boot. I'll certainly look into that idea - thanks Mick!

> BTW, have you had a look at rEFInd?  In the absence of Gummiboot you may
> fulfils your needs.

I hadn't heard of it, but it looks interesting now you point it out.

Well, that's my research topic for today sorted out.  :)

-- 
Rgds
Peter




Re: [gentoo-user] Fwd: [gentoo-dev] Last rites: kde-apps/ksnapshot

2016-08-24 Thread J. Roeleveld
On Monday, July 18, 2016 08:59:53 AM Neil Bothwick wrote:
> On Mon, 18 Jul 2016 06:59:02 +0100, Mick wrote:
> > > > I beg your pardon - my cognitive bias took over.  It does
> > > > auto-increment if the name of the picture exists, but it appears
> > > > that .png  is the default and only image format spectacle will use
> > > > at present.
> > > 
> > > Not here. I take a screenshot and save it as "test_1.png". Then I take
> > > another and hit Save As, the name defaults to ".png".
> > 
> > Its behaviour is not as one would expect based on previous Kscreenshot
> > experience:
> > 
> > I set up the default file name in Configure Save Options as "Test".
> > 
> > I take a pic, press Ctrl+S and it is saved as "Test.png", second pic
> > will be saved as "Test-1.png", third pic saved as "Test-2.png" and so
> > on.
> 
> Yes, that works, but it always saves it in the same location. With Save
> As it remembers the last location but does not increment the filename.
> This is the behaviour I need, saving sequential screenshots in a
> particular directory, and I suspect Joost's needs are similar.
> 
> Since it does increment the filename with Save, but not with Save As, I
> feel this is a bug rather than a deliberate missing feature, so I'll file
> a report.
> 
> It's still not as useful as KSnapshot's approach of remembering both the
> location and the name, it even showed the name a new screenshot would be
> saved as in the title bar.

Been trying out different options with Spectacle, but I still can't get it to 
do anything sane.

If you managed to file a bug report, can you provide the URL to it?

Thanks,

Joost

PS. sorry for the late reply to this, got stuck with work and still trying to 
catch up...