Processed: Re: RFP: gtksheet -- GTK+3 GtkSheet widget

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 ITP: gtksheet -- GTK+3 GtkSheet widget
Bug #1036393 [wnpp] RFP: gtksheet -- GTK+3 GtkSheet widget
Changed Bug title to 'ITP: gtksheet -- GTK+3 GtkSheet widget' from 'RFP: 
gtksheet -- GTK+3 GtkSheet widget'.
> owner -1 b...@debian.org
Bug #1036393 [wnpp] ITP: gtksheet -- GTK+3 GtkSheet widget
Owner recorded as b...@debian.org.

-- 
1036393: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036393
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1036393: RFP: gtksheet -- GTK+3 GtkSheet widget

[Bastian Germann]

Control: retitle -1 ITP: gtksheet -- GTK+3 GtkSheet widget
Control: owner -1 b...@debian.org

I am going to package gtksheet.

Processed: retitle 1052001 to ITP: govarnam -- Completion engine to type Indic languages

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 1052001 ITP: govarnam -- Completion engine to type Indic languages
Bug #1052001 [wnpp] RFP: govarnam -- Completion engine to type Indic languages
Changed Bug title to 'ITP: govarnam -- Completion engine to type Indic 
languages' from 'RFP: govarnam -- Completion engine to type Indic languages'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1052001: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052001
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1052341: ITP: golang-github-openpeedeep-xdg -- A cross platform package that tries to follow XDG Standard when possible

[Aravind I M]

Package: wnpp
Severity: wishlist
Owner: Aravind I M 

* Package name : golang-github-openpeedeep-xdg
Version : 1.0.0-1
Upstream Author : OpenPeeDeeP
* URL : https://github.com/OpenPeeDeeP/xdg
* License : BSD-3-Clause
Programming Lang: Go
Description : A cross platform package that tries to follow XDG Standard 
when possible


This package provides the library to have xdg compliance to application 
by provisioning access to xdg environment variables. Default values are 
used for unset xdg environment variables. This package does not merge 
files if they exist across different directories nor does it create the 
missing directories as it is the responsibility of the application and 
not of the library.


This package is in the dependency tree of Lazygit (#908894) [1]

[1] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[gregor herrmann]

On Wed, 20 Sep 2023 10:29:49 +0200, Francesco P. Lovergine wrote:

> > > I can't really test now, because Geo::GDAL::FFI also needs the
> > > unpackaged FFI::Platypus::Declare, but from reading
> > > https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
> > > and
> > > https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
> > > a simple
> > > 
> > > override_dh_auto_configure:
> > >   dh_auto_configure -- GDAL=/usr
> > > 
> > > plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and 
> > > libgdal-dev
> > > might be enough without any Alien::gdal. Maybe :)
> > > 
> > > (Not sure about
> > > https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
> > > but this is also guarded by an if())

[…]
 
> Ok, it seems that the solution is much more easy than the prospected. The 
> implementation is smart
> enough to keep the gdal.so in the right place, something I oversight before.
> The resulting package needs to be arch:any to create a correct internal
> Geo::GDAL::gdal.pm module per arch,
> but it seems working. 

Sounds great, thanks for investigating.

> That said, I would try to patch to avoid the Platypus::Declare use
> which is currently discouraged/deprecated: I would avoid to read other 
> complains by gregor :-D

Heh :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Processed: tagging 1052262

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1052262 + pending
Bug #1052262 [wnpp] ITP: obs-time-source -- Plugin for OBS Studio that displays 
current date and time
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1052262: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052262
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1052083: RFP: varnam-schemes -- Language related files for Varnam

[Guido Günther]

Hi,
On Sun, Sep 17, 2023 at 11:40:05AM +0200, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: varnam-schemes
>   Version : 1.8.0
> * URL : https://www.example.org/
> * License : MPL-2.0
>   Programming Lang: Ruby
>   Description : Language related files for Varnam
> 
> The scheme files are needed for govarnam / libvarnam to provide the
> completions for the different Indic languages

Prelimenary packaging is at https://salsa.debian.org/agx/varnam-schemes

Bug#1050969:

[Christopher Obbard]

There is some work pending upstream before we can really ship this in Debian: 
https://gitlab.com/larswirzenius/v-i/-/issues/35#note_1552156798

Bug#1052319: ITP: rust-analyzer -- LSP server for Rust

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: rust-analyzer
  Version : 0.3.1631
  Upstream Contact: Rust Analyzer Developers
* URL : https://github.com/rust-lang/rust-analyzer
* License : MIT or Apache-2.0
  Programming Lang: Rust
  Description : LSP server for Rust

rust-analyzer is an implementation of Language Server Protocol for the Rust 
programming language. It provides features like completion and goto definition 
for many code editors, including VS Code, Emacs and Vim. 

Bug#1052001: RFP: govarnam -- Completion engine to type Indic languages

[Guido Günther]

Hi,
On Fri, Sep 15, 2023 at 07:30:31PM +0200, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: govarnam
>   Version : 1.9.0
> * URL : https://github.com/varnamproject/govarnam
> * License : AGPL-3
>   Programming Lang: Go
>   Description : Completion engine to type Indic languages
> 
> Easily Type Indian Languages on computer and mobile. GoVarnam is a
> cross-platform transliteration library. Manglish -> Malayalam, Thanglish
> -> Tamil, Hinglish -> Hindi plus another 10 languages. GoVarnam is a
> near-Go port of libvarnam
> 
> govarnam builds a shared library that can be used from C (and other 
> languages).

Looking at #1052083 I noticed that the scheme files need govarnam to
build so here's prelimenary packaging:

   https://salsa.debian.org/agx/govarnam

