From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 27 00:35:48 2020 Received: (at 43198) by debbugs.gnu.org; 27 Oct 2020 04:35:48 +0000 Received: from localhost ([127.0.0.1]:42348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXGi3-00059u-JF for submit@debbugs.gnu.org; Tue, 27 Oct 2020 00:35:48 -0400 Received: from mail-pl1-f182.google.com ([209.85.214.182]:33703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXGi0-00059e-UR for 43198@debbugs.gnu.org; Tue, 27 Oct 2020 00:35:46 -0400 Received: by mail-pl1-f182.google.com with SMTP id b19so116477pld.0 for <43198@debbugs.gnu.org>; Mon, 26 Oct 2020 21:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZRXLPI8PeAcShGfTGurXMxPT1QcaUJWbKe4257JNrUg=; b=WX2Kn/sZ0mvS17cNgQDHZX3S36rYY9d4jdBuhOpPnc+sd0u5+s3XxKptq+85XBV3gT ORBQMuYpax1EyXYrcue2Nh9TRZEFekjncbQW9iZ++QWvW3XYdhhMzYF3A7aLLUih7e62 4VIXhu6mDBh1bnmuC6LUAAY7FcLZNUajB4IOv9XgSZyXv399lztrOQxZIh4+rXQvEchC 3Xatv4cz4Mh82z4DRFSP3fAK6optDWgLwwFjqrlguIelOANwJbMsKzOigJfbH0zuu6Hw L5XkWIUk4uiGYOVQewLOc0xub6ke0n7gjU52YACH0wWqhAQ9W6ONvxpKIrd0WI7zx9wb XzhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZRXLPI8PeAcShGfTGurXMxPT1QcaUJWbKe4257JNrUg=; b=G6c1TPqgo3r3lyxOEUVK0k4h4KZ71k2/4Jaeati+hd3UGtUDrLfE2PReDgSyqsYRmC 5cMT5P5YshUBA7mFuXaR+Y2fU2h5uRMP6BrdZmpq+jIRrz8H+8EU5bVbncb5mY0FPltp rZXxfok7bDTMFP6t3nZeAKctecXOyYfJfk2qN2LHLCb+C2fxsQDgl67LnBQ4S5QopEkH xClZRK+66IH46jFGnegXg8Hrmb6MSND3/56g/BGzUYSsWO3BpIuccwW0cH63ZWDv4kMr DgHUuZCNksSLcArFMqMIeFJTlAvBgB2G3FH5Fh6Uy2P9nhmpZP5pPPU7UeUQDjz5RqlL 8ayA== X-Gm-Message-State: AOAM532BgM1VuDmZ+5WJkhaFoKvCXBZs2cAMvOFF9C87prhfy1/K180B HZGE/p5+8qZJIi2Gh8Xlc+sEuHYvLtMzgzyqufnjL8PS1GwlMQ== X-Google-Smtp-Source: ABdhPJx3vKnm8gBI7JBwBwLbi+qspHwu2Z6VIglgO4WKq9XQZbojh8QD3LG0D8mAGjQxiUH2PNn2I1nAiQG/BrkByJI= X-Received: by 2002:a17:90b:fce:: with SMTP id gd14mr282849pjb.219.1603773338861; Mon, 26 Oct 2020 21:35:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Prafulla Giri Date: Tue, 27 Oct 2020 10:20:27 +0545 Message-ID: Subject: Re: Questions about "Add breeze icon assets" To: Hartmut Goebel Content-Type: multipart/alternative; boundary="00000000000029c34b05b29f943c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 43198 Cc: 43198@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000029c34b05b29f943c Content-Type: text/plain; charset="UTF-8" Hello Mr. Goebel, To be really honest, I do not know much about KDE and all. I am just some random guy who knows a little bit of guix/guile/scheme/gnu/linux, and I just wanted to use Kdenlive, and really wanted a dark theme. ( https://issues.guix.gnu.org/43200) I looked for the breeze icon theme in guix and found that we only had the breeze-icons package, and not the entire breeze theme, and adding that to kdenlive's dependencies did not supply the breeze theme in it's entirety. I looked around for a solution and bumped into this: https://github.com/KDE/breeze-icons and this: https://github.com/KDE/breeze Seeing these two repos led me to conclude that the breeze-icons package merely supplied the icons, whereas the breeze repository held the entire breeze theme: what I was looking for in order to make the theme available in Kdenlive (this was the end goal). So, I decided to package the contents of the breeze repo ( https://github.com/KDE/breeze) into a package, and (reluctantly) decided to call it breeze-assets. The reason that I inherited breeze-icons for this was because I thought that since they were both "basically the same" thing, or rather, parts of the same theme, they must share their dependencies. And I thought that since I don't know much about KDE, and setting up it's build environment, I started my packaging with: `guix environment breeze-icons && cd breeze # the breeze repo clone` and then went on adding more and more missing dependencies. Hence, the inheritance. So, it is not a well thought out decision on my part, but rather just what I started the whole thing with. I understand that this might be causing breeze-assets to have as inputs things that it does not require at all. Once that was done, I tried adding breeze-icons and breeze-assets as dependencies for KdenLive but that was still not working correctly. At run time, some parts of the breeze theme were missing because the icons that should have been available in the Breeze Theme were not available as they were in separate /gnu/store/xxx-package directories. In order to resolve this issue, I had two choices: I could either declare breeze-assets and breeze-icons as propagated-inputs of kdenlive, or I could declare a union-build of breeze-assets and breeze-icons as a union build in the inputs of kdenlive itself. Being a (wannabe) guix/functional-package-management purist, I chose to go the second route. But then, I thought that perhaps other packages would also benefit from having the union of breeze-icons and breeze-assets readily available to just include in their input list. Hence, I added the union package: `breeze`. And with that added as an input for Kdenlive, and the runtime variable XDG_DATA_DIRS pointing to /gnu/store/xxx-breeze/share during runtime, kdenlive has the breeze theme available (Commit: e33a1e546a52aa70ffe0c8389f29ff3288cc4510). Now, I can see that my solution is inelegant. And I should have not mixed two different things together. But because of my lack of knowledge regarding the matter, and my end goal of getting kdenlive's breeze theme working, it appears that I've implemented a kludge. Please do go ahead and make the corrective changes. I have one request, however: that you please retain the union build of breeze-assets and breeze-icon as it makes it easier to get the entire theme without creating union-builds in every single package's input list. If that is acceptable to you (to keep the union build `breeze` package) - and please do correct me if I am wrong - am I correct in thinking that this must be a matter of only cleaning `breeze-assets` up (removing the inheritance, perhaps moving the package to another file altogether (kde-plasma.scm, perhaps) ? If you do not have the time, and want me to clean this up, please do give me the instructions and I will be happy to make the necessary changes. Again, please forgive me for the inconvenience caused. On Tue, Oct 27, 2020 at 12:52 AM Hartmut Goebel < h.goebel@crazy-compilers.com> wrote: > Hi Prafulla, > > sorry, I'm late for the show and this is already merged. I packages quite > a lot KDE packages and also made several attempts to make plasma-desktop > run on guix. > > I'm curious about breeze-artwork and breeze and have some questions: > > 1. What is the reason you broke up breeze into breeze-assets and > breeze? What is the use of having a package "breeze-assets"? > > I'm asking since in guix we typically do not split up packages this way, > but are using different "outputs". > > > 1. What is the reason you inherit breeze(-artwork) from breeze-icons? > > I'm asking since > > a) breeze-icons are part of KDE Frameworks, whereas breeze is part of KDE > Plasma. So I expect these to be somewhat independent of each other, as one > can see by quite different version numbers. > > b) While breeze-assets inherits breeze-icons, it overwrites all > information inherited from except of the build-system and some inputs. Even > the version is different. > > > 1. What is the reason for breeze becoming unified with breeze-icons? > > I'm asking since, as explained above, I'd expect these to be somewhat > independent of each other. (breeze of course requires breeze-icons). > > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goebel@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > > --00000000000029c34b05b29f943c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mr. Goebel,

To be real= ly honest, I do not know much about KDE and all. I am just some random guy = who knows a little bit of guix/guile/scheme/gnu/linux, and I just wanted to= use Kdenlive, and really wanted a dark theme. (https://issues.guix.gnu.org/43200)

I looked for the breeze icon theme in guix and found that we only h= ad the breeze-icons package, and not the entire breeze theme, and adding th= at to kdenlive's dependencies did not supply the breeze theme in it'= ;s entirety. I looked around for a solution and bumped into this: https://github.com/KDE/breeze-icon= s and this: https://github.co= m/KDE/breeze

Seeing these two repos led me to = conclude that the breeze-icons package merely supplied the icons, whereas t= he breeze repository held the entire breeze theme: what I was looking for i= n order to make the theme available in Kdenlive (this was the end goal).

So, I decided to package the contents of the breeze = repo (https://github.com/KDE/bree= ze) into a package, and (reluctantly) decided to call it breeze-assets.= The reason that I inherited breeze-icons for this was because I thought th= at since they were both "basically the same" thing, or rather, pa= rts of the same theme, they must share their dependencies. And I thought th= at since I don't know much about KDE, and setting up it's build env= ironment, I started my packaging with: `guix environment breeze-icons &= & cd breeze # the breeze repo clone` and then went on adding more and m= ore missing dependencies. Hence, the inheritance. So, it is not a well thou= ght out decision on my part, but rather just what I started the whole thing= with. I understand that this might be causing breeze-assets to have as inp= uts things that it does not require at all.

Once t= hat was done, I tried adding breeze-icons and breeze-assets as dependencies= for KdenLive but that was still not working correctly. At run time, some p= arts of the breeze theme were missing because the icons that should have be= en available in the Breeze Theme were not available as they were in separat= e /gnu/store/xxx-package directories. In order to resolve this issue, I had= two choices: I could either declare breeze-assets and breeze-icons as prop= agated-inputs of kdenlive, or I could declare a union-build of breeze-asset= s and breeze-icons as a union build in the inputs of kdenlive itself. Being= a (wannabe) guix/functional-package-management purist, I chose to go the s= econd route. But then, I thought that perhaps other packages would also ben= efit from having the union of breeze-icons and breeze-assets readily availa= ble to just include in their input list. Hence, I added the union package: = `breeze`. And with that added as an input for Kdenlive, and the runtime var= iable XDG_DATA_DIRS pointing to /gnu/store/xxx-breeze/share during runtime,= kdenlive has the breeze theme available (Commit: e33a1e546a52aa70ffe0c8389= f29ff3288cc4510).

Now, I can see that my solution = is inelegant. And I should have not mixed two different things together. Bu= t because of my lack of knowledge regarding the matter, and my end goal of = getting kdenlive's breeze theme working, it appears that I've imple= mented a kludge. Please do go ahead and make the corrective changes.

I have one request, however: that you please retain = the union build of breeze-assets and breeze-icon as it makes it easier to g= et the entire theme without creating union-builds in every single package&#= 39;s input list. If that is acceptable to you (to keep the union build `bre= eze` package) - and please do correct me if I am wrong - am I correct in th= inking that this must be a matter of only cleaning `breeze-assets` up (remo= ving the inheritance, perhaps moving the package to another file altogether= (kde-plasma.scm, perhaps) ?

If you do not have th= e time, and want me to clean this up, please do give me the instructions an= d I will be happy to make the necessary changes.

A= gain, please forgive me for the inconvenience caused.

On Tue, Oct = 27, 2020 at 12:52 AM Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:
=20 =20 =20

Hi Prafulla,

sorry, I'm late for the show and this is already merged. I packages quite a lot KDE packages and also made several attempts to make plasma-desktop run on guix.

I'm curious about breeze-artwork and breeze and have some questions:

  1. What is the reason you broke up breeze into breeze-assets and breeze? What is the use of having a package "breeze-assets&quo= t;?

I'm asking since in guix we typically do not split up packages this way, but are using different "outputs".

  1. What is the reason you inherit breeze(-artwork) from breeze-icons?

I'm asking since

a) breeze-icons are part of KDE Frameworks, whereas breeze is part of KDE Plasma. So I expect these to be somewhat independent of each other, as one can see by quite different version numbers.

b) While breeze-assets inherits breeze-icons, it overwrites all information inherited from except of the build-system and some inputs. Even the version is different.

  1. What is the reason for breeze becoming unified with breeze-icons?

I'm asking since, as explained above, I'd expect these to = be somewhat independent of each other. (breeze of course requires breeze-icons).


--=20
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-co=
mpilers.com | compilers which you thought are impossible |
--00000000000029c34b05b29f943c--