Bug#1071994: git-buildpackage: Please document the --no-sign option in man pages or gbp buildpackage --help

[Guido Günther]

control: tags -1 moreinfo

Hi,
On Mon, May 27, 2024 at 09:05:06AM +, Guillaume Yziquel wrote:
> Package: git-buildpackage
> Version: 0.9.32
> Severity: wishlist
> X-Debbugs-Cc: guillaume.yziq...@mailfence.com
> 
> Dear Maintainer,
> 
> Hi.
> 
> Context: toying around with packaging for tasksh package upstream fix.
> 
> The --no-sign option that allows me to build my package without access
> to the Debian maintainer's private key is not documented in the
> documentation of git-buildpackage. Anywhere I've looked around. If it
> is, it is well hidden.
> 
> This is confusing for the following reason: people trying to hack off a
> quick and dirty package have to disable signing the package; but the
> only thing the documentation talks about is signing tags. That confusion
> has held me back in the past.
> 
> Documenting --no-sign would make things much easier. Lower the entry
> bar.

This is an option of dpkg-buildpackage which (eventually) is invoked by
gbp buildpackge. We have this in the docs:

-  Call  debuild(1)  or  Cowbuilder (via --git-pbuilder) or the application 
specified via --git-builder passing along all arguments given to gbp 
buildpackage on the command line that don't start with  --git-.

Do you have suggestions how that could be improved?
Cheers,
 -- Guido

> 
> Please consider.
> 
> Best regards.
> 
> G.
> 

Bug#893955: sofia-sip-bin: Man pages are currupted

[Guido Günther]

Hi,
On Sat, Mar 24, 2018 at 12:41:50PM +0100, David Ayers wrote:
> Package: sofia-sip-bin
> Version: 1.12.11+20110422.1-2.1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> the included man pages for
>   addrinfo
>   localinfo
>   sip-date
>   sip-dig
>   sip-options
>   stunc
> all seem to be currupted in stretch.
> Please consider fixing this issue for stable.

The man pages are all zero sized files, e.g.:

 $ gunzip -c /usr/share/man/man1/localinfo.1.gz | wc -l

Cheers,
 -- Guido

Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean

[Guido Günther]

Hi,
On Mon, May 20, 2024 at 04:16:49PM -0400, Daniel Kahn Gillmor wrote:
> On Sun 2024-05-19 20:43:58 +0200, Guido Günther wrote:
> > But you'd break that when filtering out files? I think what keeps me
> > confused: the tarball uploaded to Debian is the filtered one and hence
> > has a different checksum, no? 
> 
> hm, i don't think so, because we use
> import-orig.filter-pristine-tar=False.  This lets me preserve both the

Ah...now I get it. You filter the branch but let pristine-tar take care
of restoring the original tarball.

[..snip..]

> > Another reason to not parse debian/clean verbatim is that we'd also need
> > to support dh's substitution variables and would forever need to follow
> > what dh does (and we might even need to pay attention to the dh compat
> > level of the package) as otherwise things would break on people.
> 
> you've convinced me that running the clean target is better than trying
> to parse debian/clean :)

Great! Let's try that path then.

> 
> >> whether the packaging used debhelper or not.  Does that seem like a
> >> plausible way to operate gbp import-orig?
> >
> > That would be an approach. Implementation wise the "tricky" bit is
> > that you don't have debian/ on the upstream branch you want to filter so
> > dh_clean or `debian/rules clean` won't work as is . So we'd need to
> > overlay that (which is certainly doable, just wanted to point it out).
> 
> ah, yes, i see the complication here.
> 
> > So that's a lot of effort for s.th. that can already be done via either
> > gbp.conf or FilesExcluded. I'm not against it, just looking at the pros
> > and cons.
> 
> right, i see tradeoff you're describing, and if you decide this is too
> much complication for gbp, i'm willing to just keep the two lists
> (debian/clean and debian/gbp.conf's import-orig.filter) in sync more or
> less manually.

I'm fine with the complication. Just wanted to point out possible
implementation pitfalls. Just to be sure: It's unlikely that I'll be
able to look at an implementation myself near term.

> Thanks for thinking this all through with me here, Guido!

Thanks for explaining your workflow!
 -- Guido

Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean

[Guido Günther]

Hi dkg,
On Thu, May 16, 2024 at 10:15:52AM -0400, Daniel Kahn Gillmor wrote:
> Hi Guido--
> 
> On Thu 2024-05-16 08:39:27 +0200, Guido Günther wrote:
> > Great! This matches my preferred way too.
> 
> ☺  Thanks for walking through the options here with me!
> 
> > Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that
> > for similar purposes as it even allows to use `gbp import-orig --uscan`
> > and have things filtered out. `debian/clean` could parse the pattern from
> > there.
> 
> Hm, I don't know what the semantics are for Files-Excluded, or what
> other side effects they have.  The documentation for the
> machine-readable copyright format:
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> doesn't even include the word "Excluded", let alone "Files-Excluded"
> (see #685506, sigh).  According to
> https://wiki.debian.org/UscanEnhancements#Deleting_Files_using_Files-Excluded_field_in_debian.2Fcopyright
> the Files-Excluded field actually affects the tarball by causing uscan
> to re-pack it without those files.
> 
> Doing the tarball re-packing would mean breaking the upstream tarball's
> cryptographic signature, so i'm not sure i want to do that.  The goal
> here is to increase attributability and provenance, and breaking the
> upstream cryptographic signature seems to work against that goal.

But you'd break that when filtering out files? I think what keeps me
confused: the tarball uploaded to Debian is the filtered one and hence
has a different checksum, no? 

> 
> > What if you'd read the filter list in the `clean` target?
> 
> Hm, while i depend on gbp for my regular packaging workflow, one of the
> things i like about it is how it wraps itself around other packaging
> workflows.  If i remove debian/gbp.conf from my package's source, the
> source can still build just fine using dpkg-buildpackage or debuild.
> I'd like to keep that property.

I understand that point.

> 
> > I think what you propose is doing it the other way around: Have gbp
> > run `debian/rules clean` to have a programatical way of filtering?
> 
> right, that would do the job, and is probably the more principled way to
> do it than merely parsing debian/clean.  It would work regardless of

It would also have the upside that packages invoking `dh_clean … path1
path2` would still work.

Another reason to not parse debian/clean verbatim is that we'd also need
to support dh's substitution variables and would forever need to follow
what dh does (and we might even need to pay attention to the dh compat
level of the package) as otherwise things would break on people.

> whether the packaging used debhelper or not.  Does that seem like a
> plausible way to operate gbp import-orig?

That would be an approach. Implementation wise the "tricky" bit is
that you don't have debian/ on the upstream branch you want to filter so
dh_clean or `debian/rules clean` won't work as is . So we'd need to
overlay that (which is certainly doable, just wanted to point it out).

So that's a lot of effort for s.th. that can already be done via either
gbp.conf or FilesExcluded. I'm not against it, just looking at the pros
and cons.

Cheers,
 -- Guido

Bug#1071200: git-buildpackage: gbp import-orig: support filtering based on debian/clean

[Guido Günther]

Hi,

On Wed, May 15, 2024 at 06:58:22PM -0400, Daniel Kahn Gillmor wrote:
[..snip..]

> background:  i prefer debian packaging linked to the upstream revision
> control, but also being able to tie our work to formally released
> tarballs, if the upstream project ships them.  I'm relying on gbp

Great! This matches my preferred way too.

> import-orig with an appropriately configured debian/gbp.conf to import
> cryptographically signed upstream tarball releases while pointing back
> to upstream's revision control tags.
> 
> One example workflow that i would like to be able to have easily at my
> disposal as a maintainer is to tell that things are in the tarball that
> are *not* in the upstream revision control system (the other direction:
> looking for things in upstream revision control that didn't get shipped
> in the tarball, is interesting, but a separate question).
> 
> After having verified the cryptographic signatures of the upstream
> tarball, and the upstream release tag, and doing "gbp import-orig", it's
> nice to be able to do (for example):
> 
> git diff --stat gnupg-2.2.43..upstream/2.2.43
> 
> This helps me identify artifacts that we should probably be re-building
> from source.
> 
> By including these generated artifacts in debian/clean, i can ensure
> that during the standard debian build process, they will be necessarily

Wouldn't d/copyright's `Files-Excluded:` work here too? I'm using that
for similar purposes as it even allows to use `gbp import-orig --uscan`
and have things filtered out. `debian/clean` could parse the pattern from
there.

> re-generated (because we run "debian/rules clean" before building).  But
> if i'm including them in debian/clean, then there's no point in keeping
> them in the git packaging directory either.  and i would prefer to avoid
> synchronizing debian/clean and debian/gbp.conf's import-orig.filter
> list.

What if you'd read the filter list in the `clean` target?

I think what you propose is doing it the other way around: Have gbp
run `debian/rules clean` to have a programatical way of filtering?

Cheers,
 -- Guido

> 
>   --dkg
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), 
> (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.23.7
> ii  git1:2.43.0-1+b1
> ii  man-db 2.12.1-1
> ii  python33.11.8-1
> ii  python3-dateutil   2.9.0-2
> ii  python3-pkg-resources  68.1.2-2
> ii  python3-yaml   6.0.1-2
> ii  sensible-utils 0.0.22
> 
> Versions of packages git-buildpackage recommends:
> pn  cowbuilder | pbuilder | sbuild  
> ii  pristine-tar1.50+nmu2
> ii  python3-requests2.31.0+dfsg-1
> 
> Versions of packages git-buildpackage suggests:
> pn  python3-notify2  
> pn  sudo 
> ii  unzip6.0-28
> 
> -- no debconf information

Bug#1070191: New upstream version 1.24.3

[Guido Günther]

Hi Matthias,
> I uploaded this yesterday along with the rest of gtk-rs. However, I didn't
> notice that gst-plugin-gtk4 needs gstreamer-allocator for its dmabuf
> feature.

Thanks for updating the package. I saw the notification but didn't get
to check the package in detail.

> A few questions from my side:
> 
> - Do you just need the source code (i.e the crate) ?

I intend to use it in livi (this is from C) which (very) recently gained
that ability (https://gitlab.gnome.org/guidog/livi/-/merge_requests/51)
so we'd want the gstreamer plugin as well.

> - Do you need the dmabuf feature ?

Yes, this is needed to get zero copy for hw accelerated video
playback. Although for initial testing of the package that would not be
needed.

> - Do you need the gstreamer1.0-gtk4 .so plugin I haven't build yet (from the
> same source) ?

I think that's the bit needed to make use of it from other languages
than rust:

  
https://gitlab.gnome.org/guidog/livi/-/merge_requests/51/diffs#b150b909f5fbd26ccdfcd3165cf0ee05b2760286_1152_1188

(there are more (non rust) video player queuing up to make use of it at
some point).

> I will upload a revision with the dmabuf feature disabled so it can migrate
> to testing.

That's great and already helps! Thanks a lot!

> Let me know what you need for this package so I can adjust the packaging
> accordingly.

Let me know if you need any more details.
Cheer,
 -- Guido

> 
> best,
> 
> 
> -- 
> Matthias Geiger 
> Debian Maintainer
> "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg
> 

Bug#1070330: [Pkg-libvirt-maintainers] Bug#1070330: libvirt: CVE-2024-4418: stack use-after-free in virNetClientIOEventLoop()

[Guido Günther]

control: -1 +pending

Hi,
On Fri, May 03, 2024 at 09:10:23PM +0200, Salvatore Bonaccorso wrote:
> Source: libvirt
> Version: 10.2.0-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for libvirt.
> 
> CVE-2024-4418[0]:
> | stack use-after-free in virNetClientIOEventLoop()
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

See https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/220

Cheers,
 -- Guido

> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2024-4418
> https://www.cve.org/CVERecord?id=CVE-2024-4418
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2278616
> [2] 
> https://gitlab.com/libvirt/libvirt/-/commit/8074d64dc2eca846d6a61efe1a9b7428a0ce1dd1
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
> 

Bug#1068123: Breaks phosh << 0.37.0-2

[Guido Günther]

Hi Jeremy,
On Fri, May 03, 2024 at 09:46:02AM -0400, Jeremy Bícha wrote:
> Control: severity -1 important
> 
> On Sun, Mar 31, 2024 at 6:03 AM Guido Günther  wrote:
> > gnome-session 46 dropped `--builtin` and `--systemd`. This breaks phosh <
> > 0.37.0-2. Would be great to have a proper `Breaks: ` relationship
> > to ease upgrades.
> 
> I'm lowering the severity since phosh 0.38 landed in Testing today and
> it would be good for gnome-session to migrate also. But I can do

I think that's fine.

> another gnome-session upload soon. What exact gnome-session
> binary-package do you think we need to add the Breaks: to? I know that

You mean which binary package? It's gnome-session-binary.

Cheers,
 -- Guido

> Budgie was also affected by the change; that's why budgie-session
> exists now.
> 
> Thank you,
> Jeremy Bícha
> 

Bug#1070172: Exception when invoked without options

[Guido Günther]

Hi,
On Thu, May 02, 2024 at 03:55:53PM +0200, Guido Günther wrote:
> Hi,
> On Wed, May 01, 2024 at 12:27:41PM +0200, Guido Günther wrote:
> > Package: gcovr
> > Version: 7.2-1
> > Severity: grave
> > 
> > Hi,
> > invoking gcovr 7.2 in an empty directory fails like
> > 
> > $ gcovr 
> > --
> >GCC Code Coverage Report
> > Traceback (most recent call last):
> >   File "/usr/bin/gcovr", line 1972, in 
> > print_text_report(covdata)
> >   File "/usr/bin/gcovr", line 822, in print_text_report
> > OUTPUT.write("Directory: "+options.root+"\n")
> >  ~^
> > TypeError: can only concatenate str (not "NoneType") to str
> > 
> > 
> > This makes meson think gcovr is not available, e.g.:
> > 
> >   
> > https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265
> > 
> > I've marked this as grave as it breaks CI pipelines.
> 
> Just had a closer look. It seems verson 3.2 instead of 7.2 got
> imported. I'll propose a fix.

Uploaded to delayed/3. MR is at 
https://salsa.debian.org/debian/gcovr/-/merge_requests/5
Cheers,
 -- Guido
> 
> Cheers,
>  -- Guido
> 
> > 
> > Cheers,
> >  -- Guido
> > 
> > 
> > -- System Information:
> > Debian Release: trixie/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> > 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> > 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: arm64
> > 
> > Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages gcovr depends on:
> > ii  python33.11.6-1
> > ii  python3-pkg-resources  68.1.2-2
> > 
> > gcovr recommends no packages.
> > 
> > gcovr suggests no packages.
> > 
> > -- no debconf information

Bug#1070172: Exception when invoked without options

[Guido Günther]

Hi,
On Wed, May 01, 2024 at 12:27:41PM +0200, Guido Günther wrote:
> Package: gcovr
> Version: 7.2-1
> Severity: grave
> 
> Hi,
> invoking gcovr 7.2 in an empty directory fails like
> 
> $ gcovr 
> --
>GCC Code Coverage Report
> Traceback (most recent call last):
>   File "/usr/bin/gcovr", line 1972, in 
> print_text_report(covdata)
>   File "/usr/bin/gcovr", line 822, in print_text_report
> OUTPUT.write("Directory: "+options.root+"\n")
>  ~^
> TypeError: can only concatenate str (not "NoneType") to str
> 
> 
> This makes meson think gcovr is not available, e.g.:
> 
>   
> https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265
> 
> I've marked this as grave as it breaks CI pipelines.

Just had a closer look. It seems verson 3.2 instead of 7.2 got
imported. I'll propose a fix.

Cheers,
 -- Guido

> 
> Cheers,
>  -- Guido
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: arm64
> 
> Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gcovr depends on:
> ii  python33.11.6-1
> ii  python3-pkg-resources  68.1.2-2
> 
> gcovr recommends no packages.
> 
> gcovr suggests no packages.
> 
> -- no debconf information

Bug#1070191: New upstream version 1.24.3

[Guido Günther]

Source: rust-gst-plugin-gtk4
Severity: wishlist

Hi,
Please update to the new upstream version. 0.12.5 added support for
dmabuf import which can significantly reduce CPU usage.
Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1070172: Exception when invoked without options

[Guido Günther]

Package: gcovr
Version: 7.2-1
Severity: grave

Hi,
invoking gcovr 7.2 in an empty directory fails like

$ gcovr 
--
   GCC Code Coverage Report
Traceback (most recent call last):
  File "/usr/bin/gcovr", line 1972, in 
print_text_report(covdata)
  File "/usr/bin/gcovr", line 822, in print_text_report
OUTPUT.write("Directory: "+options.root+"\n")
 ~^
TypeError: can only concatenate str (not "NoneType") to str


This makes meson think gcovr is not available, e.g.:

  
https://gitlab.gnome.org/World/Phosh/phosh-mobile-settings/-/jobs/3839480#L3265

I've marked this as grave as it breaks CI pipelines.

Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcovr depends on:
ii  python33.11.6-1
ii  python3-pkg-resources  68.1.2-2

gcovr recommends no packages.

gcovr suggests no packages.

-- no debconf information

Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases

[Guido Günther]

Hi Peter,

On Mon, Apr 15, 2024 at 02:28:18PM +0200, Petter Reinholdtsen wrote:
> Dear package maintainer of git-buildpackage,
> 
> Do you have an idea when you will find time to look at this patch?

Sorry, I assumed that it was meant to show the intended result not as an
actual patch proposal (as it doesn't use any of the methods provided by
gbp but shells out via popen). (It *is* helpful to demo the desired
outcome, thanks Gioele).

So is the intended flow to

- import the new upstream version
- fake merge that into the packaging branch (using the "replace" mode
  to avoid any conflicts (e.g. if the upstream source contain a debian/ dir)
- apply the new debian/ on or debian diff on top?

If so a patch that reuses the corresponding bits from import-orig (plus
adjusting the test to verify it) would be very welcome.

Cheers,
 -- Guido

> [Gioele Barabucci 2024-08-19]
> > The attached new patch, although still "quick and dirty", improves the
> > handing of possible modification+deletion conflicts that may arise while
> > merging the the upstream branch into the Debian branch.
> 
> -- 
> Happy hacking
> Petter Reinholdtsen
> 

Bug#1068916: [Debian-on-mobile-maintainers] Bug#1068916: phosh: FTBFS on mips64el, riscv64, s390x: 24/26 phosh:tools / check-exported-symbols FAIL 0.03s exit status 1

[Guido Günther]

Hi Sebastian, Matthias,

On Sat, Apr 13, 2024 at 12:38:59PM +0200, Sebastian Ramacher wrote:
[..snip..]
> 000ec388 gDF .text00a4  Base
> phosh_arrow_get_progress

Thanks for filing this! The failing test is a symbol visibility check to
check that no unwanted symbols are being exported. Basically we check
that we only export the symbols from `phosh-exported-symbols.txt`) which
looks like:

{
   phosh_shell_get_default;

   …

   gtk_filter_list_model_*;
   gtk_sort_list_model_*;
};

Matthias do you have an idea why all the symbols are visible on the
above three architectures but not on others although we don't use
`--export-dynamic`?

This is the relevant linker line from the log at:

https://buildd.debian.org/status/fetch.php?pkg=phosh=mips64el=0.37.1-1=1712010515=0

> [485/1929] cc  -o src/phosh 
> src/phosh.p/meson-generated_.._.._subprojects_libcall-ui_src_cui-enums.c.o 
> src/phosh.p/meson-generated_.._phosh-enums.c.o 
> src/phosh.p/meson-generated_.._phosh-marshalers.c.o 
> src/phosh.p/meson-generated_.._phosh-resources.c.o 
> src/phosh.p/meson-generated_.._dbus_iio-sensor-proxy-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_hostname1-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_portal-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_login1-manager-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_login1-session-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_gsd-color-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_gnome-session-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-gnome-shell-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-display-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-screen-saver-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-screenshot-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-end-session-dialog-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-gtk-mountoperation-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_geoclue-manager-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-wwan-mm-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_calls-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_calls-emergency-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_gnome-session-client-private-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_gnome-session-presence-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_gsd-rfkill-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_mpris-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-wwan-ofono-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-osk0-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_geoclue-agent-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_notify-dbus.c.o 
> src/phosh.p/meson-generated_.._dbus_phosh-idle-dbus.c.o 
> src/phosh.p/meson-generated_.._.._protocol_xdg-shell-protocol.c.o 
> src/phosh.p/meson-generated_.._.._protocol_ext-idle-notify-v1-protocol.c.o 
> src/phosh.p/meson-generated_.._.._protocol_xdg-output-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_input-method-unstable-v2-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_phoc-device-state-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_phoc-layer-shell-effects-unstable-v1-protocol.c.o
>  src/phosh.p/meson-generated_.._.._protocol_phosh-private-protocol.c.o 
> src/phosh.p/meson-generated_.._.._protocol_virtual-keyboard-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-foreign-toplevel-management-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-gamma-control-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-layer-shell-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-output-management-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-output-power-management-unstable-v1-protocol.c.o
>  
> src/phosh.p/meson-generated_.._.._protocol_wlr-screencopy-unstable-v1-protocol.c.o
>  src/phosh.p/main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro 
> -Wl,-z,now -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,--start-group 
> src/libphosh.a src/libphosh-tool.a subprojects/gmobile/src/libgmobile.a 
> subprojects/libcall-ui/src/libcall-ui.a subprojects/gvc/libgvc.a 
> -Wl,--dynamic-list=/<>/src/phosh-exported-symbols.txt 
> /usr/lib/mips64el-linux-gnuabi64/libfribidi.so 
> /usr/lib/mips64el-linux-gnuabi64/libgcr-ui-3.so 
> /usr/lib/mips64el-linux-gnuabi64/libgcr-base-3.so 
> /usr/lib/mips64el-linux-gnuabi64/libgck-1.so 
> /usr/lib/mips64el-linux-gnuabi64/libp11-kit.so 
> /usr/lib/mips64el-linux-gnuabi64/libgtk-3.so 
> /usr/lib/mips64el-linux-gnuabi64/libgdk-3.so 
> /usr/lib/mips64el-linux-gnuabi64/libz.so 
> /usr/lib/mips64el-linux-gnuabi64/libpangocairo-1.0.so 
> /usr/lib/mips64el-linux-gnuabi64/libpango-1.0.so 
> /usr/lib/mips64el-linux-gnuabi64/libharfbuzz.so 
> 

Bug#1068230: [Debian-on-mobile-maintainers] Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Guido Günther]

Hi Praveen,
On Wed, Apr 03, 2024 at 05:58:41PM +0530, Praveen Arimbrathodiyil via 
Debian-on-mobile-maintainers wrote:
> On Tue, 2 Apr 2024 08:04:12 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?=
>  wrote:
> > On Tue, Apr 2, 2024 at 8:03 AM Jeremy Bícha  
> > wrote:
> > >
> > > On Tue, Apr 2, 2024 at 5:31 AM Pirate Praveen  
> > > wrote:
> > > > Recently automatic suspend stopped working. I think this was after 
> > > > gnome settings daemon 46 was available. Some background
> > > > https://salsa.debian.org/Mobian-team/devices/librem5-support/-/issues/7
> > > >
> > > > Not sure if phosh needs some adjustments with recent changes in gnome 
> > > > settings daemon. For now assigned to both.
> > >
> > > Do you have phosh 0.37 or higher installed yet?
> > 
> > Correction: Do you have phosh 0.37.0-2 or 3.7.1-1 installed?
> I still have phosh 0.36.0-1 but auto suspend started working again. So it
> was probably fixed in a recent kernel update.

Thanks for checking! Please always make sure you check for inhibitors
(`gnome-session-inhibit -l`, `systemd-inhibit -l`) to make sure nothing
left a suspend/sleep inhibitor blocking this.

Cheers,
 -- Guido

> 
> Closing this.






> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1068238: ITP: gmobile -- mobile related helpers for glib based projects

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: gmobile
  Version : 0.1.0
  Upstream Contact: The Phosh developers
* URL : https://gitlab.gnome.org/World/Phosh/gmobile
* License : LGPL
  Programming Lang: C
  Description : mobile related helpers for glib based projects

The shared library is used by projects like phosh to determine device
tree compatibles, use suspend robust timers or query cutout and notch 
information.

Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Guido Günther]

Hi,
On Tue, Apr 02, 2024 at 02:32:16PM +0530, Pirate Praveen wrote:
> Package: gnome-settings-daemon,phosh
> severity: serious
> 
> Recently automatic suspend stopped working. I think this was after gnome
> settings daemon 46 was available. Some background
> 

Suspends fine here with phosh 0.37.1 (although notching changed in that
area for a while) and g-s-d 46

Cheers,
 -- Guido

> 
> Not sure if phosh needs some adjustments with recent changes in gnome
> settings daemon. For now assigned to both.
> 
> On kde plasma mobile, automatic suspend still works, so this appears to be
> gnome specific regression.
> 

Bug#1068187: Session fails to start with gnome-session >= 46

[Guido Günther]

Package: phosh
Version: 0.37.1
Severity: grave

gnome-session no longer accepts the --systemd or --builtin arguments
which restults in the session failing to start.

This is already fixed in 0.37.0-2. Mostly filing this to get the version
tracking right.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages phosh depends on:
ii  dconf-gsettings-backend [gsettings-bac  0.40.0-4+b1
kend]
ii  fonts-lato  2.015-1
ii  gnome-shell-common  44.9-1
ii  gsettings-desktop-schemas   46.0-1
ii  libc6   2.37-15
ii  libcairo2   1.18.0-1+b1
ii  libcallaudio-0-10.1.9-1+b1
ii  libcap2-bin 1:2.66-5
ii  libecal-2.0-2t643.50.3-2.2
ii  libedataserver-1.2-27t643.50.3-2.2
ii  libfeedback-0.0-0   0.2.1-1+b1
ii  libfribidi0 1.0.13-3+b1
ii  libgcr-base-3-1 3.41.2-1
ii  libgcr-ui-3-1   3.41.2-1
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii  libglib2.0-0t64 2.78.4-6
ii  libgnome-desktop-3-20t6444.0-5
ii  libgtk-3-0t64   3.24.41-4
ii  libgudev-1.0-0  238-3
ii  libhandy-1-01.8.3-1
ii  libical3t64 3.0.17-1.1
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.46.0-1
ii  libpam0g1.5.2-9.1+b1
ii  libpango-1.0-0  1.52.0+ds-1
ii  libpolkit-agent-1-0 124-1
ii  libpolkit-gobject-1-0   124-1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsecret-1-0   0.21.4-1
ii  libsystemd0 255.4-1
ii  libupower-glib3 1.90.2-8
ii  libwayland-client0  1.22.0-2.1+b1
ii  phoc0.37.0+next20240325.1905.b42258fa.1

Versions of packages phosh recommends:
ii  feedbackd  0.2.1-1+b1
ii  fonts-cantarell0.303.1-1
ii  gnome-session-bin  46.0-1
ii  gnome-session-common   46.0-1
ii  gnome-settings-daemon  46~beta-2
ii  iio-sensor-proxy   3.5-1+b1
ii  librsvg2-common2.54.7+dfsg-2
ii  phosh-mobile-tweaks0.37.0-1
hi  phosh-osk-stub 0.35.0
ii  slurp  1.5.0-1
ii  squeekboard1.24.0-1

phosh suggests no packages.

-- no debconf information

Bug#1068123: Breaks phosh << 0.37.0-2

[Guido Günther]

On Sun, Mar 31, 2024 at 11:59:24AM +0200, Guido Günther wrote:
> Package: gnome-session
> Version: 46.0-1
> Severity: important
> 
> gnome-session 46 dropped `--builtin` and `--systemd`. This breaks phosh <
> 0.37.0-2. Would be great to have a proper `Breaks: ` relationship
> to ease upgrades.

Hi,
I just noticed that gnome-session 46 isn't in testing yet so bumping
severity to not break the current installations. A fixed phosh is about
to be uploade too:

   https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1387

Cheers,
 -- Guido

Bug#1068123: Breaks phosh << 0.37.0-2

[Guido Günther]

Package: gnome-session
Version: 46.0-1
Severity: important

gnome-session 46 dropped `--builtin` and `--systemd`. This breaks phosh <
0.37.0-2. Would be great to have a proper `Breaks: ` relationship
to ease upgrades.
Cheers,
 -- Guido

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-session depends on:
ii  adwaita-icon-theme 46~rc-1
ii  fonts-cantarell0.303.1-1
ii  gnome-session-bin  46.0-1
ii  gnome-session-common   46.0-1
ii  gnome-settings-daemon  46~beta-2
ii  gnome-shell44.9-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.15.1-1
ii  xdg-desktop-portal-phosh [xdg-desktop-portal-backend]  0.0.0
ii  xdg-desktop-portal-wlr [xdg-desktop-portal-backend]0.7.1-1

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base   12.0.6+nmu1
ii  gnome-keyring  42.1-1+b2

-- no debconf information

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Guido Günther]