Mostly missing is the installation into multi arch directories but it's
enough to build the schemes.
Cheers,
 -- Guido

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 904044 ITP: openvpn3 -- Next generation OpenVPN client for Linux
Bug #904044 [wnpp] RFP: openvpn3 -- Next generation OpenVPN client for Linux
Changed Bug title to 'ITP: openvpn3 -- Next generation OpenVPN client for 
Linux' from 'RFP: openvpn3 -- Next generation OpenVPN client for Linux'.
> owner 904044 !
Bug #904044 [wnpp] ITP: openvpn3 -- Next generation OpenVPN client for Linux
Owner recorded as Marc Leeman .
> --
Stopping processing here.

Please contact me if you need assistance.
-- 
904044: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#904044: OpenVPN3

[Marc Leeman]

OK, I'll pick it up.

There are two repositories, one is the core libraries; the other is the
linux client. The client is compiled by using a git external.

Because of this (git external), I decided package the two repositories
separately: one as a library (lib/dev combo), to use the dev package for
the headers and linking the openvpn3-core statically [1]

The (source) packages are reflecting the upstream git repositories:

1. openvpn3 (library)
2. openvpn3-linux (client)

I need to do some restructuring (from your answer I understand that
/usr/include/openvpn/ as the include path should ot be used).

We're testing it with our company VPN, and it seems to work just fine
(including the 2FA over a web page), the only thing we need to do is to
remove this line from the ovpn files that are generated/provided (error
feedback is not optimal ;-) ).

# OVPN_ACCESS_SERVER_ORGANIZATION=OpenVPN, Inc.

[1] I'd like to get the packages without too much of a patch on the code
and there are some questionable practices like including cpp files.


On Tue, 19 Sept 2023 at 22:28, Bernhard Schmidt  wrote:

> Hi Marc,
>
> > Because our company decided "there will be no impact" to use multifactor
> > authentication, I was forced to package openvpn3.
> >
> > I don't know if you were planning anything in that direction, but my
> > current work can be found here:
> >
> > https://salsa.debian.org/televic-team/openvpn3
> > 
> >
> > It's rough, I need to go through the finer details.
> >
> > If you are nog planning anything, I can open an ITP.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044
> > 
>
> Thanks for letting us know. I haven't taken a deep look at it, but it
> looks pretty sane and I'm not aware of any work other than the upstream
> repository. You are certainly welcome to package it.
>
> I can review and sponsor the first uploads if noone beats me to it
> (anyone: feel free to do so, there is no need of the OpenVPN2
> maintainers to specifically review anything in OpenVPN3, and they will
> continue to be used in parallel for years to come).
>
> I've seen you have applied for DM, so I would be happy to give you
> uploader rights when things have settled.
>
> Bernhard
>


-- 
g. Marc

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Wed, Sep 20, 2023 at 10:29:49AM +0200, Francesco P. Lovergine wrote:


The resulting package needs to be arch:any to create a correct 
internal Geo::GDAL::gdal.pm module per arch,


Err, not required if depending on libgdal-dev, indeed.

--
Francesco P. Lovergine

Bug#884253: See also

[Dan Jacobson]

See also https://github.com/tumic0/GPXSee/issues/98 .

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

On Tue, Sep 19, 2023 at 06:36:13PM +0200, Francesco P. Lovergine wrote:

On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote:

I can't really test now, because Geo::GDAL::FFI also needs the
unpackaged FFI::Platypus::Declare, but from reading
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL
and
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md
a simple

override_dh_auto_configure:
  dh_auto_configure -- GDAL=/usr

plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev
might be enough without any Alien::gdal. Maybe :)

(Not sure about
https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567
but this is also guarded by an if())



Mmmm, let me see. The chain I used was to impact minimally on changes for the 
module
taken from CPAN. I would be happy to minimize the use of all that stuff, I was 
not exactly
enthusiastic about the new course at the time.



Ok, it seems that the solution is much more easy than the prospected. The 
implementation is smart
enough to keep the gdal.so in the right place, something I oversight before. The resulting 
package needs to be arch:any to create a correct internal Geo::GDAL::gdal.pm module per arch,

but it seems working. That said, I would try to patch to avoid the 
Platypus::Declare use
which is currently discouraged/deprecated: I would avoid to read other 
complains by gregor :-D

Thanks a lot for the hints.


--
Francesco P. Lovergine

Bug#1051044: Updating the opentk Uploaders list

[Ying-Chun Liu (PaulLiu)]

Hi Bastian, 

OK. I'll take over this next week. 

Yours, 
Paul

於 2023年9月19日 下午7:52:18 [GMT+02:00]，Bastian Germann  寫到：
>Control: retitle -1 O: opentk -- Open Toolkit wrapper for OpenGL, OpenAL and 
>OpenCL
>Control: reassign -1 wnpp
>X-Debbugs-Cc: paul...@debian.org
>
>Without Jo, the package is obviously not maintained anymore.
>I am orphaning it now.
>
>Paul, you maintain the only reverse dependency, so you might
>want to step up as a new maintainer.
>
>Description: Open Toolkit wrapper for OpenGL, OpenAL and OpenCL
> The Open Toolkit is an advanced, low-level C# library that wraps OpenGL,
> OpenCL and OpenAL. It is suitable for games, scientific applications and
> any other project that requires 3d graphics, audio or compute functionality.

Processed: Bug#1052301 marked as pending in node-stdlib

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1052301 [wnpp] ITP: node-stdlib -- Standard library for JavaScript and 
Node.js
Added tag(s) pending.

-- 
1052301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems