Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland

2024-04-15 Thread Alan M Varghese

Control: tags -1 - moreinfo


Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not << 0.2
as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends} (which
will be emoty anyway).

Done and done.

Alan M Varghese (NyxTrail)



Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

2024-04-15 Thread Alan M Varghese

Control: tags -1 - moreinfo

> This FTBFS: "! LaTeX Error: File `lmodern.sty' not found."

> Also I think the additional notes in the changelog entry belong in > 
README.Debian or README.source.

Done and done.


Alan M Varghese (NyxTrail)



Bug#1066876: RFS: hyprland/0.36.0+ds-1 [ITP] -- Dynamic tiling Wayland compositor

2024-04-15 Thread Alan M Varghese

Updated to newer upstream version 0.38.1



Bug#1069058: RFS: libhyprcursor/0.1.7-1 [ITP] -- hyprland cursor format, library and utilities (headers)

2024-04-15 Thread Alan M Varghese

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libhyprcursor":

 * Package name : libhyprcursor
   Version  : 0.1.7-1
   Upstream contact : https://github.com/hyprwm/hyprcursor/issues
 * URL  : https://github.com/hyprwm/hyprcursor
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprcursor
   Section  : x11

The source builds the following binary packages:

  hyprcursor-util - Utility to manipulate hyprcusor and xcursor themes
  libhyprcursor0 - hyprland cursor format, library and utilities
  libhyprcursor-dev - hyprland cursor format, library and utilities (headers)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libhyprcursor/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprcursor/libhyprcursor_0.1.7-1.dsc