Hi Sebastian, Carsten,
On Fri, Mar 22, 2024 at 08:34:29AM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-03-08 22:10:10 [+0100], Carsten Schoenert wrote:
> > Hello Guido,
> Hi,
> 
> > On Tue, Jan 30, 2018 at 07:19:48AM +0100, Carsten Schoenert wrote:
> > > > We should not do more options. Multi threaded should be on when:
> > > > 
> > > >   - not using pristine-tar
> > > >   - iff pristine-tar can handle it
> > > > 
> > > > The first one is simple but what about the second?
> > 
> > the mentioned issue #888572 was closed some time ago so pristine-tar
> > shouldn't be a problem here anymore.
> > 
> > I will try to tweak gbp locally now again while working on a new version
> > of kicad-packages3d which will be about 5GB now to archive. ;)
> 
> I got pointed here by Amin.
> As mentioned, pristine-tar can handle multi-block xz images so this is
> not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing)
> is using multi threaded compression by default. So this *might* be
> considered fixed.

Thanks a lot for the follow up. Carsten can you confirm with TB if this works as
expected?
Cheers,
 -- Guido

Bug#1066030: Please move packagekit plugin to Recommends

[Guido Günther]

Package: gnome-software
Version: 46~beta-1
Severity: wishlist

Hi,

Would it be possible to move

/usr/lib/*/gnome-software/plugins-20/libgs_plugin_packagekit.so

and related files to a separate package and make it a Recommends rather
than a dependency?

This would allow to use gnome-software without package kit for
e.g. managing flatpaks only.

This is useful on device with restricted resources like phones where the
packagekit backend takes lots of RAM and slows down initial app startup
although it's often not used since people use `apt` for the OS side
packages.

Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-software depends on:
ii  appstream1.0.2-1
ii  apt-config-icons 1.0.2-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
pn  gnome-software-common
ii  gsettings-desktop-schemas46~beta-3
ii  libadwaita-1-0   1.5~beta-1
pn  libappstream4
ii  libappstream51.0.2-1
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libfwupd21.9.14-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0t64 [libglib2.0-0]   2.78.4-2.1
ii  libgtk-4-1   4.12.5+ds-3
ii  libgtk3-perl 0.038-3
ii  libgudev-1.0-0   238-3
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmalcontent-0-00.11.1-1+b2
ii  libpackagekit-glib2-18   1.2.8-2
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpolkit-gobject-1-0124-1
ii  libsoup-3.0-03.4.4-5
ii  libxmlb2 0.3.15-1
ii  packagekit   1.2.8-2
pn  software-properties-gtk  

Versions of packages gnome-software recommends:
ii  fwupd  1.9.14-1

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- Configuration Files:
/etc/xdg/autostart/org.gnome.Software.desktop [Errno 2] No such file or 
directory: '/etc/xdg/autostart/org.gnome.Software.desktop'

Bug#1065519: Feedback

[Guido Günther]

Hi Evan,
On Wed, Mar 06, 2024 at 04:28:40PM -0500, no-re...@ejrdesign.co.za wrote:
> > > This is odd: I can't seem to find this error message in the
> > > rockchip_drm_vop2 mainline driver. Are you using a vendor kernel? If
> > > so which one exactly?
> 
> I am not sure... I downloaded the Debian image
> (Orangepicm4_1.0.4_debian_bookworm_desktop_xfce_linux5.10.160.7z) from
> https://drive.google.com/drive/folders/1MJl-pIU2I7EHDN6rlirumVkBOz7utvyE
> and

Ah...that's what they link from

   
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-CM4-1.html

and they also have links to their build scripts there.

> Mar 06 21:21:59 orangepicm4 phoc[3137]: Failed to create server: Could not
> create backend
> Mar 06 21:22:04 orangepicm4 phoc[3883]: [libseat] [seatd/seat.c:39] Created
> VT-bound seat seat0
> Mar 06 21:22:04 orangepicm4 phoc[3883]: [libseat] [seatd/server.c:145] New
> client connected (pid: 3855, uid: 1000, gid: 1000)

Thanks. Unfortunately this doesn't contain the desired output. Is there
a way to get ssh access to such a device?
Cheers,
 -- Guido

Bug#1065519: [Debian-on-mobile-maintainers] Bug#1065519: phosh-full: Phosh not booting on login or from cmd on OrangePi

[Guido Günther]

control: reassign -1 phoc

Hi Evan,

The problem is that the compositor can't start:

On Tue, Mar 05, 2024 at 08:46:24PM +, Evan Robinson wrote:
[..snip..]

> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [common/terminal.c:162] 
> Could not open target tty: Permission denied
> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [seatd/seat.c:61] Could not 
> open tty0 to update VT: Permission denied
> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [common/terminal.c:162] 
> Could not open target tty: Permission denied
> Mar 05 20:33:38 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
> Unsupported linear format at Cluster0-win0
> Mar 05 20:33:38 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
> Unsupported linear format at Cluster0-win0

This is odd: I can't seem to find this error message in the
rockchip_drm_vop2 mainline driver. Are you using a vendor kernel?
If so which one exactly?

> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [seatd/seat.c:72] Could not 
> open terminal for VT 0: Permission denied
> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [seatd/seat.c:461] Could 
> not open VT for client
> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [common/terminal.c:162] 
> Could not open target tty: Permission denied
> Mar 05 20:33:38 orangepicm4 phoc[3244]: [libseat] [seatd/seat.c:86] Could not 
> open terminal to clean up VT 0: Permission denied
> Mar 05 20:33:40 orangepicm4 lightdm[3258]: pam_unix(lightdm-greeter:session): 
> session opened for user lightdm(uid=110) by (uid=0)
[..snip..]

You seem to have lightdm still running but use phosh.service. Please
stop lightdm to make sure they don't race for the same tty.

> Mar 05 20:33:48 orangepicm4 phoc[3188]: [backend/backend.c:107] Timeout 
> waiting session to become active
> Mar 05 20:33:48 orangepicm4 phoc[3188]: [backend/backend.c:272] failed to 
> start a session
> Mar 05 20:33:48 orangepicm4 phoc[3188]: [backend/backend.c:322] failed to add 
> backend 'drm'
> Mar 05 20:33:48 orangepicm4 phoc[3244]: [libseat] [common/terminal.c:162] 
> Could not open target tty: Permission denied
> Mar 05 20:33:48 orangepicm4 phoc[3244]: [libseat] [seatd/seat.c:86] Could not 
> open terminal to clean up VT 0: Permission denied
> Mar 05 20:33:48 orangepicm4 phoc[3188]: Failed to create server: Could not 
> create backend
> Mar 05 20:33:48 orangepicm4 systemd[1]: phosh.service: Main process exited, 
> code=exited, status=1/FAILURE
> Mar 05 20:33:48 orangepicm4 systemd[1]: phosh.service: Failed with result 
> 'exit-code'.
> Mar 05 20:33:48 orangepicm4 systemd[1]: phosh.service: Triggering OnFailure= 
> dependencies.

To debug further could you create a .phoshdebug file in your users $HOME
with:

  G_MESSAGES_DEBUG=phoc-wlroots
  export G_MESSAGES_DEBUG

(if you didn't change phosh.service the relevant user is the one with
uid 1000). Then

  systemctl stop phosh
  systemctl start phosh

and get the logs from that one. To shorten the log you can use

  journalctl _COMM=phoc

as the other processes don't matter atm.

Cheers,
 -- Guido

Bug#1065430: ITP: phosh-wallpapers -- Phosh Wallpapers and other artwork

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: phosh-wallpapers
  Version : 0.37.0
  Upstream Contact: Guido Günther 
* URL : https://gitlab.gnome.org/guidog/phosh-wallpapers
* License : GPL, CC-BY-SA-4
  Description : Phosh Wallpapers and other artwork

This package contains the current wallpapers and plymouth theme.

Bug#1010751: clone: handle -b optional branch specification in VCS-Git

[Guido Günther]

Hi,
On Thu, Feb 29, 2024 at 10:49:32PM +0100, Nicolas Boulenguez wrote:
> Package: git-buildpackage
> Followup-For: Bug #1010751
> 
> Ping?

I'll have a look over the next days (I missed your last update).
Cheers,
 -- Guido

Bug#1064373: [Debian-on-mobile-maintainers] Bug#1064373: squeekboard: Depends on obsolete rust-gtk

[Guido Günther]

Hi Jeremy,
GTK4 lacks API to be make it usable as on screen keyboard (see
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5628) so I assume
this is unlikely to happen. It could switch to something like
gtk4-layer-shell as work around though.

(I'm not a squeekboard maintainer so this is just my PoV about the
current state of affairs).

Phosh has an alternative OSK (phosh-osk-stub) which would prevent
removal of the whole stack from Debian when rust-gtk goes away.

Cheers,
 -- Guido

On Tue, Feb 20, 2024 at 05:19:34PM -0500, Jeremy Bícha wrote:
> Source: squeekboard
> Version: 1.22.0-5
> Severity: important
> Tags: upstream trixie sid
> Forwarded: https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/64
> 
> rust-gtk (the old GTK3 bindings) are no longer maintained. Squeekboard
> is the last thing keep rust-gtk in Debian. Please switch to rust-gtk4.
> 
> Thank you,
> Jeremy Bícha
> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1061616: New upstream version 0.43.0

[Guido Günther]

Source: pixman
Version: 0.42.2-1
Severity: wishlist

There's a new upstream version. It seems pixman gave up on the odd/even split:

   https://gitlab.freedesktop.org/pixman/pixman/-/issues/87#note_2243045

It seems there's some details to be sorted out but e.g. having it in
expermental would be awesome as wlroots is about to bump it's dependency.
Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1060658: [Debian-on-mobile-maintainers] Bug#1060658: Bug#1060658: megapixels don't start could not find any config file

[Guido Günther]

Hi,
On Wed, Jan 17, 2024 at 02:17:53PM +0530, Pirate Praveen wrote:
> 
> 
> On 16/01/24 10:01 pm, Arnaud Ferraris wrote:
> > Hi,
> > 
> > Le 12/01/2024 à 10:37, Pirate Praveen a écrit :
> > > Package: megapixels
> > > Version: 1.7.0-1
> > > Severity: grave
> > > 
> > > Running megapixels from commandline on mobian trixie fails with this error
> > > 
> > > /usr/share/megapixels/config/purism,librem5r4.ini not found.
> > 
> > This is expected, megapixels doesn't support the L5 (yet?).
> 
> I was looking at a blog post for QR code readers and mega pixel was
> mentioned
> 
> https://forums.puri.sm/t/qr-code-scanning-via-megapixels/14408
> 
> Found another reference now https://blog.brixit.nl/megapixels-2-0/
> 
> but seems this never finished.

On the L5 you can use millipixels (which is a fork of megapixels) for QR
code scanning. I've filed #1060921 to track L5 support in megapixels.

Cheers,
 -- Guido

> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1060921: Please support the Librem5's cameras

[Guido Günther]

Package: megapixels
Version: 1.7.0-1
Severity: wishlist
Tags: upstream

Dear Maintainers,

as noted in #1060658 there's no support for any of the Librem 5 cameras
yet. It would be great if megapixels would support them out of the box
as at least the selfie cam driver and the necessary SoC bits are in the
mainline kernel already.

(Hopefully this issue helps to avoid confusion regarding expected device 
support)

Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.5.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages megapixels depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  libc62.37-13
ii  libepoxy01.5.10-1+b2
ii  libfeedback-0.0-00.2.1-1+b1
ii  libglib2.0-0 2.78.3-1
ii  libgtk-4-1   4.12.4+ds-3
pn  libraw-bin   
ii  libtiff6 4.5.1+git230720-3
ii  libwayland-client0   1.22.0-2.1
ii  libx11-6 2:1.8.7-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libzbar0 0.23.92-9

Versions of packages megapixels recommends:
ii  imagemagick  8:6.9.12.98+dfsg1-5
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5
ii  libimage-exiftool-perl   12.70+dfsg-1

megapixels suggests no packages.

Bug#1060371: git-buildpackage: feature request: gbp sync

[Guido Günther]

Hi,
On Wed, Jan 10, 2024 at 03:06:05PM +0800, Otto Kekäläinen wrote:
> Package: git-buildpackage
> Severity: wishlist
> 
> Hi!
> 
> I frequently find myself doing manual work comparing if my local git
> repository contents and tags are correct and in sync with the git
> remotes and the Debian and Ubuntu archives.
> 
> I am worried about mistakes such as:
> 
> - A maintainer tagged and uploaded but forgot to push it to remote git
> repositories
> 
> - Maintainer git tagged a version that failed to upload, and then
> forgot to delete and re-tag after fix and new upload attempt, or I did
> locally fix the tag to point to correct contents put forgot to force
> push updated tag to git remotes
> 
> - Somebody else than the regular maintainer uploaded but didn't push
> to git and git repository content is behind Debian/Ubuntu apt
> repositories
> 
> - Somebody (e.g. Ubuntu sponsor) modified the package before upload,
> and git repository diverges from apt repository
> 
> 
> To automatically detect (and perhaps even fix) these situations I
> propose git-buildpackage adds a feature 'gbp sync' which would roughly
> have this logic:
> 
> 1. Traverse past 8 or so debian/changelog entries, extract
> Debian/Ubuntu release name and version and check if equivalent git
> tags exist locally.
> 
> 2. Compare to remotes and warn if any tags are missing locally, or
> remotes have more tags than local, or tags point to different commits.
>
> 3. Check from equivalent apt repositories (including -security,
> -updates, -proposed-updates) what versions they have and warn if apt
> repositories have releases missing from the debian/changelog, or if
> past local changelog entries seems to never have reached any apt
> repository.

…skipping binNMUs ?

> 4. While doing the above, also download the . dsc files to a local
> temporary directory. Using the checksums in the .dsc files verify that
> the apt repository .debian.tar checksum matches what the locally
> tagged git commit debian/ contents would produce. This verifies the
> uploaded version actually is the same as in the gbp tag.
> 
> 5. If everything matches, emit a success message. If not, tell users
> what is out of sync and ask the user (maintainer) to manually fix and
> validate fixes by rerunning 'gbp sync'.

I agree that this sort of validation/fix would make sense.

Somewhat related is /usr/share/doc/git-buildpackage/examples/gbp-upload
which helps to ensure that tags end up in the blessed repo when doing an
upload.

Cheers,
 -- Guido

> 
> 
> This could also be a separate tool, but since git-buildpackage has
> such an extensive test suite and mature code base, and the tool would
> operate off the semantics of gbp.conf seems this could be an useful
> extension to git-buildpackage.
> 
> - Otto
> 

Bug#829444: Use DEP14 branch layout by default

[Guido Günther]

Hi,
On Fri, Jan 05, 2024 at 12:25:24PM +0800, Otto Kekäläinen wrote:
> Hi and Happy New Year!
> 
> Using 'debian/latest' instead of 'master' by default in
> git-buildpackage would still make sense.

It does. Thanks for looking into this. I'll add some details below:

> 
> I started drafting a PR at
> https://github.com/agx/git-buildpackage/pull/93 to implement this, but
> it takes a while to read through and understand all the 500+ mentions
> of string 'master' and which of these refer to default Debian branch
> and which not.
> 
> I have been using the debian/latest convention from DEP-14[1] in all
> my packages for several years now. This is the scheme I follow based
> on what I find most practical:
> 
> - debian/latest
> - debian/12-bookworm
> - debian/11-bullseye
> - debian/11-bullseye-backports
> - debian/10-buster
> - ubuntu/23.10-mantis
> - ubuntu/22.04-focal
> 
> Having the release number in addition to to code name makes it easier
> for contributors to choose the correct branch for Merge Requests, and
> also ensures they are nicely sorted in chronological order in branch
> listings.
> 
> The upstream branch name is whatever upstream uses (typically master,
> main or a version branch or tag, e.g. 10.11 or 5.5).

I'd prefer (as noted above) "upstream/latest" as the new default here as
that has less potential to cause havoc.

What we need to figure out is a way to distinguish "old" style
repos (default upstream and master (or what gbp.conf provides) with
newly created ones (default debian/latest and upstream/latest or what
gbp.conf provides).

Likely the best way to do so is to add a `gbp.conf` option:

`layout = [legacy|dep14]`

defaulting to `legacy` if unset.  We can then emit a warning and
deprecate the legacy layout when `layout` is unset and any of
`upstream-branch`, `debian-branch` is unset. We can also back that up
with tests. At a later point we can switch the default.

A related issue is interoperability between different gbp versions but
when collaborating in a team but I think we can at least manage to not
break anything when the new defaults don't overlap with the old ones
(this would be o.k for {debian,upstream}/latest).

Cheers,
 -- Guido

> 
> For reference these are the gbp.conf changes I use for maintenance branches:
> 
> ± git diff debian/latest..ubuntu/23.10-mantic debian/gbp.conf
> diff --git a/debian/gbp.conf b/debian/gbp.conf
> index c82f832717a..bfdfe73742c 100644
> --- a/debian/gbp.conf
> +++ b/debian/gbp.conf
> @@ -8,7 +8,9 @@ sign-tags = True
>  upstream-signatures = on
> 
>  # DEP-14 format
> -debian-branch = debian/latest
> +debian-branch = ubuntu/23.10-mantic
> +debian-tag = ubuntu/%(version)s
> +debian-tag-msg = %(pkg)s Ubuntu release %(version)s
>  upstream-branch = 10.11
>  upstream-tag = mariadb-%(version)s
> 
> The proposal by Raphaël to support %(vendor) would help automate the
> debian-tag and debian-tag-msg so they don't need to be customized per
> branch.
> 
> 
> [1] https://dep-team.pages.debian.net/deps/dep14/
> 

Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")

[Guido Günther]

Hi,
On Sat, Dec 23, 2023 at 05:09:48PM +0100, Gioele Barabucci wrote:
> Control: tags -1 patch
> 
> Hi Guido,
> 
> On 23/12/23 16:57, Guido Günther wrote:
> > > the gbp-import-dsc script crashes while parsing changelogs that include 
> > > leap
> > > seconds.
> > > 
> > > dateutil.parser._parser.ParserError: second must be in 0..59: Sun,  1 Jan
> > > 2006 00:59:60 +0100
> > 
> > This looks like a bug in dateutil, can you reassign there?
> 
> Not really:
> 
> > > As of 2023-12 there is an open issue asking for support for leap seconds 
> > > in
> > > dateutils [3].

Ah...I missed that one. We should work around it in gbp then.

>  from gbp.git.modifier import GitModifier   # noqa: F401
> @@ -41,7 +42,11 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
>  >>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
>  '888479400 +0100'
>  """
> +rfc822_date_orig = rfc822_date
> +rfc822_date = rfc822_date.replace(":60 ", ":59 ")
>  d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
> +if rfc822_date != rfc822_date_orig: # Handle leap seconds.
> +d += datetime.timedelta(seconds=1)

That works. Could you add a line to the doctest in that function too so
we check for and don't break it on accident again. Otherwise I can do it
when applying the patch.

Cheers,
 -- Guido

>  seconds = calendar.timegm(d.utctimetuple())
>  tz = d.strftime("%z")
>  return '%d %s' % (seconds, tz)
> -- 
> 2.43.0
> 

Bug#912725: [Pkg-libvirt-maintainers] Bug#912725: virtinst: Please demote virtinst recommends on virt-viewer to suggests

[Guido Günther]

Hi,
On Tue, Dec 26, 2023 at 01:27:11PM -0800, Matt Taggart wrote:
[..snip..]
> Interestingly, the virt-manager package only Suggests virt-viewer but, if
> anything, I would think the dependency would be stronger there? So maybe
> Recommends or even Depends? But I guess it's possible to use virt-manager to
> manage VMs without ever needing to launch virt-viewer, so maybe Suggests is
> correct there as well.

virt-manager merely suggests virt-viewer since it's basically a useful
tool to have too (virt-manager doesn't need virt-viewer to show any
consoles) so a very weak relation makes sense

virtinst recommends virt-viewer so people installing it get a set of
tools to install VMs and connect to their UI so a stronger relation
looks justified to me.

It's not a dependency as (as you note) there are use cases where it
works without virt-viewer but the default should (in my opinion) be
to have a working set and not let the user figure out why they can't
connect to their VMs UI.

Cheers,
 -- Guido

> 
> For those running into this, the work around is to use
> '--no-install-recommends' as Karl mentioned in the original report.
> 
> Thanks,
> 
> -- 
> Matt Taggart
> m...@lackof.org
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
> 

Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")

[Guido Günther]

Hi,
On Sat, Dec 23, 2023 at 04:48:51PM +0100, Gioele Barabucci wrote:
> Package: git-buildpackage
> Version: 0.9.33
> 
> Dear git-buildpackage maintainer,
> 
> the gbp-import-dsc script crashes while parsing changelogs that include leap
> seconds.
> 
> For example, while parsing the changelog of unicode/5.0, gbp-import-dsc
> crashes with
> 
> ```
>   File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 116,
> in get_author_from_changelog
> date = rfc822_date_to_git(dch.date, fuzzy=True)
>
>   File "/usr/lib/python3/dist-packages/gbp/git/__init__.py", line 44, in
> rfc822_date_to_git
> d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
> ^^^
>   File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line
> 1368, in parse
> return DEFAULTPARSER.parse(timestr, **kwargs)
>^^
>   File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py", line
> 651, in parse
> six.raise_from(ParserError(str(e) + ": %s", timestr), e)
>   File "", line 3, in raise_from
> dateutil.parser._parser.ParserError: second must be in 0..59: Sun,  1 Jan
> 2006 00:59:60 +0100
> ```

This looks like a bug in dateutil, can you reassign there?
Cheers,
 -- Guido

> 
> Leap seconds (:60) are explicitly permitted by Debian Policy [1] and RFC
> 5322 [2] and produced by `date -R`.
> 
> As of 2023-12 there is an open issue asking for support for leap seconds in
> dateutils [3].
> 
> A possible solution to this issue, suggested by olasd, would to parse the
> date using the stdlib method `email.utils.parsedate_tz` and handle the leap
> seconds manually:
> 
> ```
> import email, datetime
> 
> add_leap_second = False
> dateinfo = list(email.utils.parsedate_tz(rfc822_date))
> if dateinfo[5] == 60:
> dateinfo[5] = 59
> add_leap_second = True
> 
> date = datetime.datetime(*dateinfo[:6])
> 
> if add_leap_second:
> date += datetime.timedelta(seconds=1)
> ```
> 
> Alternatively:
> 
> ```
> dhc_date = dch.date.replace(":60 ", ":59 ")
> date = rfc822_date_to_git(dch.date, fuzzy=True)
> if dch_date != dch.date:
> date += datetime.timedelta(seconds=1)
> ```
> 
> Regards,
> 
> [1] «ss is the two-digit seconds (00-60)»
> https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
> 
> [2] «the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
> number of seconds allowing for a leap second; see [RFC1305])»
> https://datatracker.ietf.org/doc/html/rfc5322#section-3.3
> 
> [3] https://github.com/dateutil/dateutil/issues/1018
> 
> -- 
> Gioele Barabucci
> 

Bug#1058496: sway: Please update to wlroots 0.17

[Guido Günther]

Hi Diederik,
On Fri, Dec 15, 2023 at 04:59:40PM +0100, Diederik de Haas wrote:
> On dinsdag 12 december 2023 18:44:25 CET you wrote:
> > Please update sway to work with wlroots 0.17. 0.17.0 is currently in
> > experimental an will be uploaded to unstable by the end of December 2023.
> 
> FYI: I looked a bit into this issue and after having applied 1 upstream 
> commit 
> and backported a second, I got the following compile error:
> 
> ```
> ../sway/lock.c: In function ‘handle_output_commit’:
> ../sway/lock.c:53:18: error: ‘struct wlr_output_event_commit’ has no member 
> named ‘committed’
>53 | if (event->committed & (
>   |  ^~
> ../sway/lock.c: In function ‘destroy_lock_surface’:
> ../sway/lock.c:69:65: error: ‘struct wlr_session_lock_surface_v1’ has no 
> member named ‘mapped’
>69 | if (other != surf->lock_surface && other-
> >mapped) {
>   | ^~
> ../sway/lock.c: In function ‘handle_new_surface’:
> ../sway/lock.c:114:44: error: ‘struct ’ has no member named ‘map’
>   114 | wl_signal_add(_surface->events.map, >map);
>   |^
> ../sway/lock.c:120:50: error: ‘struct ’ has no member named ‘mode’
>   120 | wl_signal_add(>wlr_output->events.mode, 
> >output_mode);
> ```
> 
> After backporting the second I got a bad _feeling_ that this strategy may be 
> used to get it to compile, but would that still make it run (properly)?
> 
> The 'map' issue may be fixed by backporting the following commit:
> https://github.com/swaywm/sway/commit/c9e1dab3187d22ada0232d699e759a628e0ed185
> but this is quite an extensive one.
> 
> While researching this I also noticed several commits titled
> "chase wlroots ..." like commit 6f6b82793d95e3c10d54bcf21ca3f0c76c44b882 
> referencing an upstream wlroots MR with the 'breaking' label attached to it.

There's a larger amount of API changes that are needed for the 0.16 ->
0.17 switch, see


https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3527#breaking-changes-for-compositors

so I agree: trying to backport that is a considerable amount
f work. I'd either look at packaging a 1.9 git snapshot and maybe check
with upstream if they intend to release a 0.17 based version.

AFAIK sway's development branch tracks the current (in development)
0.18.x already (which will be another soname bump).

Cheers,
 -- Guido

Bug#1057766: Osk button missing after startup

[Guido Günther]

Package: phosh
Version: 0.34.0-1
Severity: grave

There's a regression in phosh 0.34.0 that prevents the button to
manually unfold the OSK after startup. Let's block testing migration
as this makes many apps unusable for some people.

Likely fixed via 
https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1332

 -- Guido



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages phosh depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  fonts-lato   2.015-1
ii  gnome-shell-common   44.5-2
ii  gsettings-desktop-schemas45.0-2
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libcallaudio-0-1 0.1.9-1
ii  libecal-2.0-23.50.1-1
ii  libedataserver-1.2-273.50.1-1
ii  libfeedback-0.0-00.2.1-1
ii  libfribidi0  1.0.13-3
ii  libgcr-base-3-1  3.41.1-3
ii  libgcr-ui-3-13.41.1-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.1-4
ii  libgnome-desktop-3-2044.0-2
ii  libgtk-3-0   3.24.38-6
ii  libgudev-1.0-0   238-3
ii  libhandy-1-0 1.8.2-3
ii  libical3 3.0.17-1
ii  libjson-glib-1.0-0   1.8.0-2
ii  libnm0   1.44.2-3
ii  libpam0g 1.5.2-9.1
ii  libpango-1.0-0   1.51.0+ds-3
ii  libpolkit-agent-1-0  123-3
ii  libpolkit-gobject-1-0123-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-2+b1
ii  libpulse016.1+dfsg1-2+b1
ii  libsecret-1-00.21.1-1
ii  libsystemd0  254.5-1
ii  libupower-glib3  1.90.2-6
ii  libwayland-client0   1.22.0-2.1
ii  phoc 0.34.0~beta1+ds-2~exp1

Versions of packages phosh recommends:
ii  feedbackd  0.2.1-1
ii  gnome-session-bin  45.0-2
ii  gnome-session-common   45.0-2
ii  gnome-settings-daemon  45.0-1
ii  iio-sensor-proxy   3.5-1
ii  phosh-mobile-tweaks0.33.0-1
ii  phosh-osk-stub 0.34.0-1
ii  phosh-plugins  0.34.0-1
ii  slurp  1.4.0-1
ii  squeekboard1.22.0-5

phosh suggests no packages.

-- no debconf information

Bug#908204: git-buildpackage: cannot use gbp push without tagging a release

[Guido Günther]

Hi Carlos,
On Fri, Dec 08, 2023 at 12:58:41AM -0300, Carlos Henrique Lima Melara wrote:
> Hi,
> 
> I'm working with a lot of newcommers in the Debian Brasília community
> and learning packaging (and a myriad of tools that come with it) is
> quite overwhelming. So we try to streamline things to make packaging a
> little easier. gbp is a awesome tool (thanks!) because it simplifies
> working with git, but the problem comes with the combination of working
> with forks+mr (remember, newcommers) and importing new upstream
> releases. gpb push fails because there is no tag in the debian branch
> (but we want an unreleased and untagged push to the fork so an MR can be
> opened). The alternative is to teach them pushing with plain old git,
> but they always forget to push the upstream/pristine-tar branches.
> 
> Also, I too work with multiple computers and with the fork+mr workflow
> so being able to just gbp push would be wonderful. git push --all is not
> ok because often I have a patch-queue branch that I don't want on salsa
> and also upstream branches sometimes coexist.
> 
> S, it would be really nice to at least have a flag --tips or --head
> in gbp to do all the work for me.

I think

   gbp  push --debian-tag='' 

does what you want. Note that this doesn't change anything for
pristine-tar / upstream) which is usually the desired effect.

Cheers,
 -- Guido

> 
> Cheers,
> Charles

Bug#1055345: git-buildpackage: Please document how to build against a package from experimental

[Guido Günther]

Hi,
On Mon, Nov 13, 2023 at 10:40:50AM +0100, Martin Quinson wrote:
> Le dimanche 12 novembre 2023 à 21:00 +0100, Guido Günther a écrit :
> > Hi,
> > On Sun, Nov 05, 2023 at 09:18:58PM +0100, Martin Quinson wrote:
> > > Le dimanche 05 novembre 2023 à 17:27 +0100, Guido Günther a écrit :
> > > 
> > > > 
> > > > What about suggesting to bootstrap a new environment instead via:
> > > > 
> > > >    DIST=experimental git-pbuilder create 
> > > > 
> > > > This also handles adding experimental to /etc/apt/sources.list (no extra
> > > > setup needed). Maybe we can streamline things that way a bit?
> > > 
> > > This has the drawback of taking all dependencies from experimental, which
> > > may
> > > not be what one wants.
> > 
> > Is that that the case? I didn't see where in the chroot that would be
> > configured. Can you point me to it?
> 
> I must confess that I didn't experiment with this approach because I was 
> afraid
> it would give me all packages from experimental while it was not what I 
> wanted.
> Only afraid of, not sure at all. The truth is that I have no idea.

I've checked that the above works as expected and only required packages
are taken out of experimental (with the dependency resolve set as
suggested earlier). Do you want to update the docs accoring to that,
that would be great!
Cheers,
 -- Guido

> 
> I am sorry for the false info if I was wrong.
> 
> Thanks for your time,
> Mt

Bug#1055345: git-buildpackage: Please document how to build against a package from experimental

[Guido Günther]

Hi,
On Sun, Nov 05, 2023 at 09:18:58PM +0100, Martin Quinson wrote:
> Le dimanche 05 novembre 2023 à 17:27 +0100, Guido Günther a écrit :
> > Hi Martin,
> > On Sat, Nov 04, 2023 at 04:43:10PM +0100, Martin Quinson wrote:
> > > Package: git-buildpackage
> > > Version: 0.9.32
> > > Severity: wishlist
> > > Tags: patch
> > > 
> > > Hello,
> > > 
> > > thanks a lot for this package, that very often saves my life when
> > > packaging.
> > > There is one thing however where gbp could be more helpful, it's when I
> > > have to
> > > build my package against a build-depend that comes from experimental.
> > > 
> > > I finally found a way to do it, and I propose the following patch for the
> > > documentation for the next person looking for this information. I fully
> > > acknowledge that this documentation is somehow suboptimal, and that the 
> > > gbp
> > > tool could be more helpful here, but the proposed documentation would
> > > already
> > > be great.
> > 
> > Thanks for taking the time to document this. Some minor nits below:
> > 
> > 
> > > ---
> > >  docs/chapters/special.xml |   25 +
> > >  1 file changed, 25 insertions(+)
> > > 
> > > Index: b/docs/chapters/special.xml
> > > ===
> > > --- a/docs/chapters/special.xml
> > > +++ b/docs/chapters/special.xml
> > > @@ -40,6 +40,31 @@
> > >  
> > >  
> > >  
> > > +    
> > > +    Using build-depends from experimental
> > > +    
> > 
> > This should mention that one ought to use `gbp buildpackage
> > --git-pbuilder` (as that is not the default).
> 
> Agreed.
> 
> > > +    To build your package against a build-depends taken from 
> > > experimental,
> > > you first need
> > > +    to configure your pbuilder. To that extend, add the following to
> > > +    ~/.pbuilderrc to instruct pbuilder to take build
> > > depends from
> > > +    experimental when they cannot be satisfied from unstable.
> > > +    
> > > +    
> > > +PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-
> > > experimental
> > > +    
> > 
> > Wouldn't we want to make that conditional like:
> > 
> > if [ "$GBP_DIST" = "experimental" ]; then
> >     echo "Using 'pbuilder-satisfydepends-experimental' for $GBP_DIST"
> >     PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-
> > experimental
> > fi
> 
> Nice addition, thanks.
> 
> > but I *think* this is even the default nowadays for building against
> > experimental.
> > 
> > > +    
> > > +    You then need to add experimental to the apt configuration within the
> > > chroot.
> > > +    The simplest for that is to edit the config file from outside of the
> > > chroot directly,
> > > +    as follows:
> > > +    
> > > +sudo bash -c "echo 'deb http://deb.debian.org/debian experimental main' 
> > > >>
> > > /var/cache/pbuilder/base.cow/etc/apt/sources.list"
> > > +    
> > 
> > What about suggesting to bootstrap a new environment instead via:
> > 
> >    DIST=experimental git-pbuilder create 
> > 
> > This also handles adding experimental to /etc/apt/sources.list (no extra
> > setup needed). Maybe we can streamline things that way a bit?
> 
> This has the drawback of taking all dependencies from experimental, which may
> not be what one wants.

Is that that the case? I didn't see where in the chroot that would be
configured. Can you point me to it?

Cheers,
 -- Guido

> 
> I agree that things could be streamlined in the tool, but documenting how to
> get around the corner with the current tools is already great, IMHO.
> 
> Thanks,
> Mt

Bug#1055345: git-buildpackage: Please document how to build against a package from experimental

[Guido Günther]

Hi Martin,
On Sat, Nov 04, 2023 at 04:43:10PM +0100, Martin Quinson wrote:
> Package: git-buildpackage
> Version: 0.9.32
> Severity: wishlist
> Tags: patch
> 
> Hello,
> 
> thanks a lot for this package, that very often saves my life when packaging.
> There is one thing however where gbp could be more helpful, it's when I have 
> to
> build my package against a build-depend that comes from experimental.
> 
> I finally found a way to do it, and I propose the following patch for the
> documentation for the next person looking for this information. I fully
> acknowledge that this documentation is somehow suboptimal, and that the gbp
> tool could be more helpful here, but the proposed documentation would already
> be great.

Thanks for taking the time to document this. Some minor nits below:

> 
> Again, thanks for this great tool and for your time.
> Mt
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (90, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.23.6
> ii  git    1:2.40.1-1
> ii  man-db 2.11.2-3
> ii  python3    3.11.4-5+b1
> ii  python3-dateutil   2.8.2-3
> ii  python3-pkg-resources  68.1.2-1
> ii  python3-yaml   6.0.1-1
> ii  sensible-utils 0.0.20
> 
> Versions of packages git-buildpackage recommends:
> ii  cowbuilder    0.89
> ii  pbuilder  0.231
> ii  pristine-tar  1.50
> ii  python3-requests  2.31.0+dfsg-1
> 
> Versions of packages git-buildpackage suggests:
> ii  python3-notify2  0.3-5
> ii  sudo 1.9.14p2-1
> ii  unzip    6.0-28
> 
> -- no debconf information
> 

> ---
>  docs/chapters/special.xml |   25 +
>  1 file changed, 25 insertions(+)
> 
> Index: b/docs/chapters/special.xml
> ===
> --- a/docs/chapters/special.xml
> +++ b/docs/chapters/special.xml
> @@ -40,6 +40,31 @@
>  
>  
>  
> +
> +Using build-depends from experimental
> +

This should mention that one ought to use `gbp buildpackage
--git-pbuilder` (as that is not the default).

> +To build your package against a build-depends taken from experimental, 
> you first need
> +to configure your pbuilder. To that extend, add the following to
> +~/.pbuilderrc to instruct pbuilder to take build 
> depends from
> +experimental when they cannot be satisfied from unstable.
> +
> +
> +PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-experimental
> +

Wouldn't we want to make that conditional like:

if [ "$GBP_DIST" = "experimental" ]; then
echo "Using 'pbuilder-satisfydepends-experimental' for $GBP_DIST"

PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-experimental
fi

but I *think* this is even the default nowadays for building against 
experimental.

> +
> +You then need to add experimental to the apt configuration within the 
> chroot.
> +The simplest for that is to edit the config file from outside of the 
> chroot directly,
> +as follows:
> +
> +sudo bash -c "echo 'deb http://deb.debian.org/debian experimental main' >> 
> /var/cache/pbuilder/base.cow/etc/apt/sources.list"
> +

What about suggesting to bootstrap a new environment instead via:

   DIST=experimental git-pbuilder create 

This also handles adding experimental to /etc/apt/sources.list (no extra
setup needed). Maybe we can streamline things that way a bit?

Cheers,
 -- Guido

> +
> +Once everything is setup (and once you updated apt cache files with
> +git-pbuilder update), you can force the build of your 
> package against
> +a given package from experimental by specifying the relevant version in 
> the
> +debian/control.
> +
> +
>  
>  Importing NMUs
>  

Bug#1055071: Initramfs significantly larger

[Guido Günther]

Source: osk-sdl
Version: 0.67.1-2
Severity: important

As of 40410cfef9f9e811db333a3406a701ddd18a4f8e the initramfs on the
Librem 5 grew quite a bit.

usr/lib/aarch64-linux-gnu/dri/ went from 22MB to 100MB making /boot run
out of space for some users.

I assume reverting the above would do the trick but haven't verified
yet.

Cheers,
 -- Guido

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1054305: Please install helper binaries into /usr/libexec

[Guido Günther]

Hi Michael,
On Sat, Oct 21, 2023 at 01:36:28PM +0200, Michael Biebl wrote:
> Source: network-manager-iodine
> Version: 1.2.0-3.2
> Severity: wishlist
> Tags: patch
> User: bi...@debian.org
> Usertags: nm-libexec
> 
> Hi,
> 
> your package installs helper binaries that are currently located in
> /usr/lib/NetworkManager.
> Now that Debian policy allows to install such binaries into
> /usr/libexec, it was requested in [1] that the network-manager package
> is updated to use this location to align with other distros and avoid
> unnecessary friction.
> 
> The network-manager package and the vpn packages maintained by the
> pkg-utopia team have been updated accordingly.
> 
> For consistencies sake, please consider applying the attached patch,
> which moves the helper binaries to /usr/libexec.
> 
> It updates the compat level to 13 as well, to get a $libexecdir which is
> set to /usr/libexec (and makes minimal changes to get the package build
> with compat level 13).

Thanks a lot! My key in Debian's keyring expired, hence I'm waiting for
a keyring update so if you want to get this out of the way and NMU then
just go ahead.
Cheers,
 -- Guido

Bug#1053747: [Debian-on-mobile-maintainers] Bug#1053747: Upload phosh to? bookworm-backports ?

[Guido Günther]

Hi,
On Fri, Oct 13, 2023 at 09:24:22PM +0530, Pirate Praveen wrote:
> On Wed, 11 Oct 2023 11:07:57 +0200 Guido =?iso-8859-1?Q?G=FCnther?=
>  wrote:
> > Hi Praveen,
> > I'm always in favour of providing newer phosh to users but see below for
> details:
> >
> > On Tue, Oct 10, 2023 at 02:33:52PM +0530, Pirate Praveen via
> Debian-on-mobile-maintainers wrote:
> > > Package: phosh
> > > Version: 0.32.0-1
> > > Severity: wishlist
> > >
> > > I think it'd be a good idea to provide new versions of phosh (with phoc,
> > > wlroots, feedbackd) via bookworm-backports. I was earlier daily driving
> > > mobian trixie on my Librem 5 but since its automatic suspend broke I
> could
> > > not continue using it [1]. So I'm using mobian bookworm but I miss the
> newer
> > > phosh (especially easy access to suspend button, which I use often for
> power
> > > saving).
> > >
> > > I have built the debs already and started using it from yesterday. I
> have
> > > shared the debs in my personal repo [2]. I'd like to upload and help
> > > maintain it in bookworm-backports if you are okay with the idea of
> providing
> > > official backports.
> >
> > I'm okay with the idea if you sign up to handle bug reports concerning
> > the backported versions. If that makes sense to you and Mobian has no
> > objections (as I think running it together with Mobian will be the main
> > use case for most people) we should maintain the backported branch in
> > the DebianOnMobile git too.
> >
> > Note that backporting phosh will imply backporting phoc at some point
> > and might also break phosh-mobile-settings at some point (and that
> > requires newer libadwaita already (which requires newer GTK). That
> > shouldn't' prevent us from backporting just now, just wanted to lay out
> > that it might get a bit more involved in the future.
> 
> I tried backporting phosh-mobile-settings now, as you mentioned it needs
> newer libadwaita, which in turn needs newer glib and gtk4. So I think gnome
> team won't like the official backports.

You can backport the *current* p-m-s version (see PureOS Crimson) without
newer libadwaita but that won't work forever.

Cheers,
 -- Guido

> 
> Arnaud,
> 
> Do you think it would be a good idea to have bookworm-backports suite in
> mobian repo and upload these there?
> 
> As for bugs, I think keeping up with new upstream versions would be a good
> strategy. If I go with byzantium experience, I'd think you will support
> newer versions on crimson, so having bookworm-backports should be easier to
> maintain.
> > Cheers and thanks for having a look at this,
> >  -- Guido
> >
> > >
> > > Since pureos crimson is not yet useable, I think this would be useful
> for
> > > many who want a newer base OS.
> > >
> > > [1]
> 
> > > [2] 
> > >
> > > ___
> > > Debian-on-mobile-maintainers mailing list
> > > debian-on-mobile-maintain...@alioth-lists.debian.net
> > > 
> > >
> >
> >
> 
> 
> 

Bug#1053747: [Debian-on-mobile-maintainers] Bug#1053747: Bug#1053747: Upload phosh to bookworm-backports ?

[Guido Günther]

Hi,
On Fri, Oct 13, 2023 at 09:13:39PM +0530, Pirate Praveen via 
Debian-on-mobile-maintainers wrote:
> On Tue, 10 Oct 2023 23:56:54 +0200 Arnaud Ferraris 
> wrote:
> > Hi,
> >
> > Le 10/10/2023 à 11:03, Pirate Praveen via Debian-on-mobile-maintainers a
> > écrit :
> > > Package: phosh
> > > Version: 0.32.0-1
> > > Severity: wishlist
> > >
> > > I think it'd be a good idea to provide new versions of phosh (with phoc,
> > > wlroots, feedbackd) via bookworm-backports. I was earlier daily driving
> > > mobian trixie on my Librem 5 but since its automatic suspend broke I
> > > could not continue using it [1]. So I'm using mobian bookworm but I miss
> > > the newer phosh (especially easy access to suspend button, which I use
> > > often for power saving).
> >
> > As discussed in the Mobian issue you mention, the auto-suspend problem
> > you're experiencing is only happening with recent versions of phosh,
> > which basically reset the idle counter when a critical notification
> happens.
> >
> > Providing a backported version of phosh wouldn't help there, and the
> > solution should be provided by upstream gnome-settings-daemon[1]. In the
> > meantime, you can work around this issue by executing, for example:
> >
> >gsettings set sm.puri.phosh.notifications wakeup-screen-triggers '[]'
> 
> Thanks this fixes the auto suspend, though one motivation for getting newer
> phosh was its suspend inhibition when wifi tethering is active, which is
> also disabled with this setting. But I can live with that until

Suspend when wifi hotspot is active is *not* related to any
wakup-screen-triggers. The phosh in stable/bookworm simply doesn't take
an inhibitor when the hotspot is active (this was added in 0.26.0).

Cheers,
 -- Guido

> gnome-settings-daemon is fixed. This means I have to remember to toggle
> suspend when charging each time I turn on or off wifi tethering. I was using
> a script earlier to launch tethering and inhibit suspend earlier, I will go
> back to it until this gets fixed.



> 
> > Cheers,
> > Arnaud
> >
> > [1]
> >
> 
> >
> > >
> > > I have built the debs already and started using it from yesterday. I
> > > have shared the debs in my personal repo [2]. I'd like to upload and
> > > help maintain it in bookworm-backports if you are okay with the idea of
> > > providing official backports.
> > >
> > > Since pureos crimson is not yet useable, I think this would be useful
> > > for many who want a newer base OS.
> > >
> > > [1]
> 
> > > [2] 
> > >
> > > ___
> > > Debian-on-mobile-maintainers mailing list
> > > debian-on-mobile-maintain...@alioth-lists.debian.net
> > > 
> >
> >
> >
> 
> 
> 

> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#1053747: [Debian-on-mobile-maintainers] Bug#1053747: Upload phosh to bookworm-backports ?

[Guido Günther]

Hi Praveen,
I'm always in favour of providing newer phosh to users but see below for 
details:

On Tue, Oct 10, 2023 at 02:33:52PM +0530, Pirate Praveen via 
Debian-on-mobile-maintainers wrote:
> Package: phosh
> Version: 0.32.0-1
> Severity: wishlist
> 
> I think it'd be a good idea to provide new versions of phosh (with phoc,
> wlroots, feedbackd) via bookworm-backports. I was earlier daily driving
> mobian trixie on my Librem 5 but since its automatic suspend broke I could
> not continue using it [1]. So I'm using mobian bookworm but I miss the newer
> phosh (especially easy access to suspend button, which I use often for power
> saving).
> 
> I have built the debs already and started using it from yesterday. I have
> shared the debs in my personal repo [2]. I'd like to upload and help
> maintain it in bookworm-backports if you are okay with the idea of providing
> official backports.

I'm okay with the idea if you sign up to handle bug reports concerning
the backported versions. If that makes sense to you and Mobian has no
objections (as I think running it together with Mobian will be the main
use case for most people) we should maintain the backported branch in
the DebianOnMobile git too.

Note that backporting phosh will imply backporting phoc at some point
and might also break phosh-mobile-settings at some point (and that
requires newer libadwaita already (which requires newer GTK). That
shouldn't' prevent us from backporting just now, just wanted to lay out
that it might get a bit more involved in the future.

Cheers and thanks for having a look at this,
 -- Guido

> 
> Since pureos crimson is not yet useable, I think this would be useful for
> many who want a newer base OS.
> 
> [1] https://salsa.debian.org/Mobian-team/devices/librem5-support/-/issues/7
> [2] https://people.debian.org/~praveen/mobian/
> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
> 

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#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

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

[Guido Günther]

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

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).
> 
> This would be used by phosh-osk-stub to supply Indic language input on mobile.

The go dependency golang-github-mattn-go-sqlite3-dev is in Debian
already. The build system needs some minor tweaks:

  https://github.com/varnamproject/govarnam/pull/33
  https://github.com/varnamproject/govarnam/pull/32
  https://github.com/varnamproject/govarnam/pull/31

Cheers,
 -- Guido

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

[Guido Günther]

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).

This would be used by phosh-osk-stub to supply Indic language input on mobile.

Bug#1051463: Fails to copy / past with phoc

[Guido Günther]

Package: wl-clipboard
Version: 2.2.0-1
Severity: important
Tags: patch

Pasting fails in 2.2.0 like:

$ wl-paste
wl_registry@2: error 0: invalid version for global gtk_shell1 (20): have 3, 
wanted 4
wl_display_dispatch: Protocol error

when using phoc as wayland compositor. This is fixed via

   https://github.com/bugaevc/wl-clipboard/pull/193

and also in the new upstream version 2.2.1.

Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.4.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wl-clipboard depends on:
ii  libc6   2.37-7
ii  libwayland-client0  1.22.0-2

Versions of packages wl-clipboard recommends:
ii  xdg-utils  1.1.3-4.1

wl-clipboard suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/wl-copy (from wl-clipboard package)
debsums: changed file /usr/bin/wl-paste (from wl-clipboard package)

Bug#1051198: Fake bug to keep phosh-osk-stub out of testing

[Guido Günther]

Package: phosh-osk-stub
Version: 0.30.0-1
Severity: grave

It's useful for testing so having it in unstable is useful. It's not yet
suitable for stable releases though so lets keep it out of testing.
Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.4.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages phosh-osk-stub depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libfeedback-0.0-00.2.1-1
ii  libglib2.0-0 2.77.2-1
ii  libgnome-desktop-3-2044.0-2
ii  libgtk-3-0   3.24.37-2
ii  libhandy-1-0 1.8.2-2
ii  libhunspell-1.7-01.7.2+really1.7.2-10
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.14+ds-1
ii  libpangocairo-1.0-0  1.50.14+ds-1
ii  libpresage1v50.9.1-2.5
ii  libsystemd0  254.1-2
ii  libwayland-client0   1.22.0-2
ii  libxkbcommon01.5.0-1

Versions of packages phosh-osk-stub recommends:
ii  fonts-noto-core  20201225-1
ii  hunspell-en-us   1:2020.12.07-2

phosh-osk-stub suggests no packages.

-- no debconf information

Bug#1050762: two more minor fixes in your upstream fixes

[Guido Günther]

Hi,
(put the bug in cc: so we have a all the bits together)

On Thu, Aug 31, 2023 at 11:09:02PM +0200, Boud Roukema wrote:
> hi Guido,
> 
> I agree with closing #1050762. But upstream I still see two minor fixes
> needed (unless I misunderstand something):
> 
> https://source.puri.sm/Librem5/feedbackd/-/blob/main/doc/fbd-theme-validate.rst
> - 'See also' is missing  fbd-theme-validate(1)

I assume you mean `missing `feedback-themes`, I've added that.

> https://source.puri.sm/Librem5/feedbackd/-/blob/main/doc/feedbackd.rst
> - 'See also' has a double copy of 'feedback-themes(5)'

Dropped that, thanks!

> https://source.puri.sm/Librem5/feedbackd/-/blob/main/doc/feedback-themes.rst
> https://source.puri.sm/Librem5/feedbackd/-/blob/main/doc/fbcli.rst
> - these two both look correct :)
> 
> The other bug, #1050601, still looks open to me. At least the upstream main

That's why I didn't close it yet. The README isn't suitable to install
though as half of the information isn't relevant on the installed
system. The corresponding bits need to move to the manpages (which is
also an opportunity to disentangle those).

Cheers,
 -- Guido

> documentation files such as "README.md" and "NEWS" should be installed into
> the debian /usr/shared/doc/feedbackd/  directory. That's not duplication - it
> allows someone without internet access to access more documentation than the
> man pages. README.md will generally give more info than a man page.
> Anyway, we can discuss that further on that bug thread, which differs from
> this one.
> 
> Cheers
> Boud
> 

Bug#1050917: phosh: please provide a phosh-portals.conf for xdg-desktop-portal

[Guido Günther]

Hi,
On Thu, Aug 31, 2023 at 02:13:54PM +0100, Simon McVittie wrote:
> Control: tags -1 + fixed-upstream
> Control: forwarded -1 
> https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1301
> 
> On Thu, 31 Aug 2023 at 14:22:17 +0200, Guido Günther wrote:
> > I wasn't aware that `none` works, thanks for that!
> 
> I must admit that I've never actually tried that feature, so you might
> have to report bugs if it falls back to considering UseIn (I expect this
> to be a relatively rare use-case).
> 
> > Do you know of a way to have the config outside of `/etc/` so that
> > admins don't have to modify the conf file but can override it if they
> > want to make changes?
> 
> Since 1.17.1 it can/should be
> /usr/share/xdg-desktop-portal/phosh-portals.conf (and that's what I've been
> recommending in this MBF).
> 
> In the initial implementation of this feature in x-d-p
> 1.17.0, only /etc was searched, but I thought that was
> wrong, and fixed it to behave more like mimeapps.list in
> <https://github.com/flatpak/xdg-desktop-portal/pull/1082> which was
> included in 1.17.1.
> 
> I opened <https://gitlab.gnome.org/World/Phosh/phosh/-/issues/982> upstream
> with a suggested (but untested) change.

That helps, I'll take it from there. Thanks a lot!
 -- Guido

Bug#1050917: [Debian-on-mobile-maintainers] Bug#1050917: phosh: please provide a phosh-portals.conf for xdg-desktop-portal

[Guido Günther]

Hi Simon,
On Thu, Aug 31, 2023 at 12:41:02PM +0100, Simon McVittie wrote:
> Package: phosh
> Severity: normal
> Tags: trixie sid
> User: xdg-desktop-por...@packages.debian.org
> Usertags: portals.conf
> 
> xdg-desktop-portal 1.17.x introduces a new way to select which portals will
> be used for which desktop environments, modelled on mimeapps.list:
> 
> - each desktop environment should provide a file like
>   /usr/share/xdg-desktop-portal/phosh-portals.conf
> 
> - the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
>   environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
>   from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
> 
> - sysadmins and users can override this via files named portals.conf or
>   ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
>   and ~/.config/xdg-desktop-portal
> 
> Please see portals.conf(5) or its source code
> https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
> for full details.
> 
> If I'm reading correctly, I think phosh uses
> XDG_CURRENT_DESKTOP="Phosh:GNOME" but needs portals that are not quite the
> same as GNOME's, because it's using a wlroots-based compositor instead of
> the mutter-based GNOME Shell?
> 
> If that's the case, then it should provide a phosh-portals.conf so that
> individual users aren't required to set this up for themselves.
> 
> For example, it might look something like this (this is untested and based
> on guesses, I don't use Phosh myself, so please check this carefully):

Thanks for the details! We already have that fixed upstream¹ and it'll
trickle into Debian in the next week or so with the 0.31.0 release. We
can't use the GNOME portals atm as they require mutter's
org.gnome.Mutter.ServiceChannel which I'll need to add support for in
phoc first.

I wasn't aware that `none` works, thanks for that!

Do you know of a way to have the config outside of `/etc/` so that
admins don't have to modify the conf file but can override it if they
want to make changes?

Cheers,
 -- Guido

1) https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1301

Bug#1050762: feedbackd-device-themes: Users are not informed about existing tools from the feedbackd package

[Guido Günther]

Hi,
On Tue, Aug 29, 2023 at 02:12:36AM +0200, Boud Roukema wrote:
> I discovered from browsing sources and git histories that the debian
> 'feedbackd' package automatically installs several user-level programs
> that the user should be informed about:
> 
> $ dpkg -L feedbackd | grep /usr/bin
> 
> /usr/bin
> /usr/bin/fbcli
> /usr/bin/fbd-theme-validate

Users are informed via the manpages. I've added a feedback-themes
manpage upstream so apropos and other tools make it easier to find.

> PROPOSAL:

Thanks for proposing changes but I'd rather not duplicate documentation
as I don't want to maintain it in different places. There's nothing
Debian specific here so it should be part of the upstream docs and
trickle into Debian.

If you find anything missing please propose an MR there but note

   https://source.puri.sm/Librem5/feedbackd/-/merge_requests/112

[..snip..]
 
> To see the effects of your custom.json file, you will need to restart
> the running "feedbackd" daemon, e.g. "killall feedbackd" and then
> close and reopen a gui such as chatty that automatically restarts
> "feedbackd". Then (or before you switch) you can check individual
> effects:

Just as a remark:

There's neither a need to kill feedbackd as it can reload it's config on
SIGHUP nor do you need to restart apps.

Cheers,
 -- Guido

Bug#1043121: Needs breaks phosh << 0.30.0~

[Guido Günther]

Package: phoc
Version: 0.30.0
Severity: critical

We can't run with phosh << 0.30.0 session due to XWayland changes that
crash g-s-d settings. Hence we need the breaks.
Cheers,
 -- Guido


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages phoc depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas44.0-2
ii  libc62.37-5
ii  libcairo21.16.0-7
ii  libdrm2  2.4.115-1
ii  libegl1  1.6.0-1
ii  libgbm1  22.3.6-1+deb12u1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.76.4-4
ii  libgnome-desktop-3-2044.0-1
ii  libinput10   1.23.0-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpixman-1-00.42.2-1
ii  libseat1 0.7.0-6
ii  libudev1 252.11-1
ii  libwayland-client0   1.22.0-0.1
ii  libwayland-server0   1.22.0-0.1
ii  libxcb-composite01.15-1
ii  libxcb-dri3-01.15-1
ii  libxcb-icccm40.4.1-1.1
ii  libxcb-present0  1.15-1
ii  libxcb-render-util0  0.3.9-1+b1
ii  libxcb-render0   1.15-1
ii  libxcb-res0  1.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb-xfixes0   1.15-1
ii  libxcb-xinput0   1.15-1
ii  libxcb1  1.15-1
ii  libxkbcommon01.5.0-1
ii  mutter-common44.0-2

Versions of packages phoc recommends:
ii  phosh  0.29.0+next20230727.1753.1

phoc suggests no packages.

-- no debconf information

Bug#1035506: please update libliftoff

[Guido Günther]

Hi,
On Fri, Jul 14, 2023 at 03:26:05PM +0200, Matthias Geiger wrote:
> I created the three MR's for 0.4.1 here:
> https://salsa.debian.org/debian/libliftoff/-/merge_requests
> 
> I had to regenerate the symbols (four new ones).
> 
> Guido, feel free to review and upload if you got the time.

Thanks a lot for handling the update!
 -- Guido

Bug#1040796: Reports "release not available in the sources" when packages list is empty

[Guido Günther]

Package: apt
Version: 2.6.1
Severity: normal

With the sources.list below this works:

```
"apt-get" "-o" "Debug::pkgDepCache::AutoInstall=false" "-o" 
"APT::Get::Show-Versions=false" "-u" "dist-upgrade" "--print-uris" "--yes" "-t" 
 bookworm-security 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
```

while this gives an error:

```
# "apt-get" "-o" "Debug::pkgDepCache::AutoInstall=false" "-o" 
"APT::Get::Show-Versions=false" "-u" "dist-upgrade" "--print-uris" "--yes" "-t" 
 bookworm-updates
Reading package lists... Done
E: The value 'bookworm-updates' is invalid for APT::Default-Release as such a 
release is not available in the sources
```

I assume that's because there's not yet a point release for bookworm and
hence the Packages file is empty. This currently trips up the munin
apt_all plugin on bookworm. I'm aware there's better ways to figure out missing
upgrades but wanted to report it nevertheless.

Cheers,
 -- Guido

-- Package-specific info:

-- (no /etc/apt/preferences present) --

-- (/etc/apt/sources.list present) --

deb http://deb.debian.org/debian bookworm-updates main
deb http://deb.debian.org/debian bookworm main
deb http://deb.debian.org/debian-security/ bookworm-security main


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.21.22
ii  gnupg2.2.40-1.1
ii  powermgmt-base   1.37

-- no debconf information

Bug#1040404: [Debian-on-mobile-maintainers] Bug#1040404: gnome-calls: First call after boot blanks screen; can't access call controls

[Guido Günther]

Hi,
On Wed, Jul 05, 2023 at 10:36:47AM -0400, John Sullivan wrote:
> Package: gnome-calls
> Version: 44~alpha.1-1
> Severity: normal
> 
> This is on a PinePhone, with the Phosh environment.
> 
> Consistently, after a fresh boot, when I make a call, the screen goes
> blank. Hitting the lock button, which would normally un-blank the
> screen in some way (either by bringing up the PIN unlock screen, or by
> showing the active application), does nothing. Hitting the volume
> up/down buttons does show the expected volume adjustment pop-up.

I assume with the "lock button" you mean the (hardware) power button?

Calls itself doesn't do any blanking itself. The shell usually does.
E.g. phosh does this *based* on what gnome-calls exposes on DBus *and*
the state of the proximity sensor (also read from iio-sensor-proxy via
DBus).

So the thing to check on your device is what exposes incorrect results
or if the shell interprets them the wrong way.

>From what you write it looks as if your shell assumes the proximity
sensor is on as soon as the first call starts so I'd start debugging
there (e.g. in the case of phosh by using
`G_MESSAGES_DEBUG=phosh-proximity`).

Cheers,
 -- Guido

> 
> I can have the call as normal, but with the screen blank, I have no way to 
> hang up, or to navigate menus by pressing dialpad numbers. My only workaround 
> so far for ending the call is ssh'ing into the device
> and killing gnome-calls.
> 
> Once the first call is complete, if I make a second call, it functions as 
> normal -- the screen does not go blank immediately. When it does go blank, 
> pressing the lock button brings up the call controls.
> 
> This is 100% reproducible for me by just doing:
> 
> 1) Reboot the phone
> 2) Place a call to any number or contact 
> 3) Screen will go blank irrecoverably until gnome-calls is killed or other 
> side ends call
> 4) After call, place another call
> 5) It works as expected, as do all subsequent calls, until the next boot
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 6.1-sunxi64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages gnome-calls depends on:
> ii  dconf-gsettings-backend [gsettings-backe  0.40.0-4
> nd]
> ii  gstreamer1.0-plugins-bad  1.22.3-2
> ii  gstreamer1.0-plugins-good 1.22.4-1
> ii  libc6 2.36-9
> ii  libcallaudio-0-1  0.1.9-1
> ii  libebook-contacts-1.2-4   3.48.4-1
> ii  libfeedback-0.0-0 0.2.0-2
> ii  libfolks260.15.6-1
> ii  libgee-0.8-2  0.20.6-1
> ii  libglib2.0-0  2.74.6-2
> ii  libgom-1.0-0  0.4-1
> ii  libgstreamer1.0-0 1.22.3-2
> ii  libgtk-3-03.24.37-2mobian2
> ii  libhandy-1-0  1.8.2-2
> ii  libmm-glib0   1.20.6-2
> ii  libpeas-1.0-0 1.34.0-1+b1
> ii  libsecret-1-0 0.20.5-3
> ii  libsofia-sip-ua-glib3 
> 1.12.11+20110422.1+1e14eea~dfsg-6
> ii  libsofia-sip-ua0  
> 1.12.11+20110422.1+1e14eea~dfsg-6
> ii  modemmanager  1.20.6-2
> 
> Versions of packages gnome-calls recommends:
> ii  callaudiod  0.1.9-1
> ii  gnome-contacts  43.1-1mobian1
> 
> gnome-calls suggests no packages.
> 
> -- no debconf information
> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
> 

Bug#1030534: gbp pq import fails with series file containing form feed

[Guido Günther]

Hi Ian,
On Sat, Feb 04, 2023 at 05:31:11PM +, Ian Jackson wrote:
> Package: git-buildpackage
> Version: 0.9.30
> Severity: normal
> File: /usr/lib/python3/dist-packages/gbp/scripts/supercommand.py
> 
> Steps to reproduce:
> 
>dget 
> https://deb.debian.org/debian/pool/main/p/python-coverage/python-coverage_6.5.0+dfsg1-2.dsc
>dpkg-source --skip-patches -x python-coverage_6.5.0+dfsg1-2.dsc
>cd python-coverage-6.5.0+dfsg1/
>git init
>git add -Af .
>git commit -m import
># Now we are on a patches-unapplied packaging branch (without .pc
># directory, at least in the version of dpkg-source I have here)
>gbp pq import
> 
> Expected behaviour:
> 
>Imports the patch queue, leaving me on patch-queue/master,
>with two patches applied.
> 
> Actual behaviour:
> 
>Python stack backtrace.  (Transcript below.)
> 
>It leaves me on a broken patch-queue/master branch - one without
>the patches applied.  Even to go back to where I was before,

I've fixed that to go to an unbroken state on all exceptions (not only
the ones raised by gbp itself).

>I must
>   git checkout master; git-branch -D patch-queue/master

Or to recover with gbp iself: "gbp pq switch && gbp pq drop"

> The root cause is that the debian/patches/series file contains a line
> containing only a form feed (ctrl-L).  I think this is deranged.
> Perhaps you don't want to support it.  Maybe you want to at least
> detect and reject it
> 
> Empirically, deleting the form feed works around the problem.

gbp does the same now. Thanks for investigating!
Cheers,
 -- Guido

Bug#1036914: unblock: librem5-flash-image/0.0.3-1

[Guido Günther]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: librem5-flash-im...@packages.debian.org
Control: affects -1 + src:librem5-flash-image

Please unblock package librem5-flash-image

The tool is used to flash images to Librem 5 phones.

[ Reason ]
This adds support for stable image downloads (rather than
always fetching the latest image to flash to the phone)
hence it seems appropriate to have that in a stable relase.
It also makes downloading a bit more robust by allowing for longer
timeouts.

[ Impact ]
Users will have to manually go out and search for stable images.

[ Tests ]
- Tested flashing manually
- CI tests (that download images) pass upstream in a Debian container

[ Risks ]
Risks should be low as the package is in use on other distros since some
time.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I apologize for being late here, I simply missed that the version
is outdated. I could have backported the patch but just using the
upstream version (which didn't bring any other features) seemed more
reasonable here.

unblock librem5-flash-image/0.0.3-1
diff --git a/debian/changelog b/debian/changelog
index 2c0f47f..d94dbf9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+librem5-flash-image (0.0.3-1) unstable; urgency=medium
+
+  * New upstream release
+
+ -- Guido Günther   Fri, 24 Feb 2023 17:53:10 +0100
+
 librem5-flash-image (0.0.2-1) unstable; urgency=medium
 
   * New upstream release 0.0.2
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 3d0bb65..b2eeae8 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,17 @@
 [DEFAULT]
-debian-branch=debian/master
+debian-branch = debian/master
+debian-tag = debian/%(version)s
+upstream-branch = upstream/latest
+upstream-tag = upstream/%(version)s
+upstream-vcs-tag = v%(version)s
 pristine-tar = True
-upstream-tag = v%(version)s
+
+[tag]
+sign-tags = true
+
+[dch]
+multimaint-merge = True
+
+[import-orig]
+postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
+upstream-vcs-tag = v%(version%~%_)s
diff --git a/scripts/librem5-flash-image b/scripts/librem5-flash-image
index be28869..3896d8c 100755
--- a/scripts/librem5-flash-image
+++ b/scripts/librem5-flash-image
@@ -35,6 +35,12 @@ except ImportError:
 
 from urllib.parse import urljoin
 
+IMAGES = {
+'stable': {
+'url': 'https://storage.puri.sm/librem5/images/',
+}
+}
+
 JENKINS = 'https://arm01.puri.sm'
 BOARD_TYPE = 'librem5r4'
 VALID_PHONE_BOARD_TYPES = ['librem5r2', 'librem5r3', 'librem5r4']
@@ -130,7 +136,8 @@ def resuming_stream(url, expected_size, max_attempts):
 try:
 resp = requests.get(url,
 stream=True,
-headers={'Range': 'bytes={}-'.format(position)}
+headers={'Range': 'bytes={}-'.format(position)},
+timeout=10
 )
 resp.raise_for_status()
 
@@ -145,7 +152,9 @@ def resuming_stream(url, expected_size, max_attempts):
 if position < expected_size:
 raise PrematureEndException()
 return
-except (requests.exceptions.ConnectionError, PrematureEndException):
+except (requests.exceptions.ConnectionError,
+requests.exceptions.Timeout,
+PrematureEndException):
 if i == max_attempts - 1:
 logging.error("Max connection errors reached, aborting")
 raise
@@ -207,7 +216,7 @@ def download_image(url, target, attempts):
 verify_image(target, meta)
 
 
-def find_image(jobname, type, variant, dist):
+def find_image_jenkins(jobname, type, variant, dist):
 server = jenkins.Jenkins(JENKINS)
 logging.info("Looking for {} {} {} image".format(type, variant, dist))
 try:
@@ -219,6 +228,8 @@ def find_image(jobname, type, variant, dist):
 resp = requests.get(build['url'] + '/api/json')
 resp.raise_for_status()
 json = resp.json()
+if json['description'] is None:
+continue
 if (json['description'].startswith(variant + ' ' + type) and
 dist in json['description'] and
 json['result'] == 'SUCCESS'):
@@ -229,6 +240,40 @@ def find_image(jobname, type, variant, dist):
 return found
 
 
+def find_image_stable(board, variant, dist):
+remote = IMAGES['stable']
+logging.info("Looking for {} {} {} image".format(board, variant, dist))
+found = None
+
+path = f"{dist}/latest/{board}/{variant}/"
+url = urljoin(remote['url'], f"{path}/artifact/{IMAGE.format(board)}.xz")
+try:
+resp = requests.head(url, timeout=10)
+if resp.ok:
+

Bug#1036012: ITP: phosh-wallpapers -- Wallpapers for Phosh

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: phosh-wallpapers
  Version : 0.27.0
  Upstream Contact: François Téchené 
* URL : https://gitlab.gnome.org/guidog/phosh-wallpapers
* License : cc-by-sa-4.0
  Programming Lang: none
  Description : Wallpapers for Phosh

 Wallpapers for Phosh intended for use on mobile phones as lockscreen
 background. For docked usage some typical desktop sizes are provided as well.
 .
 The wallpapers work on other mobile and desktop environments e.g. as desktop
 background too.

Bug#1035838: gbp-pq manpage could refer to the moved location

[Guido Günther]

Hi,
On Wed, May 10, 2023 at 08:53:13AM +0900, Junichi Uekawa wrote:
> 
> Package: git-buildpackage
> Version: 0.9.22
> 
> gbp-pq manpage refers to a page that says the content has moved.
> I think it can refer to the local html copy[1], or the internet copy.

Appplied. Thanks for the patch.
Cheers,
 -- Guido

> 
> [1] /usr/share/doc/git-buildpackage/manual-html/gbp.patches.html
> 
> 
> diff -ur git-buildpackage-0.9.22{,-}
> diff -ur git-buildpackage-0.9.22/docs/manpages/gbp-pq.xml 
> git-buildpackage-0.9.22-/docs/manpages/gbp-pq.xml
> --- git-buildpackage-0.9.22/docs/manpages/gbp-pq.xml  2019-01-09 
> 04:15:13.0 +0900
> +++ git-buildpackage-0.9.22-/docs/manpages/gbp-pq.xml 2023-05-10 
> 08:49:24.326208037 +0900
> @@ -54,7 +54,7 @@
>  called patch-queue/master.
>  
>  
> -See  url="https://honk.sigxcpu.org/piki/development/debian_packages_in_git/;>
> +See  url="https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html;>
>  for example workflows.
>  
>
> 

Bug#1035563: New upstream version 1.22.0

[Guido Günther]

Source: wayland
Version: 1.21.0-1
Severity: wishlist


Hi,
wayland 1.22.0 has been released:

   https://gitlab.freedesktop.org/wayland/wayland/-/tags/1.22.0

Would be great to have that in experimental. I've made an MR to update
here:

   https://salsa.debian.org/xorg-team/wayland/wayland/-/merge_requests/5

Happy to NMU if that looks o.k.

Cheers,
 -- Guido


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1035506: New upstream version 0.4.0

[Guido Günther]

Package: source
Version: 0.3.0-1
Severity: wishlist

There's a new upstream version 0.4.1

  https://gitlab.freedesktop.org/emersion/libliftoff/-/tags/v0.4.1

Would be great to have that in experimental as current sway, wlroots
requires it.
Cheers,
 -- Guido


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1009163: import-orig: please make --upstream-vcs-tag=%(version)s strip +dfsg/+ds repack suffixes

[Guido Günther]

Hi Guilhem,
On Mon, Mar 06, 2023 at 01:37:01PM +0100, Guilhem Moulin wrote:
> Hi Guido,
> 
> On Wed, 01 Mar 2023 at 12:14:51 +0100, Guido Günther wrote:
> > On Tue, Aug 09, 2022 at 01:07:34PM +0200, Guilhem Moulin wrote:
> >> That'd work for me, thanks!  Some ideas to cover other use-cases if
> >> desired:
> >>
> >> - Always strip ‘+ds(\.\d*)?’ and ‘+dfsg(\.\d*)?’ repack suffixes
> >>   *after* version mangling.  After all, if upstream uses such suffixes
> >>   in its tags or version number, then the revision has to be mangled so
> >>   it doesn't collide with a repack suffix no?
> >> - New option --upstream-vcs-tag-strip='\+ds(\.\d*)?$'
> >
> > I wonder if a simple:
> >
> > --upstream-vcs-tag-strip
> >
> > that defaults to 'on' would already do the trick (as stripping this
> > should be the norm (as you elaborate in your first point) and the option
> > is only there if people want the old behavior.
> 
> That would cover my use-case nicely, at least :-)

Sorry for the delay. I've pushed something based on the patch in
#968329. Maybe we can even get away without another option this way.
Cheers,
 -- Guido

> 
> -- 
> Guilhem.

Bug#1034712: ITP: livi -- Minimalistic video player targeting mobile devices

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: livi
  Version : 0.0.3
  Upstream Contact: Guido Günther 
* URL : https://gitlab.gnome.org/guidog/livi
* License : GPL
  Programming Lang: C
  Description : Minimalistic video player targeting mobile devices

A minimalistic GTK4 and gstreamer based video player for mobile phones
like the Librem 5 aiming for minimal battery usage.
It supports:
 - Inhibiting suspend/idle when playing video
 - li>Stopping video playback on (i.e. power button toggled) blank
 - Registering as default video player in GNOME control center
 - An indicator whether hardware accleration is in usex

Bug#1032932: git-buildpackage: --no-sign-tags doesn't take effect if git config says to sign tags

[Guido Günther]

Hi,
On Tue, Mar 14, 2023 at 10:42:08AM +, Huw Jones wrote:
> Package: git-buildpackage
> Version: 0.9.22
> Severity: important
> Tags: patch
> X-Debbugs-Cc: h...@pexip.com
> 
> Dear Maintainer,
> 
> My gitconfig contains
> [tag]
> gpgsign = true
> When calling 
> gbp import-dsc --pristine-tar --no-sign-tags
> I get prompted by gpg to sign my tags.
> With the `--no-sign-tags` option, I would expect it to instruct git to 
> **not** sign tags.

Thanks. I think that's a reasonable assuption.
Cheers,
 -- Guido

> The following patch (also available 
> https://github.com/pexip/os-git-buildpackage/commit/8ef3ec7880caaf167429426142b0aa965ee41dd5)
> resolves the issue for me.

> 
> diff --git a/gbp/git/repository.py b/gbp/git/repository.py
> index e21b19e..90c8395 100644
> --- a/gbp/git/repository.py
> +++ b/gbp/git/repository.py
> @@ -676,6 +676,8 @@ class GitRepository(object):
>  if sign:
>  args += ['-s']
>  args += ['-u', keyid] if keyid else []
> +else:
> +args += ['--no-sign']
>  args += [name]
>  args += [commit] if commit else []
>  self._git_command("tag", args)
> 
> -- System Information:
> Debian Release: 11.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-17-amd64 (SMP w/16 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.21.3+deb11u1
> ii  git1:2.30.2-1
> ii  man-db 2.9.4-2
> ii  python33.9.2-3
> ii  python3-dateutil   2.8.1-6pexip3
> ii  python3-pkg-resources  52.0.0-4
> ii  sensible-utils 0.0.14
> 
> Versions of packages git-buildpackage recommends:
> ii  cowbuilder0.89
> ii  pbuilder  0.231
> ii  pristine-tar  1.49
> ii  python3-requests  2.25.1+dfsg-2
> 
> Versions of packages git-buildpackage suggests:
> pn  python3-notify2  
> ii  sudo 1.9.5p2-3
> ii  unzip6.0-26+deb11u1
> 
> -- no debconf information
> 

Bug#1032882: [Debian-on-mobile-maintainers] Bug#1032882: Bug#1032882: uuu: New upstream release available

[Guido Günther]

Hi Andreas,
[..snip..]
> I've forked and updated the packaging at:
> https://salsa.debian.org/ah/mfgtools
> 
> The relevant commit (apart from `gbp import-orig --uscan`) is
> https://salsa.debian.org/ah/mfgtools/-/commit/a7a75a60f5e0e923ef1deb1b08469d0a9553a8ed
> (and then updating debian/changelog ofcourse).
> 
> It build, installs and runs basic commands fine, but I haven to yet
> tested it against an actual imx target.

Testing on an imx target would be good before upload ;) 

> If there's a lack of people interested in maintaing uuu/mfgtools I'd be
> willing to help out. I don't have any particular interest in the Debian
> on Mobile effort (right now), apart from uuu/mfgtools, though.
> Would you be willing to give me access or consider if maybe it's
> better if mfgtools repo live under the "debian" group on salsa?

I've added you as maintainer to the uuu repo so we keep things
together. As Henry is the maintainer I'd rather not move repos around if
not absolutely needed. O.k.?

> I don't like leaving git repos out of sync, so if I'm given commit
> access I'd also be willing to upload to experimental.
> I could even consider adding myself to Uploaders as I am a semi-regular
> user of uuu and would like to see it be kept up to date.

Sure, go ahead.

> Please advice on what you think is appropriate.
> (I'm @ah on salsa).
> 
> Regards,
> Andreas Henriksson
> 
> PS. my personal preference is to include full upstream commit history in
> the upstream branch, if you're also open to making that change in the
> repo please tell me.

We usually use `gbp import-orig --upstream-vcs-tag=` within DebianMobile
so if that's what you're referring to, that would be a desirable change.

Cheers,
 -- Guido

Bug#1032882: [Debian-on-mobile-maintainers] Bug#1032882: uuu: New upstream release available

[Guido Günther]

Hi,
On Mon, Mar 13, 2023 at 11:38:03AM +0100, Andreas Henriksson wrote:
> Package: uuu
> Version: 1.4.193-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> As currently reported on https://tracker.debian.org/pkg/mfgtools
> the latest packaged version of uuu is 1.4.193-1 while as reported
> on the same page the latest upstream version is 1.5.21.
> 
> I'm opening this bug report to discuss around updating the uuu
> packaging. Are there any known blockers? Lack of volunteers? etc.
> 
> (As we're currently in freeze for bookworm it might be best to just
> prepare updates targeting experimental for now. I do volunteer to look
> into it if the problem is lack of volunteers, but if you do have known
> issues or blockers then please share!)

I think Henry isn't very active atm so an upload to experimental would
be fine.
Cheers,
 -- Guido

Bug#1005190: gbp dch: add trailing dot when updating changelog

[Guido Günther]

Hi,
On Fri, Mar 03, 2023 at 12:16:27AM -0800, Otto Kekäläinen wrote:
> Hi!
> 
> To summarize here:
> 
> - Good git commit message titles should NOT end with a dot. Titles

I think there's consensus about that.

> (and e.g. subject lines in an email) should not end with a dot based
> on general English grammar rules and also software development / git
> conventions as long as we have had patches and git commits.
> 
> - By convention, many people use full sentences in changelogs (as
> pointed out by e.g. Mattia in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959665). In a
> changelog it makes sense to have full sentences if the texts are
> longer. This is also what English grammar rules say: a (bullet point)
> list with just titles are not sentences and have no trailing dot, but
> if the list has longer and *some* items that are sentences, then all
> items in the list should end with a dot.

I think the reason this is not moving forward is that people have different
preferences. "English grammar rule" seems to be interpreted differently
e.g. by the Imperial college for their brand:

  
https://www.imperial.ac.uk/brand-style-guide/writing/grammar/punctuation/bullet-points/

which would only use fulls top if there's an introductory sentence (which
isn't usually the case for changelogs). And there's other recommendation
all around.

I think a good way to move this forward is to at least have a
recommendation in the developers reference (if not in policy itself) as
everyone can already have the changelog configured by `gbp dch` as they
see fit (via a customization-file) already.

> Therefore, can we please make sure that Lintian-brush and things that
> do git commits do NOT add trailing space, and that tools that write
> changelogs add trailing dots when needed?

Note that 'gbp dch' already figures out if a dot is needed based on the
commit body for *multiline* git commit messages. So the simplest thing
would be to add yet another option that (optionally) does that for one
line changelog messages as well which would break down the debate to
what is the right default (for which developer reference and policy are
usually strong indicators). I've added a note along those lines to
#959665.

Cheers,
 -- Guido

Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."

[Guido Günther]

Hi,
On Mon, May 11, 2020 at 12:08:30PM +0200, Guido Günther wrote:
> Hi,
> On Mon, May 11, 2020 at 11:13:20AM +0200, Matthijs Kooijman wrote:
> > Package: git-buildpackage
> > Followup-For: Bug #959665
> > 
> > Hi,
> > 
> > It does seem that having a full stop at the end of debian/changelogs is
> > conventional. However, this is already easy to configure locally. I had
> > this in my debian/gbp.conf for a long time:
> > 
> >   [import-orig]
> >   import-msg = New upstream release %(version)s.
> > 
> > I've since removed the dot again, since for *git* commit messages, it is
> > conventional to *not* have a full stop at the end of the first line and
> > I kept forgetting to add it for my Debian packages, so now my changelogs
> > also omit the full stop.
> > 
> > Also, it seems that Debian policy does not mention the full stop at all:
> > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
> > 
> > Anyway, this is already easy to configure, so I wonder if this would be
> > worth changing?
> 
> That's what i'm unsure about too and the reason i was asking for the
> pattern behind this. I'm leaning more to leave things as is for the
> moment too - so thanks for your input!

Note that gbp dch already figures out if a dot is needed based on the
commit body so the git commit message goes without a dot while the
changelog entry gets a dot in multiline messages (See
terminate_first_line_if_needed) if the body starts with a capital letter.

The only thing needed would be to make it act on one line messages at
all - either by adding yet another option or by reaching consensus.
Policy section 4.4. Debian changelog: "debian/changelog" does not
make any recommendations along these lines.

Cheers,
 -- Guido

Bug#1009163: import-orig: please make --upstream-vcs-tag=%(version)s strip +dfsg/+ds repack suffixes

[Guido Günther]

Hi,
On Tue, Aug 09, 2022 at 01:07:34PM +0200, Guilhem Moulin wrote:
> Hi Guido,
> 
> On Tue, 09 Aug 2022 at 10:54:54 +0200, Guido Günther wrote:
> > We could fix the replacement to be empty:
> > 
> > https://github.com/agx/git-buildpackage/compare/master...ds
> > 
> > This causes trouble for people though that need this *and* to mangle the
> > version by other means.
> 
> That'd work for me, thanks!  Some ideas to cover other use-cases if
> desired:
> 
>  - Always strip ‘+ds(\.\d*)?’ and ‘+dfsg(\.\d*)?’ repack suffixes
>*after* version mangling.  After all, if upstream uses such suffixes
>in its tags or version number, then the revision has to be mangled so
>it doesn't collide with a repack suffix no?
>  - New option --upstream-vcs-tag-strip='\+ds(\.\d*)?$'

I wonder if a simple:

 --upstream-vcs-tag-strip

that defaults to 'on' would already do the trick (as stripping this
should be the norm (as you elaborate in your first point) and the option
is only there if people want the old behavior.

If that makes sense I'd be happy to apply a patch for this as I assume
this bits many pages that need to repack upstream tarballs *and* want
--upstream-vcs-tag

Cheers,
 -- Guido


>  - AFAIK substitution in tag formats currently support a single
>character; it could be changed so the remaining of the middle portion
>is stripped, so ‘%(version%.+ds%_)’ rewrites ‘1.2.3+ds’ to ‘1_2_3’
>and ‘%(version%.+ds%.)’ rewrite it to ‘1.2.3’.  Odd semantics though
>and not trivial to document…
> 
> cheers
> -- 
> Guilhem.

Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)

[Guido Günther]

control: -1 tags +pending

Hi Samuel,
On Tue, Feb 21, 2023 at 08:33:34PM +, Samuel Henrique wrote:
> Hello Guido,
> 
> > You need to fixup the tests too though
> 
> I have updated the Github PR and also attached the new patch with the
> unit tests fixed.

Appied. Thanks!
 -- Guido

Bug#1030709: bullseye-pu: package libvirt/7.0.0-3+deb11u2

[Guido Günther]

Hi,
On Sun, Feb 19, 2023 at 06:47:58PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2023-02-06 at 18:08 +0100, Guido Günther wrote:
> > This update fixes the test failures on arm64 that were
> > detected by the 7.0.0-3+deb11u1 build.
> > 
> 
> Thanks; please go ahead.

Uploaded now. Thanks!
 -- Guido

> 
> Regards,
> 
> Adam
> 

Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)

[Guido Günther]

Hi Samueloph,

On Tue, Feb 14, 2023 at 11:16:11PM +, Samuel Henrique wrote:
> Package: git-buildpackage
> X-Debbugs-Cc: samuel...@debian.org
> Version: 0.9.30
> Severity: normal
> Tags: patch
> 
> As stated in the title, the changelog header has the wrong format.
> 
> Specfile documentation:
> https://rpm-packaging-guide.github.io/#working-with-spec-files
> ...
>  Follow this format for the first line:
> 
>  * Day-of-Week Month Day Year Name Surname  - Version-Release
> ...

This makes sense. Fedora uses the same format, e.g.

   https://src.fedoraproject.org/rpms/phosh/blob/rawhide/f/phosh.spec

You need to fixup the tests too though, e.g.:

==
FAIL: Test set_header() method
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/var/scratch/src/git-buildpackage/git-buildpackage/tests/30_test_rpm_changelog.py",
 line 99, in test_set_header
eq_(str(section), "* Thu Jan 30 2014 Jane  1.1\n- my change\n\n")
AssertionError: '* Thu Jan 30 2014 Jane  - 1.1\n- my change\n\n' != '* Thu 
Jan 30 2014 Jane  1.1\n- my change\n\n'

Cheers,
 -- Guido




> 
> I have provided a patch on Github at
> https://github.com/agx/git-buildpackage/pull/89
> 
> The patch is also attached to this bug report.
> 
> Thank you,
> 
> -- 
> Samuel Henrique 

> From 310db2177f3a43e1584682f21c43ac0de6c495e6 Mon Sep 17 00:00:00 2001
> From: Samuel Henrique 
> Date: Mon, 1 Aug 2022 18:49:19 +0100
> Subject: [PATCH] Fix RPM changelog header format (missing dash before version)
> 
>  As stated in the documentation at:
>  https://rpm-packaging-guide.github.io/#working-with-spec-files
> 
>  "...
>  Follow this format for the first line:
> 
>  * Day-of-Week Month Day Year Name Surname  - Version-Release
>  ..."
> ---
>  gbp/rpm/policy.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py
> index a2155e20..59989bb8 100644
> --- a/gbp/rpm/policy.py
> +++ b/gbp/rpm/policy.py
> @@ -85,7 +85,7 @@ class Changelog(object):
>  body_name_re = r'\[(?P.*)\]'
>  
>  # Changelog header format (when writing out changelog)
> -header_format = "* %(time)s %(name)s <%(email)s> %(revision)s"
> +header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s"
>  header_time_format = "%a %b %d %Y"
>  header_rev_format = "%(version)s"
>  

Bug#1030951: dvhtool: diff for NMU version 1.0.1-6.1

[Guido Günther]

Hi,
On Thu, Feb 09, 2023 at 11:27:03PM +0200, Adrian Bunk wrote:
> Package: dvhtool
> Version: 1.0.1-6
> Severity: normal
> Tags: patch  pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for dvhtool (versioned as 1.0.1-6.1) and uploaded 
> it to DELAYED/1. Please feel free to tell me if I should cancel it.

Never got a notification about the autopktest failure. Thanks a lot for
fixing this up!
Cheers,
 -- Guido

> 
> 
> https://tracker.debian.org/pkg/dvhtool
> 
> Issues preventing migration:
> ∙ ∙ autopkgtest for dvhtool/1.0.1-6: amd64: Regression ♻ , arm64: Regression 
> ♻ , armel: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: 
> Regression ♻ , s390x: Regression ♻ 
> 
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dvhtool/30949163/log.gz
> 
> ...
> autopkgtest [09:28:15]: test command1: dvhtool --print-all 
> /usr/share/doc/dvhtool/examples/volhdr-1.dat
> autopkgtest [09:28:15]: test command1: [---
> bash: line 1: dvhtool: command not found
> autopkgtest [09:28:15]: test command1: ---]
> autopkgtest [09:28:15]: test command1:  - - - - - - - - - - results - - - - - 
> - - - - -
> command1 FAIL non-zero exit status 127
> 
> 
> 
> cu
> Adrian

> diff -Nru dvhtool-1.0.1/debian/changelog dvhtool-1.0.1/debian/changelog
> --- dvhtool-1.0.1/debian/changelog2022-01-13 22:40:03.0 +0200
> +++ dvhtool-1.0.1/debian/changelog2023-02-09 23:23:54.0 +0200
> @@ -1,3 +1,10 @@
> +dvhtool (1.0.1-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Add the path to dvhtool in the autopkgtest.
> +
> + -- Adrian Bunk   Thu, 09 Feb 2023 23:23:54 +0200
> +
>  dvhtool (1.0.1-6) unstable; urgency=medium
>  
>[ Guido Günther ]
> diff -Nru dvhtool-1.0.1/debian/tests/control 
> dvhtool-1.0.1/debian/tests/control
> --- dvhtool-1.0.1/debian/tests/control2022-01-13 22:38:52.0 
> +0200
> +++ dvhtool-1.0.1/debian/tests/control2023-02-09 23:23:51.0 
> +0200
> @@ -1,2 +1,2 @@
> -Test-Command: dvhtool --print-all 
> /usr/share/doc/dvhtool/examples/volhdr-1.dat
> +Test-Command: /usr/sbin/dvhtool --print-all 
> /usr/share/doc/dvhtool/examples/volhdr-1.dat
>  Depends: @

Bug#1030709: bullseye-pu: package libvirt/7.0.0-3+deb11u2

[Guido Günther]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libv...@packages.debian.org
Control: affects -1 + src:libvirt

This update fixes the test failures on arm64 that were
detected by the 7.0.0-3+deb11u1 build.

[ Impact ]
We can't do any further updates of libvirt in stable (unless we
disable the test suite or specific tests).

[ Risks ]
As this doesn't affect actual code in a binary packages the
risk should be fairly low.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Backport to upstream patches to fix libxl test failures
triggered by newer xen versions.

Cheers,
 -- Guido
diff --git a/debian/changelog b/debian/changelog
index 28579ccd7e..76fb402cbc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libvirt (7.0.0-3+deb11u2) bullseye; urgency=medium
+
+  * [461d540] Fix libxl config test failures.
+Backports two commits from upstream to not fail with newer xen.
+
+ -- Guido Günther   Mon, 06 Feb 2023 17:50:14 +0100
+
 libvirt (7.0.0-3+deb11u1) bullseye; urgency=medium
 
   [ Guido Günther ]
diff --git a/debian/patches/backport/tests-Fix-libxlxml2domconfigtest-with-latest-xen.patch b/debian/patches/backport/tests-Fix-libxlxml2domconfigtest-with-latest-xen.patch
new file mode 100644
index 00..b30cd52dc1
--- /dev/null
+++ b/debian/patches/backport/tests-Fix-libxlxml2domconfigtest-with-latest-xen.patch
@@ -0,0 +1,235 @@
+From: Cole Robinson 
+Date: Thu, 27 Oct 2022 08:51:25 -0400
+Subject: tests: Fix libxlxml2domconfigtest with latest xen
+
+shadow_memkb is populated from a libxl API call, and the value can
+change. For example:
+https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2c992810854a15b41be920519ce83a4a328d5168
+
+Mock libxl_get_required_shadow_memory to give consistent output
+
+Reviewed-by: Michal Privoznik 
+Signed-off-by: Cole Robinson 
+(cherry picked from commit 72d4709ab901dd3699d342f15ca3aff9bffddf96)
+---
+ tests/libxlmock.c| 11 +++
+ tests/libxlxml2domconfigdata/basic-hvm.json  |  2 +-
+ tests/libxlxml2domconfigdata/basic-pv.json   |  2 +-
+ tests/libxlxml2domconfigdata/basic-pvh.json  |  2 +-
+ tests/libxlxml2domconfigdata/cpu-shares-hvm.json |  2 +-
+ tests/libxlxml2domconfigdata/fullvirt-acpi-slic.json |  2 +-
+ tests/libxlxml2domconfigdata/fullvirt-cpuid-legacy-nest.json |  2 +-
+ tests/libxlxml2domconfigdata/fullvirt-cpuid.json |  2 +-
+ tests/libxlxml2domconfigdata/max-eventchannels-hvm.json  |  2 +-
+ tests/libxlxml2domconfigdata/max-gntframes-hvm.json  |  2 +-
+ tests/libxlxml2domconfigdata/moredevs-hvm.json   |  2 +-
+ tests/libxlxml2domconfigdata/multiple-ip.json|  2 +-
+ tests/libxlxml2domconfigdata/variable-clock-hvm.json |  2 +-
+ tests/libxlxml2domconfigdata/vnuma-hvm-legacy-nest.json  |  2 +-
+ tests/libxlxml2domconfigdata/vnuma-hvm.json  |  2 +-
+ 15 files changed, 25 insertions(+), 14 deletions(-)
+
+diff --git a/tests/libxlmock.c b/tests/libxlmock.c
+index a36ca13..644b8ef 100644
+--- a/tests/libxlmock.c
 b/tests/libxlmock.c
+@@ -95,6 +95,17 @@ VIR_MOCK_STUB_RET_ARGS(bind,
+const struct sockaddr *, addr,
+socklen_t, addrlen)
+ 
++VIR_MOCK_IMPL_RET_ARGS(libxl_get_required_shadow_memory,
++   unsigned long,
++   unsigned long, maxmem_kb,
++   unsigned int, smp_cpus)
++{
++/* silence gcc warning about unused function */
++if (0)
++real_libxl_get_required_shadow_memory(maxmem_kb, smp_cpus);
++return 1234;
++}
++
+ VIR_MOCK_IMPL_RET_ARGS(__xstat, int,
+int, ver,
+const char *, path,
+diff --git a/tests/libxlxml2domconfigdata/basic-hvm.json b/tests/libxlxml2domconfigdata/basic-hvm.json
+index 87f8cb7..d308754 100644
+--- a/tests/libxlxml2domconfigdata/basic-hvm.json
 b/tests/libxlxml2domconfigdata/basic-hvm.json
+@@ -15,7 +15,7 @@
+ "max_memkb": 1048576,
+ "target_memkb": 1048576,
+ "video_memkb": 8192,
+-"shadow_memkb": 12288,
++"shadow_memkb": 1234,
+ "device_model_version": "qemu_xen",
+ "device_model": "/bin/true",
+ "sched_params": {
+diff --git a/tests/libxlxml2domconfigdata/basic-pv.json b/tests/libxlxml2domconfigdata/basic-pv.json
+index b71c3b0..32d188f 100644
+--- a/tests/libxlxml2domconfigdata/basic-pv.json
 b/tests/libxlxml2domconfigdata/basic-pv.json
+@@ -14,7 +14,7 @@
+ ],
+ "max_memkb&q

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Guido Günther]

Hi Adam,
On Sat, Feb 04, 2023 at 06:00:49PM +, Adam D. Barratt wrote:
> Hi Guido,
> 
> On Wed, 2022-12-14 at 20:00 +0100, Guido Günther wrote:
> > Hi,
> > On Mon, Dec 12, 2022 at 06:39:42PM +, Adam D. Barratt wrote:
> > > On Sun, 2022-12-11 at 16:24 +0100, Guido Günther wrote:
> > > > Hi Adam,
> > > > On Wed, Dec 07, 2022 at 08:22:41PM +, Adam D. Barratt wrote:
> > > > > Control: tags -1 + confirmed
> > > > > 
> > > > > On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> > > > > > Fix lxc container reboots and shutdown (#983871, #991773).
> > > > > > 
> > > > > 
> > > > > Please go ahead.
> > > > 
> > > > Uploaded now, thanks!
> > > 
> > > Unfortunately the build fails on both arm64 and armhf while running
> > > the
> > > test suite. Each has been tried a couple of times, for a total of
> > > four
> > > different buildds across three hosters between them.
> > 
> > Thanks for letting me know! I'll have a look (I assume that the
> > current
> > version in stable will fail the same way).
> > 
> 
> Did you have any luck with this?

I think so. I'll open a bug with the debdiff against release.debian.org.
Cheers,
 -- Guido

> 
> Regards,
> 
> Adam
> 

Bug#1030044: gbp-pq: Unreproducible and noisy patches due to different diff settings/algorithms

[Guido Günther]

Hi,
On Mon, Jan 30, 2023 at 05:36:43PM +0100, Gioele Barabucci wrote:
> Package: git-buildpackage
> Version: 0.9.30
> 
> Dear maintainers of git-buildpackage,
> 
> The patches exported by `gbp-pq` can be wildly different depending on the
> value set in the git option `diff.algorithm`.
> 
> Thus packages where co-maintainers happen to use different `diff.algorithm`
> values undergo a lot of unneeded "diff churn", making it impossible to
> follow the history of the Debian-specific patches.
> 
> This issue can be fixed by forcing the use of a specific diff algorithm
> inside `gbp-pq`, for example by using `--diff-algorithm=histogram` in
> `gbp.git.Repository.diff`.

Yeah, that's kind of expected as no attempt is made to force
options. One possibility would be to have `gbp clone` dump a set of
options into `.git/config` when cloning the repo. Forcing this in a
hardcoded way would disallow people to tweak these which can make
sense depending on the project.

> Another setting that can reduce diff churn and should be forced by `gbp-pq`
> is `diff.rename`, that should be set to `copies`.

Why's that?

Cheers,
 -- Guido

Bug#1030240: wayfire: FTBFS with wlroots 0.16.1

[Guido Günther]

Hi,
On Wed, Feb 01, 2023 at 04:46:14PM +0100, Guido Günther wrote:
> Hi,
> On Wed, Feb 01, 2023 at 04:37:37PM +0100, Andreas Henriksson wrote:
> > On Wed, Feb 01, 2023 at 04:23:00PM +0100, Andreas Henriksson wrote:
> > > On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote:
> > > > Hi,
> > > > [..snip..]
> > > > > This seems to be caused by wlroots/experimental missing a
> > > > > build-dependency on libvulkan-dev and indeed after installing
> > > > > that package the build works again.
> > > > 
> > > > There is a build-dependency on libvulkan-dev. I think what you mean is
> > > > the lack of a dependency in the libwlroots-dev package?
> > > 
> > > Exactly... I've already retitled the bug report (again) to remove
> > > my incorrect use of build-dep, when what I mean was -dev package
> > > depending on another -dev package.
> > 
> > FWIW here are some examples of autopkgtest for checking if pkg-config
> > works for your own -dev packages:
> > https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/
> 
> We have tests for that like ages:
> 
>   
> https://salsa.debian.org/swaywm-team/wlroots/-/blob/debian/latest/debian/tests/
> 
> It just won't trigger if you don't need the vulkan renderer. Feel free
> to submit a patch that exercises that as well.

So I looked at the old logs and why the tests passed:
   
Package vulkan was not found in the pkg-config search path.
Perhaps you should add the directory containing `vulkan.pc'
to the PKG_CONFIG_PATH environment variable
Package 'vulkan', required by 'wlroots', not found
gcc  debian/tests/test.c -lwlroots  -lwayland-server
Build test of debian/tests/test.c succeeded

The tests succeeded as the --libs check correctly prints `-lwlroots`
*and* $(shell pkg-config …) in make doesn't fail on errors. Using a
shell script instead

   https://salsa.debian.org/swaywm-team/wlroots/-/merge_requests/19

will guard against that in the future.
Cheers,
 -- Guido

Bug#1030240: wayfire: FTBFS with wlroots 0.16.1

[Guido Günther]

Hi,
On Wed, Feb 01, 2023 at 05:34:16PM +0100, Andreas Henriksson wrote:
> On Wed, Feb 01, 2023 at 04:46:14PM +0100, Guido Günther wrote:
> > Hi,
> > On Wed, Feb 01, 2023 at 04:37:37PM +0100, Andreas Henriksson wrote:
> [...]
> > > FWIW here are some examples of autopkgtest for checking if pkg-config
> > > works for your own -dev packages:
> > > https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/
> > 
> > We have tests for that like ages:
> > 
> >   
> > https://salsa.debian.org/swaywm-team/wlroots/-/blob/debian/latest/debian/tests/
> > 
> > It just won't trigger if you don't need the vulkan renderer. Feel free
> > to submit a patch that exercises that as well.
> 
> Not sure why your tests doesn't catch this then.
> 
> You can reproduce this as simple as this:
> 
> 1. start with a clean sid chroot (eg. `pbuilder login`)
> 2. add experimental to /etc/apt/sources.list
> 3. apt update
> 4. apt install libwlroots-dev/experimental
> 5. pkg-config --cflags wlroots
> 
> Package vulkan was not found in the pkg-config search path.
> Perhaps you should add the directory containing `vulkan.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'vulkan', required by 'wlroots', not found

I just answered that in another reply to this bug.
 -- Guido

Bug#1030240: wayfire: FTBFS with wlroots 0.16.1

[Guido Günther]

Hi,
On Wed, Feb 01, 2023 at 04:37:37PM +0100, Andreas Henriksson wrote:
> On Wed, Feb 01, 2023 at 04:23:00PM +0100, Andreas Henriksson wrote:
> > On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote:
> > > Hi,
> > > [..snip..]
> > > > This seems to be caused by wlroots/experimental missing a
> > > > build-dependency on libvulkan-dev and indeed after installing
> > > > that package the build works again.
> > > 
> > > There is a build-dependency on libvulkan-dev. I think what you mean is
> > > the lack of a dependency in the libwlroots-dev package?
> > 
> > Exactly... I've already retitled the bug report (again) to remove
> > my incorrect use of build-dep, when what I mean was -dev package
> > depending on another -dev package.
> 
> FWIW here are some examples of autopkgtest for checking if pkg-config
> works for your own -dev packages:
> https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/

We have tests for that like ages:

  
https://salsa.debian.org/swaywm-team/wlroots/-/blob/debian/latest/debian/tests/

It just won't trigger if you don't need the vulkan renderer. Feel free
to submit a patch that exercises that as well.
 -- Guido

> Regards,
> Andreas Henriksson
> 

Bug#1030240: wayfire: FTBFS with wlroots 0.16.1

[Guido Günther]

Hi,
[..snip..]
> This seems to be caused by wlroots/experimental missing a
> build-dependency on libvulkan-dev and indeed after installing
> that package the build works again.

There is a build-dependency on libvulkan-dev. I think what you mean is
the lack of a dependency in the libwlroots-dev package?
 -- Guido

> 
> Every package listed in pkg-config .pc files Requires* must be
> available and thus the package holding the .pc file referenced
> must be a build-dependency... otherwise pkg-config will not work.
> 
> Adding autopkgtest to run pkg-config --cflags --libs etc. and maybe
> build a trivial example application is a great way to make sure
> pkg-config is working as expected (because it's easy to forget to check
> every .pc file changes and cross-check which package provides that and
> if it's listed in build-depends on every update).
> 
> Regards,
> Andreas Henriksson
> 

Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Guido Günther]

Hi,

On Sun, Jan 08, 2023 at 06:54:17PM +0530, Pirate Praveen wrote:
> Package: riseup-vpn,phosh
> severity: grave
> 
> On mobian under phosh (librem 5), riseup-vpn gives error.
> output of riseup-vpn attached.

I don't think the severity is justified for phosh as it's certianly not
unusable or mostly so. I tihnk the same is true for riseup-net.

Cheers,
 -- Guido

> 
> phosh provides polkit-1-auth-agent
> 
> phosh 0.23
> riseup-vpn 0.21.11+ds1-2+b1
> 

> No systray icon available.
> qml: flavor: riseup-vpn
> QSystemTrayIcon::setVisible: No Icon set
> QObject::connect: No such signal 
> QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
> 2023/01/08 18:44:03 Client expects anon auth
> 2023/01/08 18:44:03 Checking for updates...
> qml: delay...
> 2023/01/08 18:44:14 Get "https://downloads.leap.se/RiseupVPN/linux/lastver": 
> net/http: TLS handshake timeout
> 2023/01/08 18:44:14 Fetching MOTD for riseup.net
> 2023/01/08 18:44:16 There are 4 pending messages
> 2023/01/08 18:44:16 firewall stop
> 2023/01/08 18:44:17 Fetching gateways...
> 2023/01/08 18:44:17 Cannot find any usable polkit
> 2023/01/08 18:44:17 ERROR: no polkit
> qml: errors, setting root.error
> qrc:/components/InitErrors.qml:39: ReferenceError: splashSpinner is not 
> defined
> qrc:/components/InitErrors.qml:38:13: QML PropertyChanges: Cannot assign to 
> non-existent property "visible"
> qml: errors, setting root.error
> qml: errors, setting root.error
> 2023/01/08 18:44:38 Close: cleanup and vpn shutdown...
> 2023/01/08 18:44:38 firewall stop
> 2023/01/08 18:44:38 openvpn stop
> 
> Catched signal(2): quitting

Bug#1028465: RM: kopanocore -- ROM; Outdated with noone interested in updating it

[Guido Günther]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: kopanoc...@packages.debian.org, c.schoen...@t-online.de, 
j...@inutil.org
Control: affects -1 + src:kopanocore

Hi,
the package is pretty outdated and there's currently noone interested
to maintaining it. There's no version in stable or testing either, so
let's drop it.

Cheers,
 -- Guido

Bug#1027618: phosh-tour: FTBFS: dh_auto_test: error: cd _build && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 1

[Guido Günther]

Hi,
On Sun, Jan 01, 2023 at 03:33:59PM +0100, Lucas Nussbaum wrote:
> > --- stdout 
> > ---
> > E: sm.puri.PhoshTour.desktop:25: custom-key-duplicated Purism::form_factor
> > I: sm.puri.PhoshTour.desktop:12: summary-first-word-not-capitalized
> > I: sm.puri.PhoshTour.desktop:8: description-first-para-too-short
> >  This apps introduces you to your device via a small graphical tour.

Fixed upstream at
https://gitlab.gnome.org/guidog/phosh-tour/-/merge_requests/7
about to be release end of month which will then go into Debian. 

Cheers,
 -- Guido

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Guido Günther]

Hi,
On Wed, Dec 21, 2022 at 03:04:43PM +0700, Arnaud Rebillout wrote:
> 
> On 15/12/2022 15:54, Guido Günther wrote:
> > Or use `gbp clone --git-defuse-attributes=off ...` ?
> 
> Indeed! Thanks, I didn't notice this option, and I can confirm that it
> solves the issue (the exact option name is "--defuse-gitattributes=off"
> actually).
> 
> I took the time to look a bit at this option and where it comes from
> (seemingly, the goal is that gbp is compatible with other tools such as
> dgit). There's still something that strikes me.
> 
> IIUC, it's *only* "gbp clone" that will defuse the git attributes.
> 
> So developer A does "gbp import-orig", brings in the offending attributes:
> still they are not defused on their local copy. Then developer B does "gbp
> pull", and then no change: gbp does not defuse attributes during pull, so
> attributes are still enabled. Then developer C does "gbp clone", and they
> possibly get a different working copy, because in this case only, attributes
> are defused.
> 
> It seems that this behavior is prone to create problems, albeit it might be
> detected by CI (not sure what Salsa CI does in details), and it's also kind
> of a niche issue anyway.

Changing git attributes is certainly a problem. If someone wants to send
patches to e.g. warn the user about that, that would be useful. That
said I'd expect maintainers to filter out .gitattributes from imported
tarballs (e.g. via uscan / debian/changelog or gbp itself)

I think what we could do is:

- warn about git found in upsteam repos / tarballs
- warn about changing git attributes
- allow to disable the either of these via d/gbo.conf

> We took a look at our packaging repos in Kali Linux (~ 600 repos), and we
> found 3 of them that are unclean on `gbp clone`. It's solved by setting
> --defuse-gitattributes. So we will probably add this argument to our
> .mrconfig, and make sure to use it all the time. We'll see where it
> gets us.

Are these repos based on upstream's git or on tarballs that got those
gitattributes imported?

> 
> I'm really not familiar with git attributes, so I don't have any
> recommendation, or anything else to say, I'm merely reporting in case it
> helps.

We have some tests that test defusing git attributes in gbp. If there's
any of your use cases missing, feel free to add those. That is often
a good step to document expected behavior.

Cheers,
 -- Guido

Bug#1027069: waybar: improve its .service file?

[Guido Günther]

Hi,
On Mon, Jan 02, 2023 at 12:34:09PM +0100, Birger Schacht wrote:
> Hi,
> 
> I asked in the wlroots IRC channel and got the information that it is not
> possible to find out if a program is starting in a wlroots based compositor.
> I thought maybe an environment variable that usable with systemd's
> `ConditionEnvironment` could exist, but apparently thats not the case.
> But I'm open to suggestions how to fix that.

The error is triggered by

```
 wl_display_roundtrip(wl_display);
  if (layer_shell == nullptr || xdg_output_manager == nullptr) {
throw std::runtime_error("Failed to acquire required resources.");
  }
```

so

weston-info 2>/dev/null | grep -E "interface: 'zwlr_layer_shell"

should get you pretty close. This will break once waybar switches to
ext-layer-shell so maybe

weston-info 2>/dev/null | grep -E "interface: 'z(wlr|ext)_layer_shell"

works better.

Cheers,
 -- Guido

> 
> cheers,
> Birger
> 
> 

Bug#1026385: Please use absolute path to auth-dialog in .service file

[Guido Günther]

Hi Michael,
On Fri, Dec 30, 2022 at 11:33:50AM +0100, Michael Biebl wrote:
> Hi,
> 
> I've made an NMU to DELAYED/14.
> 
> Please find attached the debdiff.
> Let me know if you want me to cancel the NMU.

