Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Phil Wyett]

Control: reopen -1

On Tue, 2024-02-20 at 08:12 +, Gianfranco Costamagna wrote:
> Hello,
> 
> > I think I need advice here. I am tempted to breaks replace and upgrade all 
> > to
> > libnanomsg6
> > and then work with upstream on SONAMES etc. How would you and Tobias 
> > proceed?
> 
> yes, this is correct. Change soname and go for experimental, and ask upstream 
> to change
> soname only
> if symbols are changed.
> 
> G.

Hi Gianfranco,

This is now done and ready for review.

Regards copyrights that pop-up i.e.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059236#16

This is the original author, now working under their company name.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




signature.asc
Description: This is a digitally signed message part

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[Aron Xu]

Hi,

On Tue, 20 Feb 2024 14:43:22 +0800 MouseZhang  wrote:
> Hi,
>
> Thanks for your inquiry regarding the package.
>
> > * Which version of the original kwin is used?
> Based on version 5.27.5 of the original kwin.
>

OK, please document that somewhere in your release.

> > * What is missing from the original kwin and why is a fork needed?
> The decision to fork the original kwin was driven by specific needs and 
> requirements that were not fully met by the original project.
> This fork allows us to tailor the window manager more closely to our specific 
> features within the UKUI environment.
> 1. Tablet Mode Support: We have incorporated support for the UKUI tablet 
> mode, which differs from the existing tablet mode mechanism in KWin. 
> Therefore, corresponding modifications are required to adapt to our desktop 
> environment.
> 2. Virtual Keyboard: We have developed a virtual keyboard, but the current 
> window layering in KWin does not fully meet our needs. Particularly, when 
> using the virtual keyboard for text input, pop-up windows such as QCompleter 
> often obscure the virtual keyboard. To address this issue, we need to add a 
> new window layer to ensure that the virtual keyboard always displays above 
> popup windows.
> 3. Custom Protocols: To fulfill the application requirements in the UKUI 
> environment, we have added or modified certain protocols, such as the blur 
> effect with gradual intensity changes.
> 4. Window Snapping Functionality: We have implemented a window snapping 
> feature similar to that in Windows 11, which allows users to manage windows 
> more efficiently.
> 5. Global Gestures: We have replaced the original edge gestures in KWin with 
> global gestures, such as using a four-finger swipe to invoke search.
> 6. Dependency Management: We aim to release UKUI without some of the 
> dependencies associated with the Plasma desktop environment, while still 
> using KWin as our window manager and Wayland compositor.
> 7. X11 Support: We require continued support for X11 and plan to develop new 
> features to ensure flexibility and compatibility of UKUI across various 
> systems.
>

Understood.

> > * What changes have been made based on the original kwin?
> Currently, ukui-kwin only replaces the name and does not conflict with the 
> original kwin.
> In order to meet the Ubuntu DebianImportFreeze deadline, we hope to first 
> introduce ukui-kwin into the Debian repository and then proceed with 
> functionality transplantation. The existing kwin repository used by the UKUI 
> desktop environment is located at https://gitee.com/openkylin/kwin, which 
> includes the aforementioned functionality. However, this conflicts with the 
> original kwin, so we need to fork ukui-kwin. Subsequently, the functionality 
> will be transplanted into UKUI-Kwin (https://gitee.com/openkylin/ukui-kwin).
>

But this does not sound like a reason to just rename and release - if
the reasons behind forking it aren't addressed to some certain extent,
it makes little to no sense to duplicate it in the archive. Therefore
I'd vote my -1 regarding this upload.

Thanks,
Aron

Re: Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

Shriram,

1.  For anything that has the unminified source in the upstream tarball, I 
would just create a 
lintian override with a comment listing the full path to the source for each 
file.  You can see 
an example of how this can be done here:

https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1]

Typically you only copy the source to the debian/missing-sources directory when 
it is not 
included in the upstream tarball and you have had to acquire it from another 
place.

2.  The github link below includes an embedded font in woff format.  Typically, 
fonts like 
this would be considered compiled, so a separate font source would be needed.  
However, 
I’m not sure what the Debian guidance for dealing with an HTML embedded font 
like this.  
If someone else on mentors doesn’t know, I would recommend you ask on 
debian-legal.

As these are mostly README files, and if it becomes difficult for you to 
acquire the source 
for some of them, you might consider excluding those you can’t get the source 
for, at least 
temporarily, using Files-Excluded in debian/copyright (and then running uscan, 
which will 
produce a modified tarball that does not include the problematic files).  For 
example, see:

https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads[2]

Whether this is a good option depends on how helpful those README files are for 
the users 
of your package.  If you go this route, you should add +dfsg to the version of 
your package 
to indicate that the upstream tarball has been repackaged to remove files that 
are not free 
(or for which the source is not available).

Soren

On Tuesday, February 20, 2024 8:23:41 PM MST Shriram Ravindranathan wrote:
> Thanks, Soren.
> 
> It looks like most of these files have just one or two lines that are 
> extremely long.
> 
> These are mostly README files. Most of them seem to have this 
> github-markdown.css 
>  
> minified and pasted in them. While others have the sources that were 
> used to generate them listed in the same folder.
>
> Should I copy these sources into the d/missing-sources directory?

-- 
Soren Stoutner
so...@debian.org


[1] 
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/
lintian-overrides?ref_type=heads
[2] 
https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads


signature.asc
Description: This is a digitally signed message part.

Bug#1064380: RFS: jpeginfo/1.7.1-1 [Team] -- Prints information and tests integrity of JPEG/JFIF files

[肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : jpeginfo
Version : 1.7.1-1
Upstream contact : [fill in name and email of upstream]
* URL : https://www.kokkonen.net/tjko/projects.html
* License : GPL-3
* Vcs : https://salsa.debian.org/debian-phototools-team/jpeginfo
Section : graphics

The source builds the following binary packages:

jpeginfo - Prints information and tests integrity of JPEG/JFIF files

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/j/jpeginfo/jpeginfo_1.7.1-1.dsc


Changes since the last upload:

jpeginfo (1.7.1-1) unstable; urgency=medium
.
* Team upload.
* New upstream version
* d/copyright:
- update copyright year info to 2024
- change upstream License to GPL-3
* use upstream make install
- d/rules: delete override_dh_auto_install target
- delete d/install d/manpages
* d/rules:
- add export DEB_BUILD_MAINT_OPTIONS = hardening=+all
- add override_dh_autoreconf target
* remove d/patches, no more use
* d/watch: add opts=pgpsigurlmangle=s%$%.sig%
* add d/clean
* add d/u/metadata
* add d/u/signing-key.asc

Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Thanks, Soren.

It looks like most of these files have just one or two lines that are 
extremely long.


These are mostly README files. Most of them seem to have this 
github-markdown.css 
 
minified and pasted in them. While others have the sources that were 
used to generate them listed in the same folder.


Should I copy these sources into the d/missing-sources directory?

On 21/02/24 2:28 am, Soren Stoutner wrote:

The question is if the long lines in these HTML files are actually indications
that the HTML files are not the original source.  This usually happens in one
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the
descriptions of the lintian warnings, they acknowledge that this is an
imperfect check that will result in some false-positives.  If that is the
case, the HTML files are the original source, and they have not been minified,
then you can override these warnings with a description as to why.

On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote:

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML
files. These HTML files are infact present in the source code but they
have too many lines which triggers a
"very-long-line-length-in-source-file" lintian tag and that in turn
causes the "source-is-missing" error.

Most of the info I could find in the policy manual and in the forums
pertained to binary files that were included in the source, the strategy
these resources suggested were
1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was
wondering whether it would be okay to suppress these errors. Is there
any other way to solve this?

--
Shriram Ravindranathan




--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility

[Soren Stoutner]

Mateusz,

When compiling locally on my system, the current version of lintian (2.117.0) 
found the following problems.  These are not displayed on mentors.debian.net, 
leading me to believe they were recently added checks.

W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/
libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so]
N: 
N:   Although this package is not a "-dev" package, it installs a
N:   "libsomething.so" symbolic link referencing the corresponding shared
N:   library. When the link doesn't include the version number, it is used by
N:   the linker when other programs are built against this shared library.
N:   
N:   Shared libraries are supposed to place such symbolic links in their
N:   respective "-dev" packages, so it is a bug to include it with the main
N:   library package.
N:   
N:   However, if this is a small package which includes the runtime and the
N:   development libraries, this is not a bug. In the latter case, please
N:   override this warning.
N: 
N:   Please refer to Development files (Section 8.4) in the Debian Policy
N:   Manual for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: libraries/shared/links
N:   Renamed from: non-dev-pkg-with-shlib-symlink
N: 
N:
W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8
N: 
N:   The package name of a library package should usually reflect the soname of
N:   the included library. The package name can determined from the library
N:   file name with the following code snippet:
N:   
N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/
^[[:space:]]*SONAME[[:space:]]*//p' | \
N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/\L&/'
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: libraries/shared/soname
N: 
N:
I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-common.so.
1.8
N: 
N:   Although the package includes a shared library, the package does not have
N:   a symbols control file.
N:   
N:   dpkg can use symbols files in order to generate more accurate library
N:   dependencies for applications, based on the symbols from the library that
N:   are actually used by the application.
N: 
N:   Please refer to the dpkg-gensymbols(1) manual page and
N:   https://wiki.debian.org/UsingSymbolsFiles for details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/shlibs

As noted in the text of the checks, there are scenarios where these do not 
apply (like small packages that include the runtime and the development files), 
which appears to be the case with qt5ct.  Can you please help me to understand 
why qt5ct is including this shared library, if there are any other packages in 
Debian that are building against this library, and if you feel that any of the 
lintian checks above apply?  If you feel they don’t apply I would recommend 
you add lintian overrides and I will be happy to upload your package.

Soren

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

The question is if the long lines in these HTML files are actually indications 
that the HTML files are not the original source.  This usually happens in one 
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the 
descriptions of the lintian warnings, they acknowledge that this is an 
imperfect check that will result in some false-positives.  If that is the 
case, the HTML files are the original source, and they have not been minified, 
then you can override these warnings with a description as to why.

On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote:
> Hello mentors,
> 
> I am getting a few lintian "source-is-missing" errors for some HTML 
> files. These HTML files are infact present in the source code but they 
> have too many lines which triggers a 
> "very-long-line-length-in-source-file" lintian tag and that in turn 
> causes the "source-is-missing" error.
> 
> Most of the info I could find in the policy manual and in the forums 
> pertained to binary files that were included in the source, the strategy 
> these resources suggested were
> 1. Repack upstream tar with the source code of these files
> 2. Add the source code to the d/missing-sources directory
> 
> I don't think either of these are viable options in my case. I was 
> wondering whether it would be okay to suppress these errors. Is there 
> any other way to solve this?
> 
> -- 
> Shriram Ravindranathan
> 


-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Bug#1062001: RFS: trader/7.20-1 -- simple game of interstellar trading

[Tobias Frost]

Control: tags -1 moreinfo

Hi,

some review:

d/control: 
- Please remove all versions from the versioned build depends
  that are fulfiled already since oldstable, e.g gettext and automake.
- Your VCS-Git link git:// is not using an encrypted link, but the site
  supports https://. Please use https.

d/copyright:
- the directory lib/ has files which are not documented in d/copyright;
  (They have a different license and copyright)
- same for the m4 macros

embedded code copies:
- gnulib is packaged for Debian, any reason why you don't use the packaged 
version?
- there are m4 macros from autoconf-archive. Please check if you can use
  the ones from the package autoconf-archive.

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

d/changelog
- d/changelog's purpose is to document changed to the packageing,
  generaly not to document upstream changes, so I'd cut that down
  to:

  trader (7.20-1) unstable; urgency=low
 
* New upstream release.
* Updated to Debian Policy 4.6.2 (no changes).

- lintian findings:
W: trader: groff-message troff::133: warning: macro 'mR' not 
defined [usr/share/man/man6/trader.6.gz:1]
I: trader source: public-upstream-key-not-minimal has 16 extra signature(s) for 
keyid 0D254111C4EE569B [debian/upstream/signing-key.asc]
I: trader source: vcs-field-uses-insecure-uri Git 
git://git.zap.org.au/data/git/trader.git -b with-debian
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-hpux.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-irix.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-osf.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-solaris.h]
P: trader source: source-contains-autogenerated-gperf-data 
[lib/iconv_open-zos.h]

Cheers,
-- 
tobi




On Wed, Jan 31, 2024 at 10:59:26AM +1100, John Zaitseff wrote:
> Hi, Bastian et al.,
> 
> > > > 7.19-1 was never uploaded to Debian, so please remove it from
> > > > the changelog.
> > >
> > > Would this still be the case even though I _did_ release it on
> > > The ZAP Group Australia's repository?  If so, how would I
> > > preserve the changes listed for v7.19 -- should I just add them
> > > as part of the 7.20-1 changelog entry?
> >
> > Yes, you should do that. Alternatively, you can upload 7.19-1
> > before uploading 7.20-1.
> 
> I have removed the changelog entry for 7.19-1; the entry for 7.20-1
> now reads:
> 
>  trader (7.20-1) unstable; urgency=low
> 
>* New upstream release: changed documentation (history of the game),
>  updated Swedish, Norwegian Bokmål, French, German, Serbian, Esperanto,
>  Romanian, Polish and Ukrainian translations.
>* Incorporates changes made to previous upstream release (not uploaded
>  to Debian): new Polish, Romanian and Ukrainian translations, renamed
>  AppStream metainfo and desktop files.
>* Require at least Gettext 0.21 and Automake 1.16 for building.
>* Updated to Debian Policy 4.6.2 (no changes).
> 
> Could you (or someone) now sponsor the package?  The original link
> now points to the updated package:
> 
>   dget -x 
> https://ftp.zap.org.au/pub/debian/dists/zapgroup-sid/main/source/trader_7.20-1.dsc
> 
> Yours truly,
> 
> John Zaitseff
> 
> -- 
> John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
> The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
> Australia Inc.  ╰───╯   https://www.zap.org.au/~john/
> 

