Re: ayatana-indicator-messages: bump epoch in package version from to 1

[Mike Gabriel]

Hi Jeremy, hi Michael,

On  So 12 Dez 2021 20:24:11 CET, Michael Biebl wrote:


On 12.12.21 19:22, Jeremy Bicha wrote:

Therefore, it seems pretty easy to me for you to just bump the
upstream version in its next release from 0.9.0 to 13.11.0 (or 14.0 or
14.9.0 or whatever higher number). Blame Ubuntu in your release notes.

That seems like the least complex way to handle this. No epochs. No
version skew between upstream and Debian. No version skew between the
Debian source package and the binary packages. No version skew between
Debian and Ubuntu. No tricky version number mangling in debian/rules.

Version numbers are cheap. It's really not a big deal to bump your
version from 0.9 to 14. After that, you don't have any obligation to
do year.month versioning.


Yeah, I think this is the way to go. Especially since this also  
affects other distros which will also have the same issue.


If ayatana-indicator-messages is the natural successor of  
indicator-messages it should just make sure to have a higher  
(upstream) version number.


And there is prior art here. E.g. systemd bumped it's version bumper  
from v44 to v183 after it had merged the udev sources (which at that  
point were at version v182).


We will to a year.month.revision versioning scheme for all Ayatana  
System Indicators coming with the next release series.


Thanks for your feedback.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpY94THRzIiu.pgp
Description: Digitale PGP-Signatur

Bug#1001622: ITP: groops -- software toolkit for gravity field recovery and GNSS processing

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: groops
  Version : 0+git20210906
  Upstream Authors: Torsten Mayer-Guerr,
Annette Eicker,
Daniel Rieser,
Norbert Zehentner,
Christian Pock,
Matthias Ellmer,
Beate Koch,
Andreas Kvas,
Saniya Behzadpour,
Sebastian Strasser,
Sandro Krauss,
Barbara Suesser-Rechberger,
Patrick Dumitraschkewitz
* URL : https://github.com/groops-devs/groops
* License : GPL-3-or-later
  Description : software toolkit for gravity field recovery and GNSS 
processing
 The Gravity Recovery Object Oriented Programming System (GROOPS) is a 
software
 toolkit written in C++ that enables the user to perform core geodetic 
tasks.
 Key features of the software include gravity field recovery from 
satellite and
 terrestrial data, the determination of satellite orbits from global 
navigation

 satellite system (GNSS) measurements, and the processing of GNSS
 constellations and ground station networks.
 .
 Most tasks and algorithms are (optionally) parallelized through the 
Message
 Passing Interface (MPI), thus the software enables a smooth transition 
from
 single-CPU desktop computers to large distributed computing 
environments for

 resource intensive tasks.

Bug#1001627: ITP: pytest-order -- A pytest plugin to order test execution

[Julian Gilbey]

Package: wnpp
Severity: wishlist
Owner: Julian Gilbey 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team 


* Package name: pytest-order
  Version : 1.1.0
  Upstream Author : Frank Tobia 
* URL : https://github.com/pytest-dev/pytest-order
* License : MIT
  Programming Lang: Python
  Description : A pytest plugin to order test execution

pytest-order is a pytest plugin that allows you to customize the order
in which your tests are run. It uses the marker order that defines
when a specific test shall run, either by using an ordinal number, or
by specifying the relationship to other tests.


This package is required to run the tests supplied with the Spyder
package (at build-time and for autopkgtest).  It will be maintained
within the Debian Python Team, with me as the Uploader.

Best wishes,

   Julian

Reopen RFP Skia - Google's 2D graphic suite

[maxzor]

Hello,

TL;DR Please consider reopening the following request for packaging :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180

Skia library is monolithic, comparable to Cairo, and has become quite 
central

in 2D graphics :
it is used in Firefox, Chromium, so it ends up in Chrome,
Electron-based software such as Atom, VSCode... LibreOffice...
As far as I know, currently, each of these packages statically bundles 
its skia,

which is often tens of MBs. The full Skia library build is 500MB.

I don't know the history between Skia and GNU/Linux.
It seems to me that Google is pretty neutral here. They do their thing
with their Chrome, Android and Flutter branches, and do not actively 
sponsor

the library towards GNU/Linux distributions.

I believe that the effort of decoupling Skia from the upstream packages
can be worth it. It could to allow more people to hear about the 
existence of

the library in the first place, to study its algorithms,
and maybe build upon them. There is tiny-skia in rust for example.
Of course, decoupling skia and packaging it as a shared library
could save storage space too.

Building a static library on Bullseye is pretty straightforward
with the instructions on Skia's website,
https://skia.org/docs/user/download/
it resembles, on a bullseye machine, to:

```bash
#!/bin/bash
apt install build-essential git python2 python llvm-11 llvm-11-dev 
clang-11 clang libvulkan-dev vulkan-tools

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH="${PWD}/depot_tools:${PATH}"
git clone https://skia.googlesource.com/skia.git
cd skia

python2 tools/git-sync-deps
tools/install_dependencies.sh
mkdir out
bin/gn gen out/clang11_unofficial_static --args'cc="clang" cxx="clang++" 
is_official_build=false'

ninja -C out/clang11_unofficial_static

#launching the demo viewer
out/clang11_unofficial_static/viewer --resourcePath resources
```

... building a .so is more involved, I do have an issue with the dependency
Harfbuzz, the text layout and shaper library.
Its component harfbuzz-subset has been stabilized and released
three months ago, it is not yet packaged in Debian,
and is looked-for by the linker in git HEAD. Will try an older tag.
I also have trouble getting the Vulkan backend to run on the free amdgpu 
driver:

https://bugs.chromium.org/p/skia/issues/detail?id=12736

I do not have the rights on the request mail server to unarchive the RFP.

Down below is :
  - the ripgrep of a Skia struct, "SkCpu" on my system. Beat me to it,
    I have installed quite a lot of software outside of apt,
    sometimes proprietary. Still, there's a lot of Skia in here, and 
the heuristic

    to find where skia is statically bundled is far from perfect.
  - the irc.libera.chat discussion that spawned this mail

Best regards, Maxime

--- 



```bash
mada# whoami
root
mada# pwd
/
mada# rg -uuu -i -g 
'!{var/log/*,proc/*,sys/*,run/*,dev/*,home/maxzor/skia/*,*cquery_cached_index*}' 
-T{cpp,txt,log} SkCpu | grep "Binary file"
Binary file opt/Element/element-desktop matches (found "\u{0}" byte 
around offset 7)

Binary file opt/Sozi/Sozi matches (found "\u{0}" byte around offset 7)
Binary file opt/BlueJeans/bluejeans-v2 matches (found "\u{0}" byte 
around offset 7)
Binary file usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.12.8 
matches (found "\u{0}" byte around offset 8)
Binary file usr/share/discord/Discord matches (found "\u{0}" byte around 
offset 7)
Binary file var/lib/mlocate/mlocate.db matches (found "\u{0}" byte 
around offset 0)

Binary file usr/share/code/code matches (found "\u{0}" byte around offset 7)
Binary file opt/google/chrome/chrome matches (found "\u{0}" byte around 
offset 7)
Binary file var/lib/snapd/snaps/atom_281.snap matches (found "\u{0}" 
byte around offset 6)
Binary file home/maxzor/Téléchargements/Telegram/Telegram matches (found 
"\u{0}" byte around offset 8)
Binary file home/maxzor/.cache/Cypress/4.12.1/Cypress/Cypress matches 
(found "\u{0}" byte around offset 7)
Binary file 
home/maxzor/Qt/5.14.0/gcc_64/lib/libQt5WebEngineCore.so.5.14.0.debug 
matches (found "\u{0}" byte around offset 8)
Binary file 
home/maxzor/odoo/.git/objects/pack/pack-1214eae81df955baf62061658e62733a74577092.pack 
matches (found "\u{0}" byte around offset 4)
Binary file snap/atom/281/usr/share/atom/atom matches (found "\u{0}" 
byte around offset 7)
Binary file snap/spotify/56/usr/share/spotify/libcef.so matches (found 
"\u{0}" byte around offset 7)
Binary file snap/chromium/1810/usr/lib/chromium-browser/chrome matches 
(found "\u{0}" byte around offset 7)
Binary file 
home/maxzor/elk/kibana/.git/objects/pack/pack-1dc16e6c292416e9a1d79d2758c21457782106e6.pack 
matches (found "\u{0}" byte around offset 4)
Binary file home/maxzor/.wine/drive_c/Program Files 
(x86)/PokerStars.FR/br/libcef.dll matches (found "\u{0}" byte around 
offset 3)
Binary file snap/atom/281/usr/share/atom/resources/app.asar match

Re: Reopen RFP Skia - Google's 2D graphic suite

[Andrey Rahmatullin]

On Mon, Dec 13, 2021 at 02:51:55PM +0100, maxzor wrote:
> TL;DR Please consider reopening the following request for packaging :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180
You could that yourself. On the other hand, having an RFP doesn't mean
anything so reopening it is not useful. If someone wants to package it
they could do that with or without the RFP existing.

> I believe that the effort of decoupling Skia from the upstream packages
> can be worth it. It could to allow more people to hear about the existence
> of
> the library in the first place, to study its algorithms,
> and maybe build upon them. 
Somebody still needs to do that, and then maintain the package in Debian.

> I do not have the rights on the request mail server to unarchive the RFP.
I don't think the concept of such rights exists.

>  Hello again, do you know why skia is not packaged?
>  maxzor: assuming it meets the DSFG, it is often lack of someone
> volunteering to do the work
This is correct.

>  maxzor: Didn't you just ask this in #ubuntu?
>  I did jkc, I was received... strangely
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180 -- hmm
> unsure why that bug was marked as done and archived, but there was an RFP
> bug for it a while ago. MAybe they close old RFP bugs if no one steps up
> since projects can die and not be needed. Also could be a library not needed
> by other things in debian.
It was indeed closed due to inactivity, as can be seen in the close email.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

facility to access the NEWS content

[Patrice Duroux]

Hi,

I do not known if this is the right list to address this, if it has been already
discussed and so it can be considered as noise. ;-)

Packages may provide a NEWS (or any other name, compressed or not, etc.) file
that may be part of the «main» package (like in hwloc vs. libhwloc15 for
src:hwloc) or in a library package (like in the libpipewire-0.3-0 vs.
pipewire/pipewire-bin for src:pipewire).

But as a user is there an uniform / easy (whatever its place and name) to read
it? Like:

- using the command line (apt news ... or dpkg .., etc.),
- or/and by a link in the Debian PTS for instance.

Should this then be entered for the build?
Or using some other data resource using a website or UDD content?
By this last question, I have in mind some remarks in the uscan version 5
discussion.

Many thanks,
Patrice

Note that:
1. I did not look at the Debian Policy Manual if there is a point on that and so
if it may be «randomly» placed by the maintainer(s). It is not really my point
here.
2. It exists apt-listchanges but it do not answer the need here, exact?

Re: Deps of -dev packages with pkg-config .pc file: Policy Change?

[Alexander Traud]

> If foo.pc in libfoo-dev references bar.pc [...]

That is the problem: If 'bar.pc' is referenced just because for static
libraries, why does it create a dependency for me as a user, who is 
a) not using pkg-config at all 
and/or 
b) linking dynamically?

Let us assume 'bar.pc' creates a dependency in Debian, then the question 
arises: Why is the package 'pkg-config' itself not a dependency, too?

Let us assume 'bar.pc' would create a dependency in Debian, then the 
question arises: Why does the Debian maintainer not transform it to 
'Libs.private', not upstream but via a Debian patch? That would avoid 
such .pc-file*only* dependencies.

Just to repeat: libunbound-dev works great without nettle-dev and 
libevent-dev. It is just the .pc file itself which introduced those 
dependencies. A little tweak to the .pc file, and it works for both 
dynamic and static linking, and does not add any such dependencies. My 
conclusion: The .pc file does not suite Debian (and its -dev package 
concept).

> Requires.private [is] quite clear cut.

I had a hard time to understand [1]. For platforms which have no 
separate '-dev' packages, yes, easy. For platforms which do have 
separate '-dev' packages, I see the problem one abstraction level 
higher: Those libs, which are in 'Requires.private' just for static 
linking, why not moving them to 'Libs.private'?

Let us assume it is a clear cut: What exactly should I do now in case of
- libunbound-dev: Report as that two dependencies are still missing or 
  creating a Debian patch to adjust the .pc for Debian?
- libsrtp2-dev: The package which all started this for me. It has 
  pkg-config as dep. Should I report that over depends on pkg-config?
- gnome-calculator: The default calculator in every Ubuntu Desktop 
  installation. It misses three -dev deps because of the two .pc files 
  in the package. Should I report those deps as missing? Or should I 
  report that the Gnome Calculator needs two -dev packages (and those 
  then dep on those -dev)?
When is it a wish, when is it a bug report?

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Muehlenhoff]

On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > Exactly that.
> > 
> > I'd suggest anyone who's interested in seeing Chromium supported to first
> > update it in unstable (and then work towards updated in bullseye-security).
> 
> I started doing just that: https://salsa.debian.org/dilinger/chromium (v96
> and misc-fixes branches).

As a side note: If any of the system/* patches cause issues, feel free to switch
to the vendored copies. Vendoring in general is frowned upon since it requires 
that
a fix in a libraries spreads out to all vendored copies, but for Chromium 
there's
a steady stream of Chromium-internal security issues anyway, so for all
practical purposes it doesn't make a difference if the Chromium security 
releases
also include a fix for a vendored lib like ICU.

Cheers,
Moritz

Re: Deps of -dev packages with pkg-config .pc file: Policy Change?

[Simon McVittie]

On Mon, 13 Dec 2021 at 22:46:43 +0100, Alexander Traud wrote:
> Let us assume 'bar.pc' would create a dependency in Debian, then the 
> question arises: Why does the Debian maintainer not transform it to 
> 'Libs.private', not upstream but via a Debian patch? That would avoid 
> such .pc-file*only* dependencies.

Libs.private does not follow interdependencies between .pc files, so
converting Requires.private into Libs.private would require copying all
the recursive dependencies of the required library, not just the required
library itself.

For example, if you depend on glib-2.0.pc (-lglib-2.0), converting
Requires.private: glib-2.0 into Libs.private requires you to know (or more
likely, find out at configure time) that it depends on libpcre.

This doesn't scale well, and a previously-correct .pc file can become
retroactively incorrect as a result of a lower-level library changing
an implementatation detail. For example, if GLib moves from libpcre to
libpcre2, as has been requested, then a GLib-dependent library having
-lglib-2.0 -lpcre in Libs.private will no longer be sufficient for
static linking.

> Just to repeat: libunbound-dev works great without nettle-dev and 
> libevent-dev

With the change you are asking for, libunbound-dev would work *for dynamic
linking* without those.

If you're linking statically, you need to be able to satisfy the recursive
dependencies of libunbound (regardless of whether you are using pkg-config
or not), so, no, you will need nettle-dev and libevent-dev either way.

smcv

Re: Deps of -dev packages with pkg-config .pc file: Policy Change?

[Russ Allbery]

Simon McVittie  writes:

> If you're linking statically, you need to be able to satisfy the
> recursive dependencies of libunbound (regardless of whether you are
> using pkg-config or not), so, no, you will need nettle-dev and
> libevent-dev either way.

And, specifically, I think we should say as a matter of policy that Debian
does not try to declare the dependencies required for static linking and
therefore static linking may require tracking down what additional -dev
packages you need and manually installing them.  The dependencies for -dev
packages should reflect the requirements for dynamic linking.

Static linking of C libraries is rare enough at this point, and (possibly
more relevantly) sufficiently untested by Debian that I don't think we
should try to support it directly in the dependency structure.  It would
pull in a whole bunch of -dev packages that wouldn't be used 95% of the
time.

This is what I already do for libremctl-dev, for example.  (Well, I list
the libraries required for static linking in Suggests currently, but I'm
not sure that list is complete any more and should probably just drop it
completely.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1001672: ITP: certinfo -- print x509 certificate info

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: certinfo
  Version : 1.0.6-1
  Upstream Author : Peter Reisinger
* URL : https://github.com/pete911/certinfo
* License : Expat
  Programming Lang: Go
  Description : Print x509 certificate info

 Print x509 certificate info
 .
 Similar to openssl x509 -in  -text command, but handles chains,
 multiple files and TCP addresses. TLS/SSL version prints as well when
 using TCP address argument.

This package will be maintained by the go packaging team

Bug#1001673: ITP: golang-github-icza-gox -- Minimalistic extension to Go. It means to be a complement to the standard library.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-icza-gox
  Version : 0.0~git20210726.cd40a3f-1
  Upstream Author : András Belicza
* URL : https://github.com/icza/gox
* License : Apache-2.0
  Programming Lang: Go
  Description : Minimalistic extension to Go. It means to be a complement 
to the standard library.

 The gox module is a minimalistic, lightweigt extension to Go. It
 contains constants, helpers and utilities which could have been part of
 Go itself.

This package will be maintained by the go team

Re: Re: Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?

[Steven Robbins]

Thanks for the pointer to https://wiki.debian.org/
ArchitectureSpecificsMemo#Architecture_baselines.

I read there that "Each Debian architecture has a baseline indicating the 
oldest or least capable CPU on which the architecture can be used. The 
baseline can change between Debian releases. The baseline is mostly defined by 
the gcc-N package, which is configured to produce baseline binaries when 
options like -march= are not used."

Is the choice of baseline a Debian-specific configuration of GCC?  Or might 
another OS vendor configure differently such that "gcc" running on an i386 
class 
machine actually targets something newer than i686?

-Steve


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

Re: facility to access the NEWS content

[Paul Wise]

On Mon, 2021-12-13 at 19:55 +0100, Patrice Duroux wrote:

> Packages may provide a NEWS (or any other name, compressed or not, etc.) file

Since that is an upstream file, it is not standard across all Debian
package upstreams, including the name, file type and contents.

Different subsets of packages have a standard for it (like all GNU
packages). Different subsets of packages might use a common name for it
like NEWS or ChangeLog or CHANGES.md, but some of those could be for
VCS commit logs so you can't automatically tell which is which. Other
packages might use entirely unique names for the file. Some packages
might even have one file per upstream version.

> as a user is there an uniform / easy (whatever its place and name) to read it?

Given the above constraint, the answer has to be no, until Debian
invents a new mechanism to have the package maintainer designate which
file in the package contains the release notes. That is likely to be a
lot of work for all of Debian to switch to, so the transition would
take a long time and probably never be complete.

I note that there is a ChangeLog field in DEP-8 but it is not defined
which kind of change log (commit log or release notes) it contains.
Also it contains a URL not the filename in the package.

> 2. It exists apt-listchanges but it do not answer the need here, exact?

It shows the NEWS.Debian but not the upstream NEWS file.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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