Thanks! NMU is fine. Feel Free to accelerate if it helps.
 -- Guido

Bug#1010207: import-orig: please provide a --force option

[Guido Günther]

Hi,
On Tue, Dec 13, 2022 at 03:00:09PM +0100, Roland Mas wrote:
> Le 29/11/2022 à 17:19, Guido Günther a écrit :
> > Hi,
> > On Tue, Apr 26, 2022 at 03:11:42PM +0200, Roland Mas wrote:
> > > Package: git-buildpackage
> > > Version: 0.9.22
> > > Severity: wishlist
> > > 
> > > There are cases where "gbp import-orig --uscan" exits with a no-op
> > > although a new upstream version should be available:
> > > - a new repack level in d/watch;
> > > - new subcomponents in d/watch;
> > > 
> > > In both cases, the new "upstream" part of the version number is
> > > actually increased (either with +dfsgX or +~csX.Y.Z if using
> > > subcomponents), but to get there you have to perform the ugly trick of
> > > setting the latest version number in d/changelog to 0, then running
> > > gbp import-orig --uscan, then changing the version number back to its
> > > previous value.
> > > 
> > > I think a "gbp import-orig --uscan --force" option would be a nice
> > > addition; it should be a simple matter of running uscan with -ddd.
> > Does giving the version explicitly do the trick for you?
> > 
> > gbp import-orig --uscan --upstream-version=0.23.0~rc1
> > 
> That trick works, thanks. I still think a --force option would be nice, but
> I can live with that workaround.

Great that this works for you! I'm not objecting to a `--force` option
it's just unlikely that I get to add something like this soon.
Cheers,
 -- Guido

> 
> Thank you!
> 
> Roland.
> 

Bug#1026120: git-buildpackage: issues with upstreams LFS files

[Guido Günther]

Hi,
On Thu, Dec 15, 2022 at 12:38:11PM +0700, Arnaud Rebillout wrote:
> Package: git-buildpackage
> Version: 0.9.30
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> 
> Dear Maintainer,
> 
> In Kali Linux, we package an upstream that uses Git LFS to store a big
> file (a GeoIP database). The upstream is at:
> https://github.com/rsmusllp/king-phisher
> 
> In a previous version, upstream used to version the database "as is", it
> was a regular file in the Git repo. Then in a subsequent version, they
> switched to use Git LFS to store this file.
> 
> Gbp doesn't handle this transition well, apparently this is due to the
> combination of:
> * "gbp clone" disabling Git attributes (hence git lfs)
> * however "gbp import-orig" does no such thing
> 
> I'm the person who updated this package, so my local copy of
> king-phisher doesn't have the git attributes disabled, and everything
> works fine with me. However other folks who clone the repo complain, as
> it leads to an unclean git checkout, and I don't know what's the way
> forward.
> 
> For a longer (and hopefully crystal-clear) explanation of the issue, I
> prepared a Git repo and a walkthrough to reproduce the issue. There we
> go :)
> 
> Let's first clone the king-phisher package *before* upstream switched to
> Git LFS:
> 
>   $ gbp clone https://gitlab.com/arnaudr/king-phisher.git
>   $ cd king-phisher
>   $ cat .gitattributes
>   cat: .gitattributes: No such file or directory
>   $ ls -l data/server/king_phisher/GeoLite2-City.mmdb 
>   -rw-r--r-- 1 arno arno 61615395 Dec 15 11:53 
> data/server/king_phisher/GeoLite2-City.mmdb
> 
> So at this point, the file GeoLite2-City.mmdb is versioned "as is", it
> is a regular file.
> 
> Now let's update the package to latest Git snapshot:
> 
>   $ gbp import-orig --uscan
>   gbp:info: Launching uscan...
>   Downloading data/server/king_phisher/GeoLite2-City.mmdb (62 MB)
>   gbp:info: Using uscan downloaded tarball 
> ../king-phisher_1.15.0+git20221107.orig.tar.xz
>   What is the upstream version? [1.15.0+git20221107] 
>   gbp:info: Importing '../king-phisher_1.15.0+git20221107.orig.tar.xz' to 
> branch 'upstream'...
>   gbp:info: Source package is king-phisher
>   gbp:info: Upstream version is 1.15.0+git20221107
>   gbp:info: Replacing upstream source on 'kali/master'
>   gbp:info: Successfully imported version 1.15.0+git20221107 of 
> ../king-phisher_1.15.0+git20221107.orig.tar.xz
> 
> The line "Downloading data/server/king_phisher/GeoLite2-City.mmdb (62
> MB" comes from git lfs, which is downloading the file. And here's the
> situation now:
> 
>   $ cat .gitattributes 
>   *.mmdb filter=lfs diff=lfs merge=lfs -text
>   $ cat .git/info/attributes
>   cat: .git/info/attributes: No such file or directory
>   $ ls -l data/server/king_phisher/GeoLite2-City.mmdb
>   -rw-r--r-- 1 arno arno 61615395 Dec 15 11:56 
> data/server/king_phisher/GeoLite2-City.mmdb
> 
> So we can see the git lfs thinggy, and we can see that
> .git/info/attributes' doesn't exist (more on that below).
> 
> Let's push that work (I prepared a fork to push changes):
> 
>  $ git remote add arnaudr2 g...@gitlab.com:arnaudr/king-phisher2.git
>  $ git push arnaudr2 : --follow-tags
>   Locking support detected on remote "arnaudr2". Consider enabling it with:
> $ git config 
> lfs.https://gitlab.com/arnaudr/king-phisher2.git/info/lfs.locksverify true
>   Locking support detected on remote "arnaudr2". Consider enabling it with:
> $ git config 
> lfs.https://gitlab.com/arnaudr/king-phisher2.git/info/lfs.locksverify true
>   Locking support detected on remote "arnaudr2". Consider enabling it with:
> $ git config 
> lfs.https://gitlab.com/arnaudr/king-phisher2.git/info/lfs.locksverify true
>   Locking support detected on remote "arnaudr2". Consider enabling it with:
> $ git config 
> lfs.https://gitlab.com/arnaudr/king-phisher2.git/info/lfs.locksverify true
>   Uploading LFS objects: 100% (1/1), 62 MB | 3.4 MB/s, done.
>   Enumerating objects: 112, done.
>   Counting objects: 100% (82/82), done.
>   Delta compression using up to 8 threads
>   Compressing objects: 100% (46/46), done.
>   Writing objects: 100% (49/49), 19.06 KiB | 19.06 MiB/s, done.
>   Total 49 (delta 29), reused 5 (delta 0), pack-reused 0
>   remote:
>   remote: To create a merge request for pristine-tar, visit:
>   remote:   
> https://gitlab.com/arnaudr/king-phisher2/-/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
>   remote:
>   remote:
>   remote: To create a merge request for upstream, visit:
>   remote:   
> https://gitlab.com/arnaudr/king-phisher2/-/merge_requests/new?merge_request%5Bsource_branch%5D=upstream
>   remote:
>   To gitlab.com:arnaudr/king-phisher2.git
>  c5db68b..dbf4ce7  kali/master -> kali/master
>  d9ec6a5..e4e9390  pristine-tar -> pristine-tar
>  be63910..f4f0fae  upstream -> upstream
>* [new tag] upstream/1.15.0+git20221107 -> 
> upstream/1.15.0+git20221107
> 
> And now, the issue: when we 

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Guido Günther]

Hi,
On Mon, Dec 12, 2022 at 06:39:42PM +, Adam D. Barratt wrote:
> On Sun, 2022-12-11 at 16:24 +0100, Guido Günther wrote:
> > Hi Adam,
> > On Wed, Dec 07, 2022 at 08:22:41PM +, Adam D. Barratt wrote:
> > > Control: tags -1 + confirmed
> > > 
> > > On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> > > > Fix lxc container reboots and shutdown (#983871, #991773).
> > > > 
> > > 
> > > Please go ahead.
> > 
> > Uploaded now, thanks!
> 
> Unfortunately the build fails on both arm64 and armhf while running the
> test suite. Each has been tried a couple of times, for a total of four
> different buildds across three hosters between them.

Thanks for letting me know! I'll have a look (I assume that the current
version in stable will fail the same way).

Cheers,
 -- Guido

> 
> In each case the failure looks the same:
> 
> 
>  94/167 libxlxml2domconfigtest  FAIL   0.17s (exit
> status 1)
> 
> --- command ---
> 21:04:12 abs_top_srcdir='/<>' LC_ALL='C'
> abs_srcdir='/<>/tests' LIBVIRT_AUTOSTART='0'
> G_DEBUG='fatal-warnings'
> abs_top_builddir='/<>/debian/build'
> abs_builddir='/<>/debian/build/tests'
> VIR_TEST_EXPENSIVE='1'
> /<>/debian/build/tests/libxlxml2domconfigtest
> --- stderr ---
> TEST: libxlxml2domconfigtest
>  1) LibXL XML-2-JSON basic-
> pv ... 
> Offset 349
> Expect [8192]
> Actual [6144]
>   .
> .. FAILED
>  2) LibXL XML-2-JSON basic-
> hvm... 
> Offset 382
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
>  3) LibXL XML-2-JSON basic-
> pvh... 
> Offset 351
> Expect [8192]
> Actual [6144]
>   .
> .. FAILED
>  4) LibXL XML-2-JSON cpu-shares-
> hvm   ... 
> Offset 382
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
>  5) LibXL XML-2-JSON variable-clock-
> hvm   ... 
> Offset 382
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
>  6) LibXL XML-2-JSON moredevs-
> hvm ... 
> Offset 435
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
>  7) LibXL XML-2-JSON multiple-
> ip  ... 
> Offset 349
> Expect [8192]
> Actual [6144]
>   .
> .. FAILED
>  8) LibXL XML-2-JSON vnuma-
> hvm... 
> Offset 413
> Expect [4336]
> Actual [0240]
>   .
> .. FAILED
>  9) LibXL XML-2-JSON fullvirt-
> cpuid   ... 
> Offset 307
> Expect [5656]
> Actual [3340]
>   .
> .. FAILED
> 10) LibXL XML-2-JSON fullvirt-acpi-
> slic   ... 
> Offset 307
> Expect [5656]
> Actual [3340]
>   .
> .. FAILED
> 11) LibXL XML-2-JSON max-gntframes-
> hvm... 
> Offset 382
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
> 12) LibXL XML-2-JSON max-eventchannels-
> hvm... 
> Offset 382
> Expect [12288]
> Actual [8192]
>   .
> .. FAILED
> Some tests failed. Run them using:
> VIR_TEST_DEBUG=1 VIR_TEST_RANGE=1-12
> /<>/debian/build/tests/libxlxml2domconfigtest
> ---
> 
> Regards,
> 
> Adam
> 

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Guido Günther]

Hi Adam,
On Wed, Dec 07, 2022 at 08:22:41PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> > Fix lxc container reboots and shutdown (#983871, #991773).
> > 
> 
> Please go ahead.

Uploaded now, thanks!
 -- Guido

> 
> Regards,
> 
> Adam
> 

Bug#1025870: libwlroots10: phosh crashes sometimes due to bug in wlroots (patch available)

[Guido Günther]

Hi Lukas,
On Sat, Dec 10, 2022 at 11:26:00PM +0100, Lukas Straub wrote:
> Package: libwlroots10
> Version: 0.15.1-3
> Severity: normal
> X-Debbugs-Cc: lukasstra...@web.de
> 
> Dear Maintainer,
> 
> I'm using Mobian phosh on a pinephone (non-pro). Sometimes (twice per week) 
> when waking from
> sleep, phosh crashes due to a bug in wlroots and brings down the whole 
> session with it.
> 
> This bug has been solved upstream, there's a patch in wlroots 0.16 that can 
> be backported
> to 0.15 and fixes this issue.
> 
> It's the patch here:
> https://gitlab.gnome.org/World/Phosh/phoc/-/issues/300#note_1595892
> 
> I tested wlroots 0.15.1-3 with this patch applied and that solved the
> issue for me.

I've had that on the list for this weekend, uploaded now. In the future
if you test a patch you can also make an MR right away on salsa (in this
case at https://salsa.debian.org/swaywm-team/wlroots) as this makes
things easier to apply.

Cheers,
 -- Guido

> 
> Regards,
> Lukas Straub
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libwlroots10 depends on:
> ii  libc62.36-5
> ii  libdrm2  2.4.114-1
> ii  libegl1  1.5.0-1
> ii  libgbm1  22.2.4-1
> ii  libgles2 1.5.0-1
> ii  libinput10   1.22.0-1
> ii  libpixman-1-00.42.2-1
> ii  libseat1 0.7.0-5+b1
> ii  libudev1 252.2-1
> ii  libwayland-client0   1.21.0-1
> ii  libwayland-server0   1.21.0-1
> ii  libxcb-composite01.15-1
> ii  libxcb-dri3-01.15-1
> ii  libxcb-icccm40.4.1-1.1
> ii  libxcb-present0  1.15-1
> ii  libxcb-render-util0  0.3.9-1+b1
> ii  libxcb-render0   1.15-1
> ii  libxcb-res0  1.15-1
> ii  libxcb-shm0  1.15-1
> ii  libxcb-xfixes0   1.15-1
> ii  libxcb-xinput0   1.15-1
> ii  libxcb1  1.15-1
> ii  libxkbcommon01.4.1-1
> 
> libwlroots10 recommends no packages.
> 
> libwlroots10 suggests no packages.
> 
> -- no debconf information

Bug#1024970: dch: also look for Gbp-Dch: commands in git notes

[Guido Günther]

Hi Antonio,
On Sun, Nov 27, 2022 at 08:26:24PM -0300, Antonio Terceiro wrote:
> Package: git-buildpackage
> Version: 0.9.30
> Severity: wishlist
> Tags: patch
> 
> This allows one for example to add commands (e.g. `Gbp-Dch: ignore`) to
> past commits, without having to rewrite the git history. This is
> implemented in the attached patches.

Thanks. That looks like a good idea. One thing I wonder about is if we
need a switch for that in case people use git notes for something else
already and match gbp's format? I'm leaning towards avoiding yet another
switch though - we can add it if it causes trouble.

The one thing that would be great to have before appying this would be a
test case (e.g. by adding an integration test to

   tests/component/deb/test_dch.py
   
Cheers,
 -- Guido

> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (500, 
> 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages git-buildpackage depends on:
> pn  devscripts 
> ii  git1:2.35.1-1
> ii  man-db 2.11.1-1
> ii  python33.10.6-1
> ii  python3-dateutil   2.8.2-1
> ii  python3-pkg-resources  65.5.0-1
> ii  python3-yaml   6.0-3+b1
> ii  sensible-utils 0.0.17
> 
> Versions of packages git-buildpackage recommends:
> ii  cowbuilder0.89
> ii  pbuilder  0.231
> ii  pristine-tar  1.50
> ii  python3-requests  2.28.1+dfsg-1
> ii  sbuild0.84.1
> 
> Versions of packages git-buildpackage suggests:
> pn  python3-notify2  
> ii  sudo 1.9.11p3-2
> ii  unzip6.0-27
> 
> -- no debconf information

> From 6efae4fd4ded2e456634439f388137fa3c52cac6 Mon Sep 17 00:00:00 2001
> From: Antonio Terceiro 
> Date: Sun, 27 Nov 2022 13:14:36 -0300
> Subject: [PATCH 1/2] GitCommit.get_commit_info: extract commit notes
> 
> ---
>  gbp/git/repository.py | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/gbp/git/repository.py b/gbp/git/repository.py
> index edbdfe9f..81ae70c9 100644
> --- a/gbp/git/repository.py
> +++ b/gbp/git/repository.py
> @@ -1712,7 +1712,7 @@ class GitRepository(object):
>  to the commit it points to.
>  
>  @param commitish: the commit-ish to inspect
> -@return: the commit's including id, author, email, subject and body
> +@return: the commit's including id, author, email, subject, body, 
> and notes
>  @rtype: dict
>  """
>  commit_sha1 = self.rev_parse("%s^0" % commitish)
> @@ -1744,12 +1744,15 @@ class GitRepository(object):
>  path = file_fields.pop(0)
>  files[status].append(path)
>  
> +notes, _, _ = self._git_inout('notes', ['show', commit_sha1], 
> capture_stderr=True)
> +
>  return {'id': commitish,
>  'author': author,
>  'committer': committer,
>  'subject': fields[6].decode(),
>  'patchname': fields[7].decode(),
>  'body': fields[8].decode(),
> +'notes': notes.decode(),
>  'files': files}
>  
>  #{ Patches
> -- 
> 2.35.1
> 

> From 8db4c62bc1192ecb575d567e5df00ff2f7f0cdee Mon Sep 17 00:00:00 2001
> From: Antonio Terceiro 
> Date: Sun, 27 Nov 2022 19:52:46 -0300
> Subject: [PATCH 2/2] dch: also look into commit notes for Gbp-Dch: commands
> 
> This allows one for example to add commands (e.g. `Gbp-Dch: ignore`) to
> past commits, without having to rewrite the git history.
> ---
>  docs/manpages/gbp-dch.xml | 10 +++---
>  gbp/dch.py|  2 +-
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/manpages/gbp-dch.xml b/docs/manpages/gbp-dch.xml
> index bb9574cb..8250488b 100644
> --- a/docs/manpages/gbp-dch.xml
> +++ b/docs/manpages/gbp-dch.xml
> @@ -569,9 +569,9 @@
>  Additional to the above options, the formatting of the commit message
>  in debian/changelog can be modified by special tags
>  (called Meta Tags)
> -given in the git commit message. Meta Tag processing can be activated via
> -the --meta option. The tags must start at the first 
> column of
> -a commit message but can appear on any line.
> +given in the git commit message or in commit notes. Meta Tag processing 
> can
> +be activated via the --meta option. The tags must start
> +at the first column of a commit message but can appear on any line.
>  They are of the form Tagname:
>  value. Valid Meta Tags are:
>  
> @@ -650,6 +650,10 @@
>,
>,
>
> +  
> +  

Bug#1010207: import-orig: please provide a --force option

[Guido Günther]

Hi,
On Tue, Apr 26, 2022 at 03:11:42PM +0200, Roland Mas wrote:
> Package: git-buildpackage
> Version: 0.9.22
> Severity: wishlist
> 
> There are cases where "gbp import-orig --uscan" exits with a no-op
> although a new upstream version should be available:
> - a new repack level in d/watch;
> - new subcomponents in d/watch;
> 
> In both cases, the new "upstream" part of the version number is
> actually increased (either with +dfsgX or +~csX.Y.Z if using
> subcomponents), but to get there you have to perform the ugly trick of
> setting the latest version number in d/changelog to 0, then running
> gbp import-orig --uscan, then changing the version number back to its
> previous value.
> 
> I think a "gbp import-orig --uscan --force" option would be a nice
> addition; it should be a simple matter of running uscan with -ddd.

Does giving the version explicitly do the trick for you?

   gbp import-orig --uscan --upstream-version=0.23.0~rc1

Cheers,
 -- Guido

Bug#1025060: ITP: phosh-osk-stub -- An experimental on screen keyboard for Phosh

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: phosh-osk-stub
  Version : 0.23.0~rc1
  Upstream Author : Guido Günther
* URL : https://gitlab.gnome.org/guidog/phosh-osk-stub
* License : GPL
  Programming Lang: C
  Description : A minimalistic, experimental on screen keyboard for Phosh

 phosh-osk-stub implements phosh's keyboard interface for ease of
 experimentation. The focus is on ease of change and to help debugging
 input related issues.  It features character popovers, gesture based
 cursor navigation and text completion.
 .
 For production use it's recommended to use Phosh's official on screen
 keyboard squeekboard.

 phosh-osk-stub used to live in phosh's source tree but was split out
 with phosh 0.16.0. Since then it grew in features. I'll upload to
 experimental as it is not meant to replace squeekboard but rather to
 have a small implementation that can be swapped out to ease debugging
 or help on platforms that have trouble building rust.