Bug#1061779: marked as done (RFS: libmirage/3.2.7-1 [ITP] -- CD-ROM image access library)

[Debian Bug Tracking System]

Your message dated Tue, 20 Feb 2024 20:48:40 +0100
with message-id <589f568f-19f3-4f0a-849d-f83f8ba2e...@debian.org>
and subject line Re: Bug#1061779: RFS: libmirage/3.2.7-1 [ITP] -- CD-ROM image 
access library
has caused the Debian Bug report #1061779,
regarding RFS: libmirage/3.2.7-1 [ITP] -- CD-ROM image access library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1061779: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061779
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : libmirage
   Version  : 3.2.7-1
   Upstream contact : Rok Mandeljc 
 * URL  : https://cdemu.sourceforge.io/
 * License  : GPL-2+, CC0-1.0
   Section  : libs

The source builds the following binary packages:

  libmirage11 - CD-ROM image access library
  gir1.2-mirage-3.2 - CD-ROM image access library (typelib files)
  libmirage11-dev - CD-ROM image access library (development files)
  libmirage11-doc - CD-ROM image access library (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libm/libmirage/libmirage_3.2.7-1.dsc

Changes for the initial release:

 libmirage (3.2.7-1) unstable; urgency=low
 .
   * Initial release, closes: #983444.

Regards,

-- 
Matteo Bini
--- End Message ---
--- Begin Message ---

Thanks for the upload!--- End Message ---

How to install glib schemas?

[Eberhard Beilharz]

Hi,

What's the recommended way to install glib schemas?

Currently I have a .postinst script where I call glib-compile-schemas. 
Is this the best way to do it?


Thanks,
    Eberhard



OpenPGP_0xE9140597606020D3.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML 
files. These HTML files are infact present in the source code but they 
have too many lines which triggers a 
"very-long-line-length-in-source-file" lintian tag and that in turn 
causes the "source-is-missing" error.


Most of the info I could find in the policy manual and in the forums 
pertained to binary files that were included in the source, the strategy 
these resources suggested were

1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was 
wondering whether it would be okay to suppress these errors. Is there 
any other way to solve this?


--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061779: RFS: libmirage/3.2.7-1 [ITP] -- CD-ROM image access library

[Matteo Bini]

Thank you for the heads up, Bastian.
Everything should be fixed now.

--
Matteo Bini

Bug#1064346: RFS: highlight/4.10-1 [ITA] -- Universal source code to formatted text converter

[Shriram Ravindranathan]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : highlight
   Version  : 4.10-1
   Upstream contact : Andre Simon 
 * URL  : http://www.andre-simon.de
 * License  : Expat, LGPL-2.1+, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/highlight
   Section  : devel

The source builds the following binary packages:

  highlight - Universal source code to formatted text converter
  highlight-common - source code to formatted text converter (architecture 
independent files)
  libhighlight-perl - perl bindings for highlight source code to formatted text 
converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/highlight/highlight_4.10-1.dsc

Changes since the last upload:

 highlight (4.10-1) unstable; urgency=medium
 .
   * New upstream version 4.10
   * New maintainer (Closes: #1022114)
   * d/copyright:
 - Add new maintainer to copyright
 - Convert copyright to DEP5 format
 - Remove stanzas for files that no longer exist
   * d/control:
 - Add new maintainer's name to Maintainer field
 - Update VCS-Browser field to canonical URI
   * d/p/*: Remove git-debcherry artifacts and follow DEP-3
   * Add debian/upstream/metadata

Regards,
--
  Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Joachim Zobel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : vzlogger
 Version : 3.1-4
 Upstream contact : Joachim Zobel 
 * URL : http://wiki.volkszaehler.org/software/controller/vzlogger
 * License : GPL-3
 * Vcs : https://github.com/volkszaehler/vzlogger
 Section : net 

The source builds the following binary packages:

 vzlogger - program to read measurements from smart meters and log them
to Influxdb or forward them via MQTT.

vzlogger is a tool to read and log measurements of a wide variety of
smart meters and sensors. It supports various commonly used protocols
such as s0, d0, sml, oms and others. It can write these data to an
Influxdb, forward them via MQTT, make them available via HTTP or eport
them to a volkszaehler.org middleware.

The package is maintained in the upstream repository. Upstream (which I
am part of) currently builds native packages. These are patched (a
switch from native to quilt, a different changelog and a version >= 3.0
for the dependency on openssl) to make them more suitable for debian.
The package is therefore availabe in the upstream repo 

https://github.com/volkszaehler/vzlogger.git 

on branch debian-0.8.3-1.

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

 dget -x 
http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc

Regards,
-- 
 Joachim Zobel

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[MouseZhang]

cc Aron

> On Feb 20, 2024, at 14:43, MouseZhang  wrote:
> 
> Hi,
> 
> Thanks for your inquiry regarding the package.
> 
>> * Which version of the original kwin is used?
> Based on version 5.27.5 of the original kwin.
> 
>> * What is missing from the original kwin and why is a fork needed?
> The decision to fork the original kwin was driven by specific needs and 
> requirements that were not fully met by the original project.
> This fork allows us to tailor the window manager more closely to our specific 
> features within the UKUI environment.
> 1. Tablet Mode Support: We have incorporated support for the UKUI tablet 
> mode, which differs from the existing tablet mode mechanism in KWin. 
> Therefore, corresponding modifications are required to adapt to our desktop 
> environment.
> 2. Virtual Keyboard: We have developed a virtual keyboard, but the current 
> window layering in KWin does not fully meet our needs. Particularly, when 
> using the virtual keyboard for text input, pop-up windows such as QCompleter 
> often obscure the virtual keyboard. To address this issue, we need to add a 
> new window layer to ensure that the virtual keyboard always displays above 
> popup windows.
> 3. Custom Protocols: To fulfill the application requirements in the UKUI 
> environment, we have added or modified certain protocols, such as the blur 
> effect with gradual intensity changes.
> 4. Window Snapping Functionality: We have implemented a window snapping 
> feature similar to that in Windows 11, which allows users to manage windows 
> more efficiently.
> 5. Global Gestures: We have replaced the original edge gestures in KWin with 
> global gestures, such as using a four-finger swipe to invoke search.
> 6. Dependency Management: We aim to release UKUI without some of the 
> dependencies associated with the Plasma desktop environment, while still 
> using KWin as our window manager and Wayland compositor.
> 7. X11 Support: We require continued support for X11 and plan to develop new 
> features to ensure flexibility and compatibility of UKUI across various 
> systems.
> 
>> * What changes have been made based on the original kwin?
> Currently, ukui-kwin only replaces the name and does not conflict with the 
> original kwin.
> In order to meet the Ubuntu DebianImportFreeze deadline, we hope to first 
> introduce ukui-kwin into the Debian repository and then proceed with 
> functionality transplantation. The existing kwin repository used by the UKUI 
> desktop environment is located at https://gitee.com/openkylin/kwin, which 
> includes the aforementioned functionality. However, this conflicts with the 
> original kwin, so we need to fork ukui-kwin. Subsequently, the functionality 
> will be transplanted into UKUI-Kwin (https://gitee.com/openkylin/ukui-kwin).
> 

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Phil Wyett]

On Tue, 2024-02-20 at 08:12 +, Gianfranco Costamagna wrote:
> Hello,
> 
> > I think I need advice here. I am tempted to breaks replace and upgrade all 
> > to
> > libnanomsg6
> > and then work with upstream on SONAMES etc. How would you and Tobias 
> > proceed?
> 
> yes, this is correct. Change soname and go for experimental, and ask upstream 
> to change
> soname only
> if symbols are changed.
> 
> G.

Thanks for the advice.

I will process the package in the next day or so. Playing priority catch-up 
after a number
of days in bed due to my back condition.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




signature.asc
Description: This is a digitally signed message part

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Phil Wyett]

On Thu, 2024-02-15 at 08:18 +, Debian Bug Tracking System wrote:
> 1059236

Hi Gianfranco,

I think I need advice here. I am tempted to breaks replace and upgrade all to 
libnanomsg6
and then work with upstream on SONAMES etc. How would you and Tobias proceed?

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




signature.asc
Description: This is a digitally signed message part

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Gianfranco Costamagna]

Hello,

>I think I need advice here. I am tempted to breaks replace and upgrade all to 
>libnanomsg6
>and then work with upstream on SONAMES etc. How would you and Tobias proceed?

yes, this is correct. Change soname and go for experimental, and ask upstream 
to change soname only
if symbols are changed.

G.