Re: [gnome-team] gtk+ on core-updates

Hello! Am Tue, Apr 11, 2023 at 02:36:13PM -0400 schrieb Maxim Cournoyer: > > I am also still questioning whether we should include gnome-boxes into the > > gnome meta package; it is a bit surprising to have a desktop environment > > depend on qemu. > GNOME Boxes is really part of the default

Re: [gnome-team] gtk+ on core-updates

Hi, Andreas Enge writes: > Hello! > > Am Mon, Apr 10, 2023 at 11:14:52PM -0400 schrieb Maxim Cournoyer: >> I don't know meson that much either, but I've updated the package to its >> latest 0.12.1 version, and it passes it's test suite, so we should be >> good! > > Good idea, it is also what I

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Hello! > > Am Mon, Apr 10, 2023 at 11:14:52PM -0400 schrieb Maxim Cournoyer: >> I don't know meson that much either, but I've updated the package to its >> latest 0.12.1 version, and it passes it's test suite, so we should be >> good! > > Good idea, it is also

Re: [gnome-team] gtk+ on core-updates

Hello! Am Mon, Apr 10, 2023 at 11:14:52PM -0400 schrieb Maxim Cournoyer: > I don't know meson that much either, but I've updated the package to its > latest 0.12.1 version, and it passes it's test suite, so we should be > good! Good idea, it is also what I tend to try out first... Repercussions

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer: >> OK, that's been fixed in meson-build-system; I've taken that opportunity >> to update our meson package to its latest 1.0.1 release too. > > Great, thanks a lot! The KDE package and the Gnome

Re: [gnome-team] gtk+ on core-updates

Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer: > OK, that's been fixed in meson-build-system; I've taken that opportunity > to update our meson package to its latest 1.0.1 release too. Great, thanks a lot! The KDE package and the Gnome package I have in my profile now build,

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > your gtk+ update on core-updates broke gnome packages since it somehow > moved the bin/ subdirectory from the bin to the out output, so that > gtk-update-icon-cache is not found any more by packages using gtk+:bin > as

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > your gtk+ update on core-updates broke gnome packages since it somehow > moved the bin/ subdirectory from the bin to the out output, so that > gtk-update-icon-cache is not found any more by packages using gtk+:bin > as

[gnome-team] gtk+ on core-updates

Hello Maxim, your gtk+ update on core-updates broke gnome packages since it somehow moved the bin/ subdirectory from the bin to the out output, so that gtk-update-icon-cache is not found any more by packages using gtk+:bin as input. Should the split not happen automagically? Maybe

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: >   * cons: probably not everything of Cargo.toml is implemented yet Another downside: in Cargo-land, the leaf package declares what ‘features’ (= configure flags for enabling things) it requires from dependencies. This works because Cargo

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: (b) To get a good grasp on what builds/what not, it would be useful     to build the channel at ci.guix.gnu.org or such.  More concretely,     the CI would grab all cargo-build-system rust apps from (gnu packages ...),     feed them to the

Re: antioxidant-build-system can be tested as a channel, + > GTK app 'castor' builds

kias...@disroot.org schreef op di 31-05-2022 om 17:45 [+]: > Hi Maxime, > > > > > Non-goals: > > > > * Produce exactly the same binaries with exactly the same dependencies as > > with > > Cargo. If you want to reproduce a binary produced with Cargo, use Cargo. > > > > If I compile

Re: antioxidant-build-system can be tested as a channel, + > GTK app 'castor' builds

Hi Maxime, > > Non-goals: > > * Produce exactly the same binaries with exactly the same dependencies as with > Cargo. If you want to reproduce a binary produced with Cargo, use Cargo. > If I compile project P to produce binary A (with antioxidant) and binary C (with Cargo), will A and C have

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: > (d) Implement support for "cdylib" such that things like librsvg can > be built. Some basic support now implemented in 7040ce32840ba74f948fe9d243e1eb393daec4fc, though probably more remains to be done for librsvg. signature.asc

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Ludovic Courtès schreef op ma 30-05-2022 om 17:26 [+0200]: [...] To make sure share a common understanding, could you post a summary of:   1. the goals;   2. the status;   3. pros and cons over the status quo and other options (if any!);   4. the next steps. > [...] (notabug.org is down, so I've

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Ludovic Courtès schreef op ma 30-05-2022 om 17:26 [+0200]: > (Unfortunately notabug.org is down since a few days ago.) For now, the fallback location https://github.com/emixa-d/antioxidant-fallback/ can be used. (rest of the response later) signature.asc Description: This is a digitally signed

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Hello, Maxime Devos skribis: > I've set up the channel things for the antioxidant repo, > so now you can put the following in channels.scm: > > (use-modules (guix ci)) > > (cons > (channel > (name 'antioxidated-packages) > (url "https://notabug.org/maximed/cargoless-rust-experiments;) >

antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

pull" and "guix shell antioxidated-castor -- castor" to run a 'castor' build (*) with antioxidant-build-system. (Warning: some crates were updated or added without checking the source code diff for malware!) (*) A graphical web browser for Gemini using the GTK stack, implemented in Rus

Re: Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

Zhu Zihao schreef op zo 13-03-2022 om 00:06 [+0800]: > Can you show me the link of the libcairo conflict example you said? > > I don't know what cause the segfaults in your example. C linker will > embed the full path of the library into the RUNPATH, unless > LD_LIBRARY_PATH is set, C library

Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

This problem is not related to that patch so I would like to discuss here. Maxime Devos writes: > [[PGP Signed Part:Undecided]] > Zhu Zihao schreef op za 12-03-2022 om 10:38 [+0800]: >> > What if a program uses both 'pango' and gtk?  Then IIUC, it would >> > simultanuo

Re: Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

tumashu schreef op ma 28-02-2022 om 08:22 [+0800]: > by the way, if my system-config enable mate-1.24 desktop type.  when I > install a different version mate in > my home, for example 1.26,  which one will be use when I enter my deskop by > slim? I don't know. I'm currently on a foreign

Re:Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

At 2022-02-27 18:58:37, "Maxime Devos" wrote: >tumashu schreef op zo 27-02-2022 om 18:52 [+0800]: >>    I want to include CAJA_EXTENSION_DIRS setup in ~/.guix- >> profile/etc/profile file, >> and the below code seem to do not work in glib-or-gtk-bu

Re:Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

works, thanks very much. -- 发自我的网易邮箱手机智能版 - Original Message - From: "Maxime Devos" To: tumashu , guix Sent: Sun, 27 Feb 2022 11:58:37 +0100 Subject: Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system tumashu schreef op zo 27-02-

Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

tumashu schreef op zo 27-02-2022 om 18:52 [+0800]: >    I want to include CAJA_EXTENSION_DIRS setup in ~/.guix- > profile/etc/profile file, > and the below code seem to do not work in glib-or-gtk-build-system The native-search-path will only have effect once there's actually a caja

native-search-paths search-path-specification do not work in glib-or-gtk-build-system

Hello: I want to include CAJA_EXTENSION_DIRS setup in ~/.guix-profile/etc/profile file, and the below code seem to do not work in glib-or-gtk-build-system (native-search-paths (list (search-path-specification (variable "CAJA_EXTENSION_DIRS") (f

Re: Gtk via the web

Hi, Danny Milosavljevic skribis: > You can use Gtk applications in the web using Broadway. That's why I enabled > Broadway in our gtk+ package a long time ago. > > Try it: > > broadwayd :1 & > GDK_BACKEND=broadway BROADWAY_DISPLAY=:1 gedit & > icecat http:

Re: Gtk via the web

On 11/2/20 5:24 AM, Danny Milosavljevic wrote: > You can use Gtk applications in the web using Broadway. That's why I enabled > Broadway in our gtk+ package a long time ago. I haven't seen a reference to Broadway in 30 years

Gtk via the web

directory/?origin_url=https://gitorious.org/guix-web/guix-web.git > > It’s an interesting approach with several advantages (in particular it > can be quickly developed), though I must say I remain unenthusiastic > about using web browsers for local GUIs. You can use Gtk applications i

Re: Why does slim-service-type depend on GTK+?

Patch sent: 41798. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: Why does slim-service-type depend on GTK+?

Thanks Mathieu, this helps a lot indeed! The slim service configuration depends on a generated startx, which depend on this X-wrapper: --8<---cut here---start->8--- (begin (setenv "XORG_DRI_DRIVER_PATH" (string-append

Re: Why does slim-service-type depend on GTK+?

--path /gnu/store/hh2z7mqlj54cs23a94afpxjgxfyda566-gtk+-3.24.14 /gnu/store/9pnnigbg2a173xxabfrb50mayw4la2ag-system /gnu/store/bjsss7lbxzddqmljhvjjfczz3nrkpl32-boot /gnu/store/zdfy15qp870amyi89irm4wrinmjfxgnw-shepherd.conf /gnu/store/9znzaszxk0h9z7c13a12c6g5h7445rqb-shepherd-xorg-serve

Why does slim-service-type depend on GTK+?

(vt "vt8"))) --8<---cut here---end--->8--- to bare-bones.tmpl, it drags GTK+ in the closure. Here is the slim-service-type definition: --8<---cut here---start->8--- (define slim-service-type (handle-xorg-configu

Re: Lightweight Emacs (or "GTK+ minimal)

Hi Pierre, On Mon, 8 Jun 2020 at 19:54, Pierre Neidhardt wrote: > > We could also make emacs-lucid the default compiler for Emacs packages: > GTK is never needed there as far as I know. AFAIK, 'emacs-mininal' is used by the Emacs build system. And I do not think this minimal pack

Re: Lightweight Emacs (or "GTK+ minimal)

We could also make emacs-lucid the default compiler for Emacs packages: GTK is never needed there as far as I know. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: Lightweight Emacs (or "GTK+ minimal)

Thanks for sharing! emacs-lucid closure size is 783.7 MiB. emacs is 1181.3 MiB. The difference really shines when building EXWM against emacs-lucid: it makes for a much lighter Guix System. Most Emacs packages don't have "emacs" in their closure. So if we add emacs-lucid, one of the few extra

Re: Lightweight Emacs (or "GTK+ minimal)

Leo Prikler writes: > Hello, Pierre > Hi, >> Also I wonder why guile is in there. > According to guix graph, guile is pulled by gnutls. > >> 1. Does anyone have a recipe for Emacs without GTK+ (that can also >>display pictures)? > Not directly, but you

Lightweight Emacs (or "GTK+ minimal)

Hello, Pierre > Also I wonder why guile is in there. According to guix graph, guile is pulled by gnutls. > 1. Does anyone have a recipe for Emacs without GTK+ (that can also >display pictures)? Not directly, but you could try building it with motif (package lesstif) or Lucid/Athena

Lightweight Emacs (or "GTK+ minimal)

Hi Guix! I'm working on reducing some package closures. Looking at Emacs, it drags: - llvm - mesa - guile - cups / ghostscript / hplip - wayland Turns out that it seems to be all because of GTK+ (to be confirmed). 1. Does anyone have a recipe for Emacs without GTK+ (that can also display

Meld: Leaky inputs? (from gi.repository import Gtk): Meld requires GTK+ 3.20 or higher.

Hi Guix, I've just pushed the Meld package, but now I'm noticing something strange: while it works well in a ./pre-inst-env environment, it fails to start on my out-of-date profile. Error message: --8<---cut here---start->8--- Meld requires GTK

Re: Lisp: Package cl-cffi-gtk

Hi, On Wed, 10 Oct 2018 15:16:33 +0200 Pierre Neidhardt wrote: > Alright, I've packaged it as you suggested. See the wip-nextbrowser > branch. If was slightly simpler as for Sly. > > That said, I wonder if this is not over-complicated. > Wouldn't it be easier to mimic Quicklisp there and

Re: Lisp: Package cl-cffi-gtk

Hi Pierre, On Tue, 09 Oct 2018 21:41:05 +0200 Pierre Neidhardt wrote: > Hi, > > I'm trying to package cl-cffi-gtk, which should not be so hard, except > that according to > > https://github.com/Ferada/cl-cffi-gtk/blob/master/INSTALL > > we need to push a

Lisp: Package cl-cffi-gtk

Hi, I'm trying to package cl-cffi-gtk, which should not be so hard, except that according to https://github.com/Ferada/cl-cffi-gtk/blob/master/INSTALL we need to push all .asd to asdf:*central-registry*. This should work, but I wonder how to do this properly with the current ASDF build

Re: [core-updates] webkitgtk-2.4 and webkitgtk/gtk+-2 no longer needed?

: Ricardo Wurmus <rek...@elephly.net> >>> Date: Thu Apr 12 20:37:54 2018 +0200 >>> >>> gnu: gnucash: Update to 3.0. >> >> This commit removes the last reference to 'webkitgtk/gtk+-2', which in >> turn contains the only reference to 'webkitg

Re: [core-updates] webkitgtk-2.4 and webkitgtk/gtk+-2 no longer needed?

pr 12 20:37:54 2018 +0200 >> >> gnu: gnucash: Update to 3.0. > > This commit removes the last reference to 'webkitgtk/gtk+-2', which in > turn contains the only reference to 'webkitgtk-2.4'. So, we could now > delete both of those packages from the 'core-updates' branch. &

[core-updates] webkitgtk-2.4 and webkitgtk/gtk+-2 no longer needed?

gnu: gnucash: Update to 3.0. This commit removes the last reference to 'webkitgtk/gtk+-2', which in turn contains the only reference to 'webkitgtk-2.4'. So, we could now delete both of those packages from the 'core-updates' branch. I would advocate removing them, since these old versions of webk

Re: More native-search-paths for gtk and

Hello, Hartmut Goebel skribis: > while checking the Nix patches for qtbase, I discovered that they have a > patch to extend XDG_DATA_DIRS and GIO_EXTRA_MODULES. > > They basically do this: > >  

More native-search-paths for gtk and

Hi, while checking the Nix patches for qtbase, I discovered that they have a patch to extend XDG_DATA_DIRS and GIO_EXTRA_MODULES. They basically do this:   XDG_DATA_DIRS=$XDG_DATA_DIRS:{gtk3}/share/gsettings-schemas/${gtk3.name}  

Re: XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

Hi, On Sun, 07 May 2017 17:35:46 -0700 Chris Marusich wrote: > Is this supposed to work "out of the box" on foreign distros? If you set the environment variables as documented yes - although some distros do weird things in their startup scripts if the environment variable

Re: XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

f the package or some of its dependencies (i.e. it has to be > available on the build side in the environment). > > I think we should just make desktop-file-utils a propagated-input of gtk. > > (In fact, even gio (part of glib) already supports desktop files: > https://developer.gnome.

XDG standard desktop entries - desktop-file-utils and gtk, and KDE: mechanism of desktop database generation in profiles

ktop-file-utils a propagated-input of gtk. (In fact, even gio (part of glib) already supports desktop files: https://developer.gnome.org/gio/stable/gio-Desktop-file-based-GAppInfo.html . However, there are lots of non-GUI programs using glib. For example, desktop-file-utils uses glib) Dis

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

iyzs...@member.fsf.org (宋文武) writes: > "Huang, Ying" <huang_ying_cari...@163.com> writes: > >> Hi, Wenwu, >> >> iyzs...@member.fsf.org (宋文武) writes: >> >>> "Huang, Ying" <huang_ying_cari...@163.com> writes: >>&g

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

"Huang, Ying" <huang_ying_cari...@163.com> writes: > Hi, Wenwu, > > iyzs...@member.fsf.org (宋文武) writes: > >> "Huang, Ying" <huang_ying_cari...@163.com> writes: >> >>> [...] >>>> - #$(if gtk+ (bu

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

Hi, Wenwu, iyzs...@member.fsf.org (宋文武) writes: > "Huang, Ying" <huang_ying_cari...@163.com> writes: > >> [...] >>> - #$(if gtk+ (build gtk+ "3.0.0") #t) >>> -#$(if gtk+-2 (build gt

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

"Huang, Ying" <huang_ying_cari...@163.com> writes: > [...] >> - #$(if gtk+ (build gtk+ "3.0.0") #t) >> - #$(if gtk+-2 (build gtk+-2 "2.10.0") #t >> +

Re: [PATCH -v2] Fix gtk-im-modules for Gtk+3

Hi, Ricardo, Ricardo Wurmus <rek...@elephly.net> writes: > huang_ying_cari...@163.com writes: > >> From: Huang Ying <huang.ying.cari...@gmail.com> >> >> Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be >> find >> in bi

Re: [PATCH -v2] Fix gtk-im-modules for Gtk+3

huang_ying_cari...@163.com writes: > From: Huang Ying <huang.ying.cari...@gmail.com> > > Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find > in bin output. Ah, I was wondering why this broke! Thanks for investigating it. > The fix works, but a

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

Hi, Wenwu, Thanks for comments. iyzs...@member.fsf.org (宋文武) writes: > huang_ying_cari...@163.com writes: > >> From: "Huang, Ying" <huang.ying.cari...@gmail.com> >> >> Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be &g

Re: [PATCH -v3] Fix gtk-im-modules for gtk+3

huang_ying_cari...@163.com writes: > From: "Huang, Ying" <huang.ying.cari...@gmail.com> > > Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find > in output "bin" instead of "out". > > * guix/profiles.scm (m

[PATCH -v3] Fix gtk-im-modules for gtk+3

From: "Huang, Ying" <huang.ying.cari...@gmail.com> Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find in output "bin" instead of "out". * guix/profiles.scm (manifest-lookup-package): New argument output to select package or stor

Re: [PATCH -v2] Fix gtk-im-modules for Gtk+3

Hi, Danny, Thanks for comments! Danny Milosavljevic writes: > Hi, > > On Mon, 30 Jan 2017 11:06:49 +0800 > huang_ying_cari...@163.com wrote: > >> -(define* (manifest-lookup-package manifest name #:optional version) >> +(define* (manifest-lookup-package manifest name

Re: [PATCH -v2] Fix gtk-im-modules for Gtk+3

Hi, On Mon, 30 Jan 2017 11:06:49 +0800 huang_ying_cari...@163.com wrote: > -(define* (manifest-lookup-package manifest name #:optional version) > +(define* (manifest-lookup-package manifest name #:optional version output) >"Return as a monadic value the first package or store path referenced

Re: [PATCH -v2] Fix gtk-im-modules for Gtk+3

Hi, All, huang_ying_cari...@163.com writes: > From: Huang Ying <huang.ying.cari...@gmail.com> > > Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find > in bin output. > > The fix works, but appears hacky, because I haven't read much guix source

[PATCH -v2] Fix gtk-im-modules for Gtk+3

From: Huang Ying <huang.ying.cari...@gmail.com> Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find in bin output. The fix works, but appears hacky, because I haven't read much guix source code, so I don't know the best solution. Signed-off-by: "

[PATCH] Fix gtk-im-modules for Gtk+3

From: Huang Ying <huang.ying.cari...@gmail.com> Gtk+3 now have multiple outputs, so the gtk-query-immodules-3.0 should be find in bin output. The fix works, but appears hacky, because I haven't read much guix source code, so I don't know the best solution. Signed-off-by: "

Re: [PATCH core-updates] gnu: gtk+: Enable broadway backend.

Hi Danny, Danny Milosavljevic <dan...@scratchpost.org> writes: > * gnu/packages/gtk.scm (gtk+)[arguments]: Modify configure-flags. > --- > gnu/packages/gtk.scm | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/gtk.scm b/gnu/

[PATCH core-updates] gnu: gtk+: Enable broadway backend.

* gnu/packages/gtk.scm (gtk+)[arguments]: Modify configure-flags. --- gnu/packages/gtk.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm index a506949ab..9498ce780 100644 --- a/gnu/packages/gtk.scm +++ b/gnu/packages/gtk.scm

Re: [PATCH] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

Chris Marusich <cmmarus...@gmail.com> skribis: > Christopher Baines <m...@cbaines.net> writes: > >> * gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build >> system to the glib-or-gtk build system, to fix missing gobject >> introspection

Re: [PATCH 1/4] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

Hello! I pushed all 4 patches with slightly adjusted commit logs (please take a look :-)). Thank you, and sorry for the delay! Ludo’.

Re: [PATCH] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

Christopher Baines <m...@cbaines.net> writes: > * gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build > system to the glib-or-gtk build system, to fix missing gobject > introspection namespaces. > --- > gnu/packages/gnome.scm | 4 ++-- > 1 file cha

[PATCH 1/4] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

* gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build system to the glib-or-gtk build system, to fix missing gobject introspection namespaces. --- gnu/packages/gnome.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages

Re: [PATCH] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

On 29/12/16 18:05, Ludovic Courtès wrote: > Hi! > > Christopher Baines <m...@cbaines.net> skribis: > >> * gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build >> system to the glib-or-gtk build system, to fix missing gobject >> introspection

Re: [PATCH] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

Hi! Christopher Baines <m...@cbaines.net> skribis: > * gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build > system to the glib-or-gtk build system, to fix missing gobject > introspection namespaces. Using ‘glib-or-gtk-build-system’ sounds right here, but with th

[PATCH] gnu: gnome-tweak-tool: Use glib-or-gtk-build-system

* gnu/packages/gnome.scm (gnome-tweak-tool): Switch from the gnu build system to the glib-or-gtk build system, to fix missing gobject introspection namespaces. --- gnu/packages/gnome.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages

Re: gtk-doc build failure

Am 01.12.2016 um 23:51 schrieb Marius Bakke: > I've committed a workaround in 3cc0342b45406f97d675266cc9ac7877be855122. > […] > -package_base = > r"gnu/store/k6211w9hlqyxvzhrsmh2a113rnzdqlkc-dblatex-0.3.5/share/dblatex" > +package_base = >

Re: gtk-doc build failure

Marius Bakke <mba...@fastmail.com> writes: > gtk-doc is not building in current 'master'. It seems to stem from > python-build-system merge. I've committed a workaround in 3cc0342b45406f97d675266cc9ac7877be855122. There is a bug in the 'dblatex' setup.py manifesting when using th

gtk-doc build failure

Hi, gtk-doc is not building in current 'master'. It seems to stem from python-build-system merge. I ran a bisect but had to skip a bunch of commits due to subversion build failure. To save anyone else the trouble, here is the result: There are only 'skip'ped commits left to test. The first bad

Re: [PATCH 2/2] profiles: Build GTK+ input module cache.

rmus <rek...@elephly.net> skribis: > >> * guix/profiles.scm (gtk-im-modules): New procedure. >> (%default-profile-hooks): Add it. > > Very nice! > >> +(define (gtk-im-modules manifest) >> + "Return a derivation that builds the cache files for

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

ep 17 00:00:00 2001 >> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@gmail.com> >> Date: Fri, 14 Oct 2016 22:57:53 +0800 >> Subject: [PATCH] gnu: gtk+: Move desktop files into "bin" output. >> >> * gnu/packages/gtk.scm (gtk+)[arguments]: Add 'move-desktop-files' phase. > > Thanks, this works for me! With this patch, `guix system build` passed > the point where it previously failed. Pushed, thanks!

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

> > > > That should work. You can post the patch here so we can test, if you > > want. > > Sure, here is it: > > From 4746292d8a672dbc3ea8d058baf6239974d92103 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@gmail.com> >

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

On Fri, Oct 14, 2016 at 11:03:59PM +0800, ? wrote: >> [...] >> Move all the 3 desktop files into 'bin' output should work. (I could >> patch that next day, but won't be able to test it due to slow >> substitute/download/build speed though.) > > That

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

st, if you > want. Sure, here is it: >From 4746292d8a672dbc3ea8d058baf6239974d92103 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzs...@gmail.com> Date: Fri, 14 Oct 2016 22:57:53 +0800 Subject: [PATCH] gnu: gtk+: Move desktop files into "bin" output. * gnu/p

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

Leo Famulari <l...@famulari.name> skribis: > On Thu, Oct 13, 2016 at 01:24:47AM -0400, Leo Famulari wrote: >> It works if I remove the 'bin' output from gtk+@3. > > I think I was mistaken. If I don't use a separate 'bin' output, I can > build the package, but I still

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

iyzs...@member.fsf.org (宋文武) skribis: > Leo Famulari <l...@famulari.name> writes: > >> On core-updates, from 6671ce93 (gnu: ath9k-htc-firmware: Update binutils >> patch for binutils 2.27), I can't build gtk+@3.20 because the daemon >> finds a cycle in the refere

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

Leo Famulari <l...@famulari.name> writes: > On core-updates, from 6671ce93 (gnu: ath9k-htc-firmware: Update binutils > patch for binutils 2.27), I can't build gtk+@3.20 because the daemon > finds a cycle in the references: > > -- > starting phase `validate-runpath' &g

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

On Thu, Oct 13, 2016 at 01:24:47AM -0400, Leo Famulari wrote: > It works if I remove the 'bin' output from gtk+@3. I think I was mistaken. If I don't use a separate 'bin' output, I can build the package, but I still get an error with `guix system build`: guix system: error: reference to inva

[core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

On core-updates, from 6671ce93 (gnu: ath9k-htc-firmware: Update binutils patch for binutils 2.27), I can't build gtk+@3.20 because the daemon finds a cycle in the references: -- starting phase `validate-runpath' validating RUNPATH of 17 binaries in "/gnu/

Re: [PATCH 2/2] profiles: Build GTK+ input module cache.

Ricardo Wurmus <rek...@elephly.net> skribis: > * guix/profiles.scm (gtk-im-modules): New procedure. > (%default-profile-hooks): Add it. Very nice! > +(define (gtk-im-modules manifest) > + "Return a derivation that builds the cache files for input method modules >

Re: [PATCH 2/2] profiles: Build GTK+ input module cache.

宋文武 <iyzs...@member.fsf.org> writes: > Ricardo Wurmus <rek...@elephly.net> writes: > >> * guix/profiles.scm (gtk-im-modules): New procedure. >> (%default-profile-hooks): Add it. >> --- >> guix/profiles.scm | 63 >> ++

[PATCH 2/2] profiles: Build GTK+ input module cache.

* guix/profiles.scm (gtk-im-modules): New procedure. (%default-profile-hooks): Add it. --- guix/profiles.scm | 63 +++ 1 file changed, 63 insertions(+) diff --git a/guix/profiles.scm b/guix/profiles.scm index 78deeb7..1a522ae 100644 --- a/guix

Re: [PATCH 2/2] gnu: gnunet-gtk: Add gsettings-desktop-schemas to inputs.

Ricardo Wurmus <rek...@elephly.net> writes: > ng0 <n...@we.make.ritual.n0.is> writes: > >> * gnu/packages/gnunet.scm (gnunet-gtk)[inputs]: Add >> gsettings-desktop-schemas. >> --- >> gnu/packages/gnunet.scm | 1 + >> 1 file changed, 1 insertion

Re: [PATCH 2/2] gnu: gnunet-gtk: Add gsettings-desktop-schemas to inputs.

ng0 <n...@we.make.ritual.n0.is> writes: > * gnu/packages/gnunet.scm (gnunet-gtk)[inputs]: Add gsettings-desktop-schemas. > --- > gnu/packages/gnunet.scm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm > in

[PATCH 2/2] gnu: gnunet-gtk: Add gsettings-desktop-schemas to inputs.

* gnu/packages/gnunet.scm (gnunet-gtk)[inputs]: Add gsettings-desktop-schemas. --- gnu/packages/gnunet.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index e4fd95e..a75d1ad 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages

Re: bug#24188: gnucash needs gtk+ in propagated-inputs

Arun Isaac skribis: >>> To actually fix this package (and some others) we can: >>> >>> - Wrap them with shared-mime-info in XDG_DATA_DIRS or propagated it. >>> >>> - Make sure 'xdg-mime-database' always run if glib applications are >>> there even without

Re: bug#24188: gnucash needs gtk+ in propagated-inputs

>> To actually fix this package (and some others) we can: >> >> - Wrap them with shared-mime-info in XDG_DATA_DIRS or propagated it. >> >> - Make sure 'xdg-mime-database' always run if glib applications are >> there even without shared-mime-info referenced by profile. >> IIRC, this was

Re: bug#24188: gnucash needs gtk+ in propagated-inputs

iyzs...@member.fsf.org (宋文武) skribis: > Arun Isaac <arunis...@systemreboot.net> writes: > >>> The following environment variables are set which may make a difference >>> here: >>> >>> GUIX_GTK3_PATH=/run/current-system/profile/lib/gtk-3.0 >>

Re: [PATCH] gnu: gtk: Add clipit.

doncatnip writes: > Hey Guix, > > This patch adds ClipIt (clipit) to the repository. Tested with lint, > build rounds=2 and actual usability. Thanks for the patch! I applied it with modifications of: - use a release tarball and remove the autogen phase. - adjust the

[PATCH] gnu: gtk: Add clipit.

Hey Guix, This patch adds ClipIt (clipit) to the repository. Tested with lint, build rounds=2 and actual usability.>From 82051a27d1ca6131ad6295fad95e0bc19cc22bfa Mon Sep 17 00:00:00 2001 From: doncatnip <gno...@gmail.com> Date: Thu, 1 Sep 2016 03:15:01 +0200 Subject: [PATCH] gnu: gtk: A

Re: [PATCH 1/5] gnu: gtk+: Add "bin" output.

宋文武 <iyzs...@gmail.com> skribis: > * gnu/packages/gtk.scm (gtk+)[outputs]: New field. > --- > gnu/packages/gtk.scm | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm > index 21365b9..5c42053 100644 > --- a/gn

Re: [PATCH] gnunet-svn, gnunet-gtk-svn

Hi, Catonano writes: > 2016-08-20 14:04 GMT+02:00 ng0 > > > >> Reported at https://gnunet.org/bugs/view.php?id=4619 >> >> > Christian Grothoff replied that he would like you to extract a stacktrace > from a core dump. > > Did you notice ? > > I

Re: [PATCH] gnunet-svn, gnunet-gtk-svn

2016-08-20 14:04 GMT+02:00 ng0 > Reported at https://gnunet.org/bugs/view.php?id=4619 > > Christian Grothoff replied that he would like you to extract a stacktrace from a core dump. Did you notice ? I would attempt that myself but admittedly I don't know how to

  1   2   3   4   >