Changes for the initial release:

 libhyprcursor (0.1.7-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1067116

Regards,
--
  Alan M Varghese



Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA

2024-04-15 Thread Alan M Varghese

|Control: |tags -1 - moreinfo

> The package FTBFS: /bin/bash: line 1: /usr/bin/python3: No such file or 
directory

Fixed by adding python3 build-dep

>  Also, debian/watch is empty but present

Added comments about why it is not filled in:

# Upstream has not published a new version in ~10+ years and
# there is no active development.
# There is no meaningful way to configure uscan at the moment. > 
__AUTO_PERMISSIVE__ and __UNKNOWN__ in debian/copyright.
These were for m4/* and INSTALL files. Removed them.

Additionally, I also changed the version to 0+20221013 instead of
0~20221013.

Thanks,
Alan M Varghese (NyxTrail)



Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

2024-04-14 Thread Alan M Varghese

> This FTBFS: "! LaTeX Error: File `lmodern.sty' not found."

lmodern.sty comes from the package `lmodern`. This package should be

installed (as a transitive dep) when 'texlive-fonts-extra' is installed.


What is the process for installing build-deps? When I run

`apt install texlive-fonts-extra`, the lmodern package also

gets installed.



Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

2024-04-14 Thread Alan M Varghese

> But this also means you haven't tried building your package


in a minimal sid chroot

I have been using podman containers based on sid instead. But, I think that
should be fine?

> Manually on a host system? `apt build-dep` or `mk-build-deps -ir`

> Recommends are not installed when installing build-deps

Ah... Makes sense. Thank you. I missed these commands somehow; I have

been running the `apt install` command for getting the dependencies inside

the container.


I will update the package with lmodern also added as a dependency.



Bug#1066871: Fwd: Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

2024-04-19 Thread Alan M Varghese

Hello Mo,


Thank you for granting me access.


I believe this would require me to force push from local repo? Wouldn't this 
result

in the loss of your own commit history?


Or we could merge the two from a different branch. But that feels like too much

work :p


If you feel it is worth it to push from my repo, please feel free to do so.

Or, I am also okay with it if you just keep what you have done there

and we can iterate on top of it without pushing from my repo (from a cursory 
look,

we just need to bring in latest upstream version, add a watch file etc).


PS: Are you active on IRC? I am usually active daytime, Indian Standard Time.

What are your preferred timings?

On 17/04/24 20:39, Mo Zhou wrote:

Hi Alan,

I granted you with the maintainer access to this repo:
https://salsa.debian.org/debian/hyprlang

This package has cleared the NEW queue a while ago:
https://tracker.debian.org/pkg/hyprlang

Could you please push your changes from personal repo
to the above repo? I can also do it for you if you don't
mind not being the git committer.

I agree with splitting these packages for the long run.
Will create repos for other packages and invite you as well.
Does it sound good to you? Repos under the public debian/
namespace allows other people to help without much permission
issues.

On 3/14/24 16:36, Alan M Varghese wrote:

Hello Mo,

May I address you Mo?

I am happy to co-maintain hyprland with you. :)

The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I understand, the Debian policy recommends de-vendoring
over including files from other sources.

I have been working on this for a while and just uploaded them all
to mentors and created RFS for them. Currently I have completed
packaging hyprland and all its dependencies to the best of my ability.

Regarding the points you shared:
1. I wasn't sure what to do with tracy. I have however de-vendored
it and created an RFS for it[1]. But, I am unable to get the GPU
traces working on my AMD RX 6600 (for a debug build of Hyprland with
tracy enabled). I am not sure if this is because of my device or
something else. I have seen some discussion upstream that tracy's
GPU traces are not always reliable.

    Tracy seems to work fine, otherwise.

2. I have de-vendored udis86 too. The library and the included CLI
seems to run fine. Here is the RFS[2].

3. Again, I have separated hyprland-protocols and the RFS is here[3].

You can find the VCS for all hyprland related stuff I did, under the
NyxTrail namespace in salsa[4].

The packages all seem to run fine so far.

This is my first time packaging for Debian and any feedback is
welcome.

Let me know how you wish to proceed.

Regards,
Alan

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868
[4] https://salsa.debian.org/NyxTrail

On 3/15/24 01:10, Mo Zhou wrote:

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
     the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
     Maybe we can keep it embedded as udis86 is only needed by
     hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
     to keep this specific project, instead of splitting the
     package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libhyprlang":

   * Package name : libhyprlang
     Version  : 0.5.0-1
     Upstream contact : vaxerski 
   * URL  : https://github.com/hyprwm/hyprlang
   * License  : LGPL-3+
   * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
     Section  : x11

The source builds the following binary packages:

    libhyprlang2 - Configuration language for Hyprland (library)
    libhyprlang-dev - Configuration language for Hyprland (development files)

To access further information about this package, please visit the following 
URL:

    https://mentors.debian.net/package/libhyprlang/

Alternativel

Re: FWD: Copyright in LGPL projects

2024-03-05 Thread Alan M Varghese

Soren,


 ... but it is also perfectly fine to ship them in the same file.

I think what Wookey is referring to is that GPL and LGPL licenses contain
a line that says something like:
'Copyright (C) 1991, 1999 Free Software Foundation, Inc.'
I believe this copyright refers to the text of the license itself. Hence, it
might not be a good idea to include a second copyright in this same file.

So, including the copyright and license in the same file can work for licenses
like MIT, BSD etc which does not mention a copyright of its own, and not
for GPL-like licenses which includes a copyright line as part of the license.

Anyways, upstream author has added a new file called "COPYRIGHT" in the root
of the project[1] that mentions the copyright years, owner and the license used.
Based on all our discussion so far, I understand this should be acceptable
for our purposes in Debian.

[1] https://github.com/hyprwm/hyprlang/blob/main/COPYRIGHT

Alan

On 3/6/24 02:19, Soren Stoutner wrote:

Wookey,

On Tuesday, March 5, 2024 2:51:10 AM MST Wookey wrote:

On 2024-03-04 11:19 -0700, Soren Stoutner wrote:

Alan,

These are good questions.

1.  Yes, there must be a copyright statement.  Only the person, people,
group, or organization that holds the copyright can issue a license for
other people to use the work.  So, you must have someone claiming a
copyright or they do not have the legal ability to release the work to
others under the LGPL.

But what requires that to be in the source tarball? Copyright is
intrinsic in the authors, it doesn't require a statement to create
it. Said authors _do_ need to specify a licence (and the LGPL requires
that licence text to be shipped in the source (I think, although I
could only actually find this requirement for a 'Combined work' and in
the FAQ just now)).

_Debian_ requires a copyright statement (in the copyright file) so we
do need to find out from the project what to put, and a statement in
the source would be a good way to communicate that, but a notice on
the project website or even an email from a representative would also
do the job.


That is correct.  There must be a copyright statement or the license
information is not legally valid (because only someone who claims copyright
can issue a license).  However, it doesn’t expressly need to be in the tarball
(see below).  That part is simply best practice, because it maintain the
copyright information if the project is forked or upstream disappears, which
otherwise can be difficult to determine if it was only on a website that is now
defunct or in an email sent to a Debian developer who is no longer
participating in the project.

So, there is a distinction between what is the minimum legal requirement and
what is best practice.


My recommendation would be that you communicate to the upstream project

that

they need to include the copyright and licensing information in the root

of

their repository, preferably all in one file, as a minimum requirement for
you to be willing to package their project in Debian.


I don't think this is correct. And we should be happy to package
anything which is actually free software. We don't get to impose extra
requirements before we will package something.


As pointed out above, there is a distinction between what is the minimum
requirement for packaging in Debian and best practice.  I carefully worded
point 2 in my original email to state that, if **I** were packaging this
software, I would communicate with upstream that if they wanted **me** to
package their software in Debian, my minimum requirement would be that they
explicitly state the copyright information in the source code.  Originally I
had a point 3, which I deleted before sending the email, explaining that my
personal preference for when I would be willing to package software is higher
than Debian’s requirement, and that a website notation or email communication
of copyright has been used in some packages in the past, but with the downside
described above.  I took out point 3 because I felt it muddied the waters, but
since the point has been brought up, it is worth discussing.


They should put a copy of the LGPL in (in a file called 'COPYING' or
'LICENCE' by convention) (if this isn't done already).  A copyright
notice for the project should _not_ go in the same file (The LGPL
already has one for the LGPL authorship itself, so this is probably
the only file in the distribution which should definitiely _not_ have
the project copyright notice). It should ideally be a header on at least
one source file, (preferably all of them), but could be any README, or
even just a notice on the project website, or an email saying '


I must disagree with you on this point.  It is perfectly fine to ship the
copyright and the license in two separate files, but it is also perfectly fine
to ship them in the same file.  I do so in my upstream project linked in a
previous email, and Debian does so in debian/copyright.  Using a file named
LICENSE or 

Bug#1066869: RFS: hyprpaper/0.6.0-1 [ITP] -- Wallpaper utility for Hyprland

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "hyprpaper":

 * Package name : hyprpaper
   Version  : 0.6.0-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprpaper
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprpaper
   Section  : x11

The source builds the following binary packages:

  hyprpaper - Wallpaper utility for Hyprland

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/hyprpaper/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprpaper/hyprpaper_0.6.0-1.dsc

Changes for the initial release:

 hyprpaper (0.6.0-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1065699
   * Included a simple man page for hyprpaper (uses pandoc for building).

Regards,
-- 
  Alan M Varghese



Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libudis86":

 * Package name : libudis86
   Version  : 0~20221013-1
   Upstream contact : https://github.com/canihavesomecoffee/udis86/issues
 * URL  : https://github.com/canihavesomecoffee/udis86
 * License  : __AUTO_PERMISSIVE__, BSD-2-Clause, __UNKNOWN__
 * Vcs  : https://salsa.debian.org/NyxTrail/udis86
   Section  : misc

The source builds the following binary packages:

  libudis86-0 - Disassembler for x86 and x86-64 class ISA (library)
  libudis86-dev - Disassembler for x86 and x86-64 class ISA (development files)
  udcli - Disassembler for x86 and x86-64 class ISA (cli)
  libudis86-doc - Disassembler for x86 and x86-64 class ISA (documentation)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libudis86/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libudis86/libudis86_0~20221013-1.dsc

Changes for the initial release:

 libudis86 (0~20221013-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1061940
   * This packaging is based on the fork
 https://github.com/canihavesomecoffee/udis86
 which includes "fixes and additions" from other forks.
   * The latest upstream release is v1.7.2 made on Sep 2, 2013. This build is
 however, based on the latest commit #5336633, made on Oct 13, 2022
   * Created a man page for udcli based on information from '--help' and
 additional information from the project's README.

Regards,
-- 
  Alan M Varghese



Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "tracy":

 * Package name : tracy
   Version  : 0.10+ds-1
   Upstream contact : Bartosz Taudul 
 * URL  : https://github.com/wolfpld/tracy/
 * License  : Expat, Expat or Unlicense, BSD-2-Clause, BSD-3-clause, 
BSD-3-Clause, Zlib, Unlicense
 * Vcs  : https://salsa.debian.org/NyxTrail/tracy
   Section  : devel

The source builds the following binary packages:

  libtracyclient0.10.0 - Hybrid frame and sampling profiler (library)
  libtracy-dev - Hybrid frame and sampling profiler (development files)
  tracy-profiler - Hybrid frame and sampling profiler (profiler application)
  tracy-capture - Hybrid frame and sampling profiler (capture application)
  tracy-csvexport - Hybrid frame and sampling profiler (csvexport application)
  tracy-doc - Hybrid frame and sampling profiler (documentation)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/tracy/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tracy/tracy_0.10+ds-1.dsc

Changes for the initial release:

 tracy (0.10+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1063442
   * This program includes source files from many other open source
 projects.
   * Of these zstd has been devendored.
   * TODO: devendor imgui, nfd, dtl

Regards,
-- 
  Alan M Varghese



Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libhyprlang":

 * Package name : libhyprlang
   Version  : 0.5.0-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprlang
 * License  : LGPL-3+
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
   Section  : x11

The source builds the following binary packages:

  libhyprlang2 - Configuration language for Hyprland (library)
  libhyprlang-dev - Configuration language for Hyprland (development files)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libhyprlang/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc

Changes for the initial release:

 libhyprlang (0.5.0-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1065352

Regards,
-- 
  Alan M Varghese



Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland

2024-03-14 Thread Alan M Varghese

Hello Mo,

May I address you Mo?

I am happy to co-maintain hyprland with you. :)

The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I understand, the Debian policy recommends de-vendoring
over including files from other sources.

I have been working on this for a while and just uploaded them all
to mentors and created RFS for them. Currently I have completed
packaging hyprland and all its dependencies to the best of my ability.

Regarding the points you shared:
1. I wasn't sure what to do with tracy. I have however de-vendored
it and created an RFS for it[1]. But, I am unable to get the GPU
traces working on my AMD RX 6600 (for a debug build of Hyprland with
tracy enabled). I am not sure if this is because of my device or
something else. I have seen some discussion upstream that tracy's
GPU traces are not always reliable.

   Tracy seems to work fine, otherwise.

2. I have de-vendored udis86 too. The library and the included CLI
seems to run fine. Here is the RFS[2].

3. Again, I have separated hyprland-protocols and the RFS is here[3].

You can find the VCS for all hyprland related stuff I did, under the
NyxTrail namespace in salsa[4].

The packages all seem to run fine so far.

This is my first time packaging for Debian and any feedback is
welcome.

Let me know how you wish to proceed.

Regards,
Alan

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868
[4] https://salsa.debian.org/NyxTrail

On 3/15/24 01:10, Mo Zhou wrote:

Hi Alan,

Thank you for your work!

I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland

I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.

I have uploaded hyprlang to NEW without checking ITP
https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html

The hyprland is still pending as I've not yet finished
the debian/copyright part.

In terms of build depends of hyprland:
1. tracy is optional. USE_TRACY is by default off. We can build
    the package without tracy.
2. the udis86 is embedded in the upstream tarball as well.
    Maybe we can keep it embedded as udis86 is only needed by
    hyprland
3. hyprland-protocols is also embedded. I suppose it is ok
    to keep this specific project, instead of splitting the
    package to increase the required amount of work.

Shall we merge our work and co-maintain this?

On 3/14/24 14:46, Alan M Varghese wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "libhyprlang":

  * Package name : libhyprlang
    Version  : 0.5.0-1
    Upstream contact : vaxerski 
  * URL  : https://github.com/hyprwm/hyprlang
  * License  : LGPL-3+
  * Vcs  : https://salsa.debian.org/NyxTrail/hyprlang
    Section  : x11

The source builds the following binary packages:

   libhyprlang2 - Configuration language for Hyprland (library)
   libhyprlang-dev - Configuration language for Hyprland (development files)

To access further information about this package, please visit the following 
URL:

   https://mentors.debian.net/package/libhyprlang/

Alternatively, you can download the package with 'dget' using this command:

   dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc

Changes for the initial release:

  libhyprlang (0.5.0-1) UNRELEASED; urgency=low
  .
    * Initial release. Closes: #1065352

Regards,






Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear Mentors,

I am looking for a sponsor for my package "hyprland-protocols":

 * Package name : hyprland-protocols
   Version  : 0.2~20230811-1
   Upstream contact : vaxerski 
 * URL  : https://github.com/hyprwm/hyprland-protocols
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprland-protocols
   Section  : x11

The source builds the following binary packages:

  hyprland-protocols - Wayland protocol extensions for Hyprland

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/hyprland-protocols/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprland-protocols/hyprland-protocols_0.2~20230811-1.dsc

Changes for the initial release:

 hyprland-protocols (0.2~20230811-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1051806
   * This build is based on a specific upstream commit of hyprland-protocols.
 hyprland depends on commit #0c2ce70 of hyprland-protocols. The latest
 release of hyprland-protocols is v0.2 which is behind by a few commits.

Regards,
-- 
  Alan M Varghese



Bug#1066876: RFS: hyprland/0.36.0+ds-1 [ITP] -- Dynamic tiling Wayland compositor

2024-03-14 Thread Alan M Varghese
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: a...@digistorm.in

Dear mentors,

I am looking for a sponsor for my package "hyprland":

 * Package name : hyprland
   Version  : 0.36.0+ds-1
   Upstream contact : https://github.com/hyprwm/Hyprland/issues
 * URL  : https://hyprland.org
 * License  : BSD-3-Clause, MIT
 * Vcs  : https://salsa.debian.org/NyxTrail/hyprland
   Section  : x11

The source builds the following binary packages:

  hyprland - Dynamic tiling Wayland compositor
  hyprland-backgrounds - Set of backgrounds packaged with the hyprland Wayland 
compositor
  hyprland-dev - Development files for Hyprland

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/hyprland/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hyprland/hyprland_0.36.0+ds-1.dsc

Changes for the initial release:

 hyprland (0.36.0+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #1040971
   * The subprojects udis86, tracy and hyprland-protocols have been
 devendored. The source is patched to support this devendoring.
   * The subproject wlroots cannot be devendored. hyprland versions depend on
 a specific commit of the wlroots project and upstream cannot does not
 recommend using any version. So, wlroots is included in this package for
 Debian, with the following changes:
 * The library 'libwlroots.so.13032' that is generated by the project is
   moved to a "private" library directory under usr/lib/hyprland.
 * RPATH is updated so that hyprland links correctly to the library in the
   modified path

Regards,
-- 
  Alan M Varghese



FWD: Copyright in LGPL projects

2024-03-03 Thread Alan M Varghese

Sent message incorrectly to debian-mentors-request instead of debian-mentors. 
Correcting.


 Forwarded Message 
Subject: Copyright in LGPL projects
Date: Mon, 4 Mar 2024 11:10:58 +0530
From: Alan M Varghese 
To: 1065...@bugs.debian.org
CC: Matthias Geiger , SmartList 


Hello Mentors,

I have been working on packaging Hyprland window manager.
hyprlang[0] (with a 'g') is a new dependency for this project. This project 
(hyprlang) is licensed under LGPL.

But, the project authors haven't included a copyright notice anywhere in the 
project. It turns out that the
authors are not sure if this is required for an LGPL project[1].

From a Debian perspective, what is the recommendation regarding this? Do we 
require projects to include the
copyright information along with LGPL?

If the copyright *has* to be included, is it enough to include it in a 
COPYRIGHT file? I couldn't find an
example of a project that does this. Most projects seem to include a copyright 
line along with a short form
of LGPL in each file. (I think it may be more appealing to upstream authors if 
we don't have to include the
copyright in every file).

For example, libplacebo[2] is a library I found installed on my system that 
uses LGPL. This project does not
have a common copyright file, but there are copyright notices in some source 
files[3]. While some other source
files in this project do not have a copyright notice[4][5][6].

Note: my doubts are specifically regarding the LGPL license. For other licenses 
like BSD, I see both practices
of including a COPYRIGHT file as well as a short copyright notice in each file, 
or a combination of the two.

Thanks,
Alan M Varghese

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065352
[1] https://github.com/hyprwm/hyprlang/issues/28
[2] https://code.videolan.org/videolan/libplacebo
[3] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c?ref_type=heads
[4] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c?ref_type=heads
[5] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c?ref_type=heads
[6] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/colorspace.c?ref_type=heads



Re: FWD: Copyright in LGPL projects

2024-03-04 Thread Alan M Varghese

Thanks you for the confirmation. Really appreciate it!

They have added a copyright file; so it should be all good. I was likely being
overly cautious and they might have been too. It tripped me up when they 
indicated
(L)GPL might have to be treated differently, and when I looked up projects that 
used
LGPL, they seemed to follow a different style from say, BSD/MIT licensed ones.

On 3/5/24 11:32, Andrey Rahmatullin wrote:

There are no special formats for copyright files and the license shouldn't
matter so I'm still not sure what's the actual question they have.
In most software the top-level copyright is simply stated as one line in
the top-level LICENSE or whatever file or even in the top-level README,
and separate per-file copyrights are stated in the files themselves. The
calibre one you linked is very unusual




Re: FWD: Copyright in LGPL projects

2024-03-04 Thread Alan M Varghese

Hello Soren,

Thank you for answering my queries.

I will share this with the upstream project. The project authors are unsure how
to do this for an LGPL project. I will see tomorrow if I can find an example of
an LGPL project that includes the copyright information in the root of the 
project.
(I found a project that does this for GPL[1], but not for LGPL).

[1] https://github.com/kovidgoyal/calibre/blob/master/COPYRIGHT

Regards,
Alan


On 3/4/24 23:49, Soren Stoutner wrote:

Alan,

These are good questions.

1.  Yes, there must be a copyright statement.  Only the person, people, group,
or organization that holds the copyright can issue a license for other people
to use the work.  So, you must have someone claiming a copyright or they do
not have the legal ability to release the work to others under the LGPL.

2.  No, it is not required that each individual file contain a copyright
statement or the header of the LGPL at the top.  The FSF recommends such as a
best practice, and I would agree that it is desirable, but it is not required.

My recommendation would be that you communicate to the upstream project that
they need to include the copyright and licensing information in the root of
their repository, preferably all in one file, as a minimum requirement for you
to be willing to package their project in Debian.

Soren

On Sunday, March 3, 2024 11:06:30 PM MST Alan M Varghese wrote:

Sent message incorrectly to debian-mentors-request instead of debian-

mentors.

Correcting.


 Forwarded Message 
Subject: Copyright in LGPL projects
Date: Mon, 4 Mar 2024 11:10:58 +0530
From: Alan M Varghese 
To: 1065...@bugs.debian.org
CC: Matthias Geiger , SmartList


Hello Mentors,

I have been working on packaging Hyprland window manager.
hyprlang[0] (with a 'g') is a new dependency for this project. This project
(hyprlang) is licensed under LGPL.

But, the project authors haven't included a copyright notice anywhere in the
project. It turns out that the authors are not sure if this is required for
an LGPL project[1].

  From a Debian perspective, what is the recommendation regarding this? Do we
require projects to include the copyright information along with LGPL?

If the copyright *has* to be included, is it enough to include it in a
COPYRIGHT file? I couldn't find an example of a project that does this. Most
projects seem to include a copyright line along with a short form of LGPL in
each file. (I think it may be more appealing to upstream authors if we don't
have to include the copyright in every file).

For example, libplacebo[2] is a library I found installed on my system that
uses LGPL. This project does not have a common copyright file, but there are
copyright notices in some source files[3]. While some other source files in
this project do not have a copyright notice[4][5][6].

Note: my doubts are specifically regarding the LGPL license. For other
licenses like BSD, I see both practices of including a COPYRIGHT file as well
as a short copyright notice in each file, or a combination of the two.

Thanks,
Alan M Varghese

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065352
[1] https://github.com/hyprwm/hyprlang/issues/28
[2] https://code.videolan.org/videolan/libplacebo
[3]
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c?

ref_

type=heads [4]
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c?

ref_t

ype=heads [5]
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c?

ref_t

ype=heads [6]
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/

colorspace.c?

ref_type=heads







Re: FWD: Copyright in LGPL projects

2024-03-04 Thread Alan M Varghese

What I meant was that upstream does not know where to put the copyright 
information or
how it should be formatted. Or, to rephrase, is there a preferred format for a 
COPYRIGHT file
in a project that uses LGPL?

This is the issue I opened upstream:
https://github.com/hyprwm/hyprlang/issues/28

On 3/5/24 01:38, Andrey Rahmatullin wrote:

On Tue, Mar 05, 2024 at 12:38:00AM +0530, Alan M Varghese wrote:

Hello Soren,

Thank you for answering my queries.

I will share this with the upstream project. The project authors are unsure how
to do this for an LGPL project. I will see tomorrow if I can find an example of
an LGPL project that includes the copyright information in the root of the 
project.
(I found a project that does this for GPL[1], but not for LGPL).

Why would that make a difference?





Bug#1066869: RFS: hyprpaper/0.6.0-1 [ITP] -- Wallpaper utility for Hyprland

2024-04-06 Thread Alan M Varghese

Hello Andrey,


$(MAKE) clear (as a replacement for $(MAKE) clean) should run in
override_dh_auto_clean, not override_dh_clean.

Done.


debian/watch is empty

Filled in.


There is a commented out override_dh_auto_configure.

Removed.


002-add-fortify-flags.patch adds -D_FORTIFY_SOURCE=2 explicitly, but the
proper fix is making the upstream build system respect the compile flags
set by dpkg-buildflags.

Removed the patch. Instead, export CXXFLAGS from debian/rules.

Thanks,
Alan