from:"daniel"

On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote:
> >https://salsa.debian.org/debian/lsm
> 
> I'm already using gbp, on my own repository server
> 
> https://git.gnuabordo.com.br/foolsm.git/, I haven't created the salsa
> account yet.

Ah. You should have put that in the Vcs-{Git,Browse} headers for everyone
to find then :)

FYI: Vcs-Git also supports specifying a branch which may be useful in your
case if the repo's default HEAD isn't the debianization.

> > d/rules:
> > > DEBUG=true
> > I'm not sure how to feel about this. Do you have a reason for turning it
> > on? Seems the last upload had it commented out. From a quick codereivew it
> > does look to just add more logging, so it's probably fine?
> Ops, built upon wrong git branch. = ) I'm going upload a new package.

> > Looking at the generated maintainerscripts in the foolsm deb I don't see
> > anything related to dpkg-maintscript-helper, are you sure that's hooked up
> > right? Good job finding that obscurica BTW I didn't know about that myself
> > :)
> 
> Nope, the maintscript is right, should be ran just for lsm update, or
> somehow the lsm is installed but foolsm is available.

Brainfart I was just looking at the wrong package.

> The script will check if /etc/lsm/lsm.conf already exist, then it'll move
> the conf file.

Great. Just what I wanted.

> > I also noticed the upstream tarballs have started including a debian/
> > directory for a non-native packaging. Do you know what's up with that? I
> > could see why they would include it if they packaged it as a "native"
> > package but for non-native it just makes no sense. Could you talk to
> > upstream to figure out what's up with that? Feel free to CC me.
>
> My guess is they would try update the package because I had missed.

Perhaps. Would still be nice if they could remove it again. Please shoot
them a mail. It's always a good idea to keep in contact with upstream
anyway, even when it's just a "look we packaged your latest release, here's
some notes" thing.

Getting their stuff into a wideley deployed distro like Debian is positive
feedback for people doing the unthankful job of publishing free
software. We provide as much of that kind of feedback to our upstreams as
possible.

> > Just FYI: I'd appreciate git commits/patches on top of my repo above
> > instead of an updated dsc dump.
> 
> As I mentioned, I don't have a salsa account, I really would like to keep my
> own repository by now, maybe soon I'll create an account.

No, there's no need really. I can pull from your repo and push to salsa, no
problem. See for the sponsorship workflow (with git) to work well for any
random DD it's best if they already have access to the repo listed in
Vcs-Git (as is the case on salsa) since they are expected to push debian/*
tags and (possibly) d/changelog updates or minor fixes there.

You can keep your repo and just tell sponsors to pull from it by adding an
additional line to the usual sponsorship message. DDs can then decide
whether to use it or not. That's how I would do it anyway.

I'll base the debian/lsm repo on your repo's state then. I do have some
review notes though:

The branch naming is non-standard see [DEP-14]. Convention is debian/latest
(used to be debian/master) or debian/unstable (used to be debian/sid) for
the development branch. I haven't looked at that document in a while either
I guess since I still use debian/sid everywhere but they changed the
recommendation from debian/$codename to debian/$suite in 2020.

[DEP-14]: https://dep-team.pages.debian.net/deps/dep14/

Further you have a number of debian/* tags in your repo that don't exist in
the debian archive. That's not going to do. If you keep your own archive of
packages you should make use of the DEP-14 $vendor feature and have
branches/tags named, say gnuabordo/*.

Since you'd have to adjust d/gbp.conf for your repo's use with something
like

 [DEFAULT]
 debian-branch = gnuabordo/latest
 debian-tag = gnuabordo/%(version)s

and keep that on a separate branch from actual Debian packaging. Thats
obviously more work, so another way to go would be to just not tag your
internal uploads. That what I tend to do when I have something I want to
deply right away and don't feel like waiting on NEW review.

Might just be easier to apply to become DM for lsm and just not have so
much of a need for a local repo ;)

--Daniel

signature.asc
Description: PGP signature

Bug#1070642: RM: qflow/experimental -- ROM; depends on RMed graywolf,berkeley-abc

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: qf...@packages.debian.org, gayw...@packages.debian.org, 
d...@darkboxed.org
Control: affects -1 + src:qflow


Hi,

I've requested removal of bekerley-abc and rdeps from unstable
previously in Bug#1069032, but forgot about experimental (thanks
Andreas Beckmann for the reminder).

Please also remove qflow from experimental. Rationale is the same as
before, please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069032

Thanks,
--Daniel

Bug#1069032: RM: berkeley-abc (+ qflow and graywolf) -- ROM; replaced by yosys-abc

Hi Andreas,

On Thu, May 02, 2024 at 09:33:20AM +0200, Andreas Beckmann wrote:
> should qflow/experimental be removed as well?

Right, I forgot about experimental. Thanks for the reminder.

> (please file a new RM bug in case you opt for removal)

Will do, thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

Hi Lucas,
Hi d-mentors (there's a workflow question below),

On Sun, Mar 24, 2024 at 05:16:54PM -0300, Lucas Castro wrote:
> The source builds the following binary packages:
> 
>   foolsm - Link connectivity monitor tool
>   lsm - Link connectivity monitor tool - transitional package
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/lsm/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -xhttps://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.21-1.dsc

I like using git since it makes dsc review easier. I've converted the
upstream tarball history and your uploads to git using gbp and put them
here:

  https://salsa.debian.org/debian/lsm

If you don't want to use git that's fine it's just a convinience for the me
or the next DD to sponsor lsm but I'd be happy to help you figure out the
Debian git workflow if you want.

Package Review
--

d/changelog:
> lsm (1.0.21-1) unstable; urgency=medium
> .
>   * New upstream release (Closes: #1041221)
>   * Usrmerge compliance (Closes: #1054086)

Could be more specific. "Use dh_installsystemd to install units" maybe?

>   * Package rename

Use imperative in changelogs and be more specific: "Rename package to
'foolsm' to stay consistent with upstream" or some such.

>  - Added transitional package for renaming process

More specific please. I'd go with straight prose and not bullet-points
myself. Say: "The old 'lsm' package is now transitional and installs the
new 'foolsm' package.

>  - Debian package was modified after upstream project rename.

I'm not sure what you're trying to tell me here?

>   * debian/watch updated
>   * debian/patches/ cleaned out

IMO these are implied. Ofc. we're going to do that when we update a package
in Debian so while these would make good git commits I don't think they
should be in d/changelog since that's mostly user-facing.

Maybe that's just my git sensibilities showing and it's perfectly
appropriate to note this in d/changelog for the old dsc focused workflow?
Feel free to rebuttle this point.

d/copyright:
> Files: *
> Copyright: 2009-2016 Mika Ilmaranta 
>2009-2015 Tuomo Soini 

licensecheck finds newer copyright dates, some ftp reviewers like to be
pedantic here and since we'll make a trip through NEW its best to be exact
here, should be:

Copyright: 2009-2019 Mika Ilmaranta 
   2009-2021 Tuomo Soini 

d/rules:
> DEBUG=true

I'm not sure how to feel about this. Do you have a reason for turning it
on? Seems the last upload had it commented out. From a quick codereivew it
does look to just add more logging, so it's probably fine?

Looking at the generated maintainerscripts in the foolsm deb I don't see
anything related to dpkg-maintscript-helper, are you sure that's hooked up
right? Good job finding that obscurica BTW I didn't know about that myself
:)

man says:

> When using a packaging helper, please check if it has native
> dpkg-maintscript-helper integration, which might make your life
> easier. See for example dh_installdeb(1).

Hmm. I do see:

$ cat debian/lsm.preinst.debhelper
# Automatically added by dh_installdeb/13.11.4
dpkg-maintscript-helper mv_conffile /etc/lsm/lsm.config 
/etc/foolsm/foolsm.conf 1.0.21\~ -- "$@"
# End automatically added section

but that somehow doesn't seem to make it into the deb. Oh. The
lsm.maintscript probably has to be called s/lsm/foolsm/ for it to work.

Random notes:

I also noticed the upstream tarballs have started including a debian/
directory for a non-native packaging. Do you know what's up with that? I
could see why they would include it if they packaged it as a "native"
package but for non-native it just makes no sense. Could you talk to
upstream to figure out what's up with that? Feel free to CC me.

Just FYI: I'd appreciate git commits/patches on top of my repo above
instead of an updated dsc dump.

Thanks,
--Daniel

signature.asc
Description: PGP signature

Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

pt, hmm. Bonus points for
forwarding this bug and patch upstream.


Git Review
--

Now, let's get into the review. Here's what I see -- if you're not reading
this in a monospace font this is the time to reconsider your ~life~
eer. config choices :D

84c24 * debian/sid origin/debian/sid Release 0.4.6-2 Samo Pogačnik  2d
ac9b0 * d/*: Fixed bash-completion integration with gi$  Samo Pogačnik  2d
ce3fb *   git-debrebase import: declare upstream Samo Pogačnik  2w
  |\  
c9552 * | git-debrebase convert-from-gbp: drop patches$  Samo Pogačnik  2w
873da * | Release 0.4.6-1Samo Pogačnik  3w
51d5b * | d/control: Set myself as MaintainerSamo Pogačnik  3w
43a8c * | d/control: Point Vcs to new location (salsa/$  Samo Pogačnik  3w
bf7e8 * | Merge tag '0.4.6' into debian/sid  Samo Pogačnik  4w
  |\|     
5a1ed * | Revert "Update changelog for 0.4.3-2 release$  Daniel Gröber  3Y
4e559 * | origin/ci/salsa Add salsa-ci configDaniel Gröber  3Y
181d5 * | debian/0.4.3-2 Update changelog for 0.4.3-2 $  Daniel Gröber  3Y
b6c79 * | Fix Vcs URLs, s/guest-dxld/dxld-guest/ Daniel Gröber  3Y
f180e * | debian/0.4.3-1 Initial release. (Closes: #91$  Daniel Gröber  3Y
73a01 | | * upstream origin/upstream docs: Replace 404$  Edwin Kofler   5M
  | |/    
110b9 | * 0.4.6 Release 0.4.6Austin Morgan  1Y
3994d | * Add test for empty pushandreasxp  1Y
89f56 | * Remove unneeded worktree on push   Daniel Bauten  4Y
c14bf | * Remove worktree in pushDaniel Bauten  4Y
dbb99 | * Remove branch creation from GitHub Action  Matijs van Z$  2Y
84854 | * Do not depend on main repo for status testsMatijs van Z$  4Y
aa416 | * 0.4.5 Release 0.4.5Austin Morgan  2Y
1b06c | * Add --file option  Austin Morgan  2Y
b4ae8 | * Fix git subrepo status command for subrepos $  Catalin Cioco  3Y
be9f0 | * Don't allow -b and --all   Austin Morgan  3Y
df975 | * Fix documentation linksAustin Morgan  3Y
4d3db | * fix tests to support use of a default branch$  Michael Tedde  3Y
87ee3 | * pass --force to git add so a user's global .$  Michael Tedde  3Y
94ac5 | * Fix .rc and enable-completion.sh for zsh bef$  Ingy döt Net   3Y
2f685 | * Better format for options  Ingy döt Net   3Y
  |/  
b562f * 0.4.3 Release 0.4.3  Ingy döt Net   3Y


Drilling in: 

c9552 * | git-debrebase convert-from-gbp: drop patches$  Samo Pogačnik  2w

I thought we agreed on using plain gbp for now?


73a01 | | * upstream origin/upstream docs: Replace 404$  Edwin Kofler   5M
  | |/
110b9 | * 0.4.6 Release 0.4.6Austin Morgan  1Y

The upstream branch is ahead of the 0.4.6 tag. Why? Seems to me you meddled
with the upstream branch by hand instead of letting the tooling take care
of it. Technicaly not a problem just makes me wonder what you're doing.


ac9b0 * d/*: Fixed bash-completion integration with gi$  Samo Pogačnik  2d

Don't use d/*. If many files are involved just leave off the context. I
hope I haven't given you the impression you *have* to put some context
there, that's not the case.

The convention is to mention the file/package when the added context helps
the rest of the commit subject read better of be shorter. It is a pretty
soft convention however I'm not very consistent with it myself ;)

My main use case for files is stuff like "d/changelog: Fix typo" or
"d/copyright: Update for new upstream". As source packages get bigger which
binary package you're talking about starts to be important, say
"some-binpkg: Remove dep on flubnub".

Technically all of these could be reworded as something like "DoThing in
$context for this and that reason", but see what's actually happening is
split in two that way. It just reads better to get the $context first and
then the $whats_happening.

Something to keep in mind here too: if you do use the prefix convention it
is prudent to edit the gbp autogenerated d/changelog entries as end-users
don't (and shouldn't) really know what any of this Debian stuff is.

Until you're a DM/DD there's always someone in the middle editing the
changelogs but you should get into the habbit of keeping in mind who
uses/reads the stuff you produce. Some DDs may feel this extra editing step
is too annoyi

Bug#979188: Maintaining git-subrepo in Debian?

On Wed, Apr 24, 2024 at 10:06:49PM +0200, Samo Pogačnik wrote:
> Ok, so i'll prepare merge request in salsa gitlab, after pushing my
> change in my working branch?

So creating a MR is fine but it's not the whole story with gbp. With gbp
you're always dealing with both a debian and an upstream branch so the MR
model doesn't fit since it just deals with the one branch you point it
at. That doesn't really hurt as long as you remember to push your upstream
branch also since I won't be pressing that merge button on the web ui
anyway.

Technically I can still just assume your upstream branch points to the
upstream/* tag you push -- assuming you don't forget to push the upstream
tag. Seriously this workflow has so many trap doors for DMs it's insane :)

Anyway. What I want to see is a nice linear series of sensible commits with
your packaging changes and one merge to bring in the new upstream [history]
on the debian branch, the conventional upstream/* tag and the corresponding
upstream branch which should be fast-forward from the previous upstream
history.

[history]: That's the one default gbp workflow tweak I insist on when it's
possible i.e. when the need for dealing with tarballs doesn't get in the
way. I want git-blame to work in packaging repos. It's increadibly valuable
for debugging but squashing the upstream changes as import-orig defaults to
looses most of that context.

So you should be doing something like this:

$ git remote add upstream https://github.com/ingydotnet/git-subrepo.git
$ git fetch upstream
$ gbp import-ref -u 0.4.6 # this will do the upstream tag/branch
  # changes and create the merge
$ gbp dch

$ gbp buildpackage [...sbuild runes...]

$ git push --tags salsa debian/sid upstream

There's also `gbp push` to make the git-push easier but it only works after
doing a `gbp tag` to create the debian/* tag. This is however inappropriate
for you as DM to do as the convention is to have the debian tag correspond
to what I upload not what you propose to me :)

On my side I'll do:

$ gbp pull samo

$ gbp buildpackage [...sbuild runes...]

$ gbp tag# creates the debian/* tag
$ debrelease   # upload to ftp-master
$ gbp push salsa

Hope that gives you something more actionable than my previous mails.

> > Have you found any docs for this workflow?
> Not really, it was just an idea while reading about gbp and git-debrebase.

Right, that's what I figured but I wasn't sure :)

> > I've thought about it some more and perhaps we should for now use something
> > simpler (plain gbp) until you get the hang of it and/or the (unapplied)
> > patches actually get in the way.
>
> I agree, i just found my fork of your git-subrepo a nice small playground. As 
> an
> exercise i've converted it into a git-debrebase tree (via: man 7 
> git-debrebase:
> 'converting an existing package').

Playing with this stuff sure is important to figure out whats going on ;)

--Daniel

PS: I noticed too late that I'd forgotten to start adding BTS to CC. I do
like to keep Debian work public and that includes teaching new
contributors, do you mind if I copy our conversation back to the BTS?

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Mon, Apr 15, 2024 at 09:13:03PM +0200, Samo Pogačnik wrote:
> Thanks for the review. I followed your suggestions above and recommited
> d/control and
> d/changelog.
> 
> > As for the Vcs change: I'd prefer if we put the git repo in the debian/*
> > namespace on Salsa.
> > 
> 
> Here i am not sure who can / how to do this?

I'll push the repo there and give you access, you just have to adjust the
Vcs-* fields and get those changes to me in a way that I actually want to
accept them ;P

FYI: I'm not being obtuse, I could ofc. just make the adjustment myself but
I'm still trying to hone your git collab maintanance skillz :)

> I feel i owe you more explanation of what i am trying to achieve here
> (now renamed to https://salsa.debian.org/spog/git-subrepo-rebase). The
> idea was to reverse the gbp's view on its branches, where the debian/sid
> is the continuous branch and the patch-queue branches are the
> intermediate and temporary ones.

I have to admit I've never really considered this to be a possible
workflow. Honestly I don't think it's a good idea to hold a loaded gun
(gbp) the wrong way round ;)

Have you found any docs for this workflow?

> In this experiment i am trying to have the patch-queue branch the main
> continuous branch, brought (by any git means) to the state, where one
> could do 'gbp pq export' to a fresh debian/sid branch rooted before any
> upstream commits grouped at the end of the patch-queue branch.

git-subrepo is a relatively simple upstream so I would really not deviate
from established and documented workflows for it. I get you probably want
to explore the possible git workflows in Debian and admittedly my idea to
use git-debrebase is probably also severe overkill (and I'm also guilty of
just wanting to play with it too ;).

I've thought about it some more and perhaps we should for now use something
simpler (plain gbp) until you get the hang of it and/or the (unapplied)
patches actually get in the way.

> So, when a new upstream version is to be integrated (after pulling the
> upstream repo):

tl;dr honestly.

Look, we already have too many possible workflows for git maint. in Debian
adding a new one that doesn't have wide usage yet isn't going to help
unless it brings something new to the table. So how does this compare to
the other 50 workflows? :^)

> I feel/hope debrebase is doing something similar as my little experiment but
> with all the debian specific bells and whistles, i am currently not even aware
> of. I would say that, if dgit/debrebase provides a workflow without messing
> with patch-sets (and tarballs), then this is the tool...

There's no escaping tarballs in Debian :3

Except maybe with dgit but even then you need to think about calling
origtargz...

*chanting* In the tarball, part of the tarball, in the tarball, part of the
 tarball ...[ad nauseam]

https://youtu.be/SxGjdx1NXfg?feature=shared=49 and also:
https://www.youtube.com/watch?v=EM9kl6jY09A

--Daniel

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Mon, Apr 08, 2024 at 09:01:24PM +0200, Samo Pogačnik wrote:
> > Anyway gbp has reasonably good documentation, maybe you haven't seen it yet:
> > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html
> > (note the navigation buttons in the top right)
>
> Thanks for the 'navigation buttons' tip. Anyway, i reworked the git-subrapo
> according to gbp manual and now i am not sure if generated changelog is ok.

You can just edit the changelog `gbp dch` generates. I do find it fucks up
most of the time the way I use it and just edit it. I am starting to think
gbp is more trouble that it's worth now that I'm starting to look at some
of the other workflows...

+git-subrepo (0.4.6-1) unstable; urgency=medium
+
+  [ Daniel Gröber ]
+  * Fix Vcs URLs, s/guest-dxld/dxld-guest/
+  * Update changelog for 0.4.3-2 release

Commits that only touch d/changelog shouldn't be included. Odd gbp-dch does
usually filter those out.

+  * Add salsa-ci config
+  * Revert "Update changelog for 0.4.3-2 release"

I would collapse such VCS artifacts too since the changelog is from the
perspective of "what changed since the last version" in the end, not a blow
by blow of the git changes we used to get there. It's a judgement call tho.

+
+  [ Samo Pogačnik ]
+  * Updated debian/control info

Needs to be a lot more specifict than that. In d/changelog you're talking
to two main groups of readers: other Debian contibutors (i.e. me) and
actual end users. Does this tell me what I need to know to figure out why
you made that change? Not really.

Looking at the diff it should have even been two commits "d/control: Point
Vcs at samo" and "d/control: Make myself Maintainer".

As for the Vcs change: I'd prefer if we put the git repo in the debian/*
namespace on Salsa.

+
+ -- Samo Pogačnik   Sun, 07 Apr 2024 19:31:14 +

> I also made another git-subrepo_rebase project (
> https://salsa.debian.org/spog/git-subrepo_rebase) just to play around with
> rebasing of debian branch onto each renewed upstream. I assume rebasing 
> workflow
> shoud somehow avoid commiting patch series into main-working branch. I
> understood git-debrebase figured that out, but ... (see below)

I have a hard time figuring out what is going on in your repos. Damn I
already hate gbp from a review standpoint.

I'm not sure you've internalized this, with gbp you really don't want to do
any manual git-pull/git-merge calls. Let it do it throught it's
gbp-import-*/gbp-pull wrappers or you're going to confuse the hell out of
me when I try to review the package.

> > I wish we could use a rebase workflow with gbp but I haven't found a way to
> > do it yet. At least not with gbp import-ref as-is. We could work on a patch
> > for it I suppose ;)
> > 
> I think i am a bit too green for that

Maybe, maybe not. Only one way to find out.

> I watched video about git-debrebase and it seemed reasonable to me at first,
> however they lost me when dgit and pushing to dgit repo got into play.

The history structure does get a bit confusing yeah. My main takeway:
"patches applied" workflows exist *mind blown*. I hadn't seen that yet,
exactly what I've been looking for since gbp-pq sucks and quilt is no
better. I just want to use striaght up git damn it and that's what
debrebase and dgit seems to let you do :)

I'm actually tending to just jumping onto dgit. Should actually make things
easier for you once I figure out how it works. There's even nice docs for
the sponsorship workflow
https://manpages.debian.org/testing/dgit/dgit-sponsorship.7.en.html unlike
with gbp where upload sponsorship seems to just not have been considered in
it's design if my DM experience with it is any indication :D

Opinions?

--Daniel

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Sun, Mar 31, 2024 at 01:42:48PM +0200, Samo Pogačnik wrote:
> I prepared a new git-subrepo in salsa as a fork of your project (
> https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and 
> prepared
debby> a new 'debian/sid' branch. Would you be so kind to take a look at it and 
comment
> on what should be changed/fixed and how to proceed.

You removed the (Closes Bug#) ITP reference from d/changelog. It's policy
to close that but with the first upload, so you have to keep it.

Workflow wise I don't see why you needed to make a merge commit at
d0cc659. Can you explan what you were doing?

On Wed, Mar 27, 2024 at 07:27:31PM +0100, Samo Pogačnik wrote:
> Thank you for the valuable information. Currently i managed to reactivate my
> Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was
> also able to setup debian-sid chrooted environment on my old Ubuntu laptop up 
> to
> the point that i think i can successfully rebuild your current 'git-subrepo'
> project using the following commands after entering 'debian-sid' (schroot -c
> debian-sid):

> $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git

I don't use pristine-tar unless absolutely required (due to DFSG repacking
or some such), gbp defaults to using git-archive to generate tarballs so
just leave off the pristine-tar options.

Packaging repos usually declare whether they use pristine-tar in d/gbp.conf
so there should rarely be a need to fiddle with the options here.

> $ cd git-subrepo
> $ gbp buildpackage  --git-pristine-tar-commit

Don't use --git-pristine-tar-commit. Proper proceedure is to do that
explicitily using gbp import-org (if using that).

There's another option for importing upstream sources which I prefer (but
that is a bit of a PITA): `gbp import-ref` it is a pure git workflow
leaving the tarball hassle to gbp and that preserves upstream git history
and git-blame'ability.

Admittedly it's not very widely used in Debian ATM (which may change thanks
to the current xz kerfluffle) so docs may be lacking. Let me know if you
can't figure it out.

> I hope this is the correct procedure - i wasn't very confident seing 'sbuild'
> requireing another 'chroot' from within my original 'chroot', however it seems
> to be working now?

Seems ok, but building in "clean" chroots (using sbuild) is strongly
preferred for real testing.

sbuild calls schroot internally. You run it from your system like
normal. You just have to configure a tell it which base chroot to use and
that chroot needs special handling to be as close to the buildd ones as
feasible. Relevant chroot bootstrapping tools often have an
"sbuild"/"buildd" mode.

I tend to use sbuild-createchroot(8) from ubuntu-dev-tools for chroot
building, but debspawn is probably orders of magnitudes easier as far as
setup and maintainance of the environments is concerned.

> My plan now is to fork your git-subrepo project, fetch latest upstream changes
> and rebuild the latest version. Would that be ok to get to the point, when a 
> new
> ITP could have been issued?

You don't need a new ITP, it's still open and valid. If you want to be
proper you can change the "owner" field to yourself. Send an email to
cont...@bugs.debian.org, see
https://www.debian.org/Bugs/server-control. Good practice for interacting
with the BTS anyway.

> > https://github.com/lkhq/debspawn looks really neat and tidy but may be
> > untrodden ground. Could be workable if you feel up to trying it. I would
> > also be curios to know if it works well. See
> > https://github.com/lkhq/debspawn/issues/27 for some discussion between
> > ximion (the author) and josh (sbuild maintainer) how it compares against
> > sbuild.
> > 
> I might try debspawn on another 'non-debian' 'nixos-based' machine, but this 
> may
> not happen very quickly. As i understood, it only requires a systemd-based
> Linux.

I wouldn't trust it working outside of Debian. It's a Debian tool for and
by Debian people.

> > Aah, it's nice and warm in the jungle but simetimes you get lost between
> > all the vines~
>
> I get lost a lot. Three years ago even so that i created new docker-pbuilder-
> based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my
> head around debian ways. You can imagine that the project wasn't accepted very
> well on debian-devel:).

c.f. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence

While sometimes we may need to build to understand others need to see you
understand before they let you build on their land ;-)

--Daniel

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

wouldn't you know it I've become a DD before I got a response to the
git-subrepo ITP/RFS ;) I also completely forgot about it until I needed it
just now.

Are you still interested in maintaining git-subrepo in Debian?

I'm trying to limit my personal packaging work to stuff I actually use on a
regular basis and apparently subrepo is not that essential, but as a DD I
can now sponsor any uploads and help you with figuring out the Debian
workflow and such though.

My packaging from way back when is at
https://salsa.debian.org/dxld/git-subrepo if you feel like it. Probably
needs a once over to check for updates necessary changes tho.

Thanks,
--Daniel

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Mon, Apr 01, 2024 at 07:54:09PM +0200, Samo Pogačnik wrote:
> > Workflow wise I don't see why you needed to make a merge commit at
> > d0cc659. Can you explan what you were doing?
>
> Well, after i updated the upstream branch, i wanted to preserve your
> original debian/sid branch, so i renamed it and merged it into the new
> debian/sid branch, based at the latest 0.4.6 release tag of the upstream
> branch.
> 
> Actually, this is the point, where i need to learn, how debian/sid branch
> is to be managed in a 'debianized' git repo through upstream updates?

Right, that's not how to do things in a git-buildpackage repo. See the
problem gbp is solving is that Debian source packages (.dsc) are composed
of two parts (tarballs) the upstream part (.orig.tar.*) and the debian part
(debian.tar.*). To represent this in git gbp has the concept of an upstream
branch and a debian branch.

When updating your gbp packaging repo to a new upstream version you have to
update the upstream branch pointer and merge that into the debian branch
separately. import-orig and import-ref will do this for you as it's a
hassle.

Honestly I really hate this part of gbp's design. Having two branches is
just such a hassle to manage and makes all the operations gbp performs
non-atomic and it has to support rollback of whatever it has already tried
to do in case anything (say a git-merge) fails down the line ... it's a
mess.

There are other git workflows in use in Debian, eg. dgit, but they're even
harder to get your head around, or at least I haven't managed to, so gbp it
is for now :/

Anyway gbp has reasonably good documentation, maybe you haven't seen it yet:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html
(note the navigation buttons in the top right)

> > I don't use pristine-tar unless absolutely required (due to DFSG repacking
> > or some such), gbp defaults to using git-archive to generate tarballs so
> > just leave off the pristine-tar options.
> > 
> > Packaging repos usually declare whether they use pristine-tar in d/gbp.conf
> > so there should rarely be a need to fiddle with the options here.
> > 
> I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to
> 'False' i can simply run 'gbp buildpackage'. Would you recommend setting
> 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo?

Oh I didn't even know gbp has a user config file. That seems
ill-concieved. Gah.

Yeah I would strongly reccomend not messing with the pristine-tar option in
the user-config. We could explicitly set it =False in d/gbp.conf but I'd
rather not as I don't think that's commonly done at all though I can find a
number of occurrences in my Debian packaging workdir.

> > There's another option for importing upstream sources which I prefer (but
> > that is a bit of a PITA): `gbp import-ref` it is a pure git workflow
> > leaving the tarball hassle to gbp and that preserves upstream git history
> > and git-blame'ability.
> > 
> > Admittedly it's not very widely used in Debian ATM (which may change thanks
> > to the current xz kerfluffle) so docs may be lacking. Let me know if you
> > can't figure it out.
> > 
> something new for me to digest:) Actually i preserved upstream history in
> my manual git-subrepo upstream branch update and lost your history in new
> debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer
> upstream could solve that as well...

I wish we could use a rebase workflow with gbp but I haven't found a way to
do it yet. At least not with gbp import-ref as-is. We could work on a patch
for it I suppose ;)

I just want to avoid using a custom script to import upstream sources if at
all possible. Debian already has too much fude factor in packaging.

> > sbuild calls schroot internally. You run it from your system like
> > normal. You just have to configure a tell it which base chroot to use and
> > that chroot needs special handling to be as close to the buildd ones as
> > feasible. Relevant chroot bootstrapping tools often have an
> > "sbuild"/"buildd" mode.
> > 
> > I tend to use sbuild-createchroot(8) from ubuntu-dev-tools
> > for chroot
> > building, but debspawn is probably orders of magnitudes easier as far as
> > setup and maintainance of the environments is concerned.
>
> Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild)
> to create chroot used by sbuild, however sbuild is not run from my old
> ubuntu host directly, but from 'schroot -c debian-sid' prepared
> previously (see:
> https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild)

I don't see why that would be necessary though? Ubuntu also uses sbuild,
the version in their archive should work just fine for our purposes as long
as you make it use a Debian chroot.

--Daniel

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Fri, Mar 15, 2024 at 06:42:54PM +0100, Samo Pogačnik wrote:
> Dne 11.03.2024 (pon) ob 20:18 +0100 je Daniel Gröber napisal(a):
> > Are you still interested in maintaining git-subrepo in Debian?
>
> please excuse me for my late response, but my situation from 2020/21 when
> we proposed the git-subrepo ITP changed in a way that i am spending most
> of my free time off-line. With this on mind i am not sure, if i am
> responsive enough for a maintainers job (i might be off-line for a few
> weeks from time to time).

Given that git-subrepo doesn't have much upstream activity these days I
don't find that very concerning at all. In fact Debian development is
pretty well suited to an offline workflow -- if only because the tools we
use were designed so long ago that having no internet was still common ;)

Only thing I would recommend you get yourself is a setup where you can
send/read your email offline and without Debian stuff getting lost.

As long as you surface regularly and especially some time before it's
release'o'clock it doesn't matter much. Worst case I'm expected to deal
with any packages under my sponsorship umbrella so the responsibility
doesn't rest enrirely on you anyway.

Now you may wonder "why don't I just do it then" and I just find having
someone else on board that cares (more intensly) about a package helps make
the drudgery of maintanance more fun ;)

> However, i am tempted to push this through and give git-subrepo more
> audience.  Unfortunately i am more experienced in embedded Linux (yocto /
> openembedded / bitbake) than in debian packaging and my desktop is more
> or less Ubuntu.

Not a big deal either. The packaging should mostly be done IIRC and since
subrepo is just a simple shell script it's about the simplest thing to
package I can imagine, no need to worry there.

The main job(s) of a maintainer are responding to bugs, fixing or
forwarding them, communicating with upstream and reviewing new versions,
perhaps writing new docs if you can see users struggling. All of which are
more about humans than about computer obscurities.

As for the Ubuntu bit. There are tons of ways to get a Debian development
environment on your system, I don't know what the easiest one is for you
since that depends on what you're familiar with. Docker is certainly
possible and AFAIK the dockerhub images are maintained by DDs.

You just have to keep in mind to build/test with Debian unstable since
that's where the actual development happens. Depending on whether you want
git-subrepo to also be available for the current release (bookworm) we
could also publish to the backports repo but that does double the amount of
package building/testing work we have to do.

> If you think that may shortcomings

I don't think about people that way, what you call shortcomings I call
*untapped potential* ;)

> I would very much appreciate any guidance regarding debian packaging
> procedures and needed packaging/testing environment.

A good place to start is https://wiki.debian.org/Packaging

If you prefer a talk format there's Lucas' (excellent) tutorial
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
I can't find a recording of it but the slides are pretty extensive.

In video format there is
https://debconf22.debconf.org/talks/79-introduction-to-setting-up-the-debian-packaging-development-environment/
but I can't vouch for that one.

We can also do a call to figure out where you're at and what info you need
because the huge scope of the general packaging related documentation can
be a bit overwhelming and confusing, even if what you need to know is like
5% of that.

> And of course congratulations on becoming a DD!

Yey, now the real work begins ;)

--Daniel

Bug#979188: Maintaining git-subrepo in Debian?

Hi Samo,

On Tue, Mar 19, 2024 at 10:00:44PM +0100, Samo Pogačnik wrote:
> > We can also do a call to figure out where you're at and what info you need
> > because the huge scope of the general packaging related documentation can
> > be a bit overwhelming and confusing, even if what you need to know is like
> > 5% of that.
> 
> Thanks for all your input, i'll try to setup the debian/build environment 
> first
> and go through the provided links. Which debian-specific tools do you find
> essential in your workflow, so that i can focus on them while reading the 
> docs?

For building I use debuild or git-buildpackage+sbuild depending on context.

I create chroots for sbuild with a wrapper script around
sbuild-createchroot using btrfs-snapshots for efficiency.

To keep working on a package without having to reinstall the entire
dependency tree (as sbuild does) every time I tweak sbuild's
--anything-failed-commands or use schroot directly with a different chroot
profile setup which has my homedir mounted.

I'm not sure all of that is the easiest setup these days. It certainly
needs "gardening" to keep it updated and in-sync between both my laptop and
workstation and I have been looking into alternatives.

https://github.com/lkhq/debspawn looks really neat and tidy but may be
untrodden ground. Could be workable if you feel up to trying it. I would
also be curios to know if it works well. See
https://github.com/lkhq/debspawn/issues/27 for some discussion between
ximion (the author) and josh (sbuild maintainer) how it compares against
sbuild.

When trying to understand how the build tools work and fit together keep in
mind that debuild (the traditional default) is nothing but a wrapper around
dpkg-buildpackage (which has a more extensive manpage) and passess most
options down as-is. git-buildpackage (by default) wraps debuild (or
optionally sbuild if you tell it to). sbuild allows building in chroots and
has a number of fancy options to make that easy.

Aah, it's nice and warm in the jungle but simetimes you get lost between
all the vines~
--Daniel

signature.asc
Description: PGP signature

Bug#979188: Maintaining git-subrepo in Debian?

On Mon, Apr 01, 2024 at 11:07:50PM +0200, Daniel Gröber wrote:
> I wish we could use a rebase workflow with gbp but I haven't found a way to
> do it yet. At least not with gbp import-ref as-is. We could work on a patch
> for it I suppose ;)

Looking at git-debrebase (https://www.youtube.com/watch?v=iov10lD7tcg)
now. Looks promising, hmm.

--Daniel


signature.asc
Description: PGP signature

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

2024-05-02 Thread Daniel Reichelt


On 02.05.24 17:30, Roland Clobus wrote:

I'll prepare a proper fix that detects whether the directory is present.


Perfect, thanks!

Bug#1068953: new upstream (10.0)

2024-05-02 Thread Daniel Baumann


On 5/2/24 10:30, David Lamparter wrote:

I've managed to get sbuild crosscompile to work for hppa and found the
problem (it's a missing "XREF_SETUP()" line, not that the error message
would give any hint to that...)


yay!


I'll put a -2 together later today.


nice, feel free to ping me when done to sponsor it.

Regards,
Daniel

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

2024-05-02 Thread Daniel Reichelt

Hi Roland,
> On 20/04/2024 13:32, Daniel Reichelt wrote:
> What are you doing that makes the directory 'config/includes.binary'
> disappear?
> If I use 'lb config --distribution sid', the directory is created (but
> empty) and there will be no error message.

I'm keeping my (final, i.e. `lb config`ured) config-trees in git which 
has been

working for over a decade so far.

> the directory is created (but empty) and there will be no error
> message.

It is not a good practise to depend on the existence of empty
directories, IMHO.

Your commit message says nothing abaout the patch in
scripts/build/binary_includes. Why did you move those lines in the first
place?

Prior to the move, `if Find_files config/includes.binary/` acted as a
check for existence of said directory. With your patch, that's no longer
the case which is the actual problem here.

Best,
Daniel

Bug#1068161: Video playback regression

2024-05-01 Thread Daniel Richard G.

Hi Andres,

On Tue, 2024 Apr 30 02:42-04:00, Andres Salomon wrote:
> Please let me know if this is still broken with chromium 124.

I'm happy to report that the issue appears to be resolved in the current
124.0.6367.78-1~deb12u1. (I did not test 124.0.6367.60.)

Some additional info that I meant to send in earlier:

* I was able to work around the problem in 123 with "--use-gl=egl".
  Even now, with 124, I get "MESA: error: Out of instructions"
  messages on the terminal when this flag is removed (but video now
  works either way).

* The video adapter is listed as a "VGA compatible controller [0300]:
  Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
  Graphics Controller [8086:27a2]", on a Lenovo ThinkPad.

* This is a different and much older bug, but I've observed that some
  Web sites show visual artifacts in chromium on this particular system,
  and --use-gl=egl also cleared those up. I think the issue may be that
  the driver for this specific hardware is buggy, and affected users are
  better off using the alternate GL implementation. (I can provide more
  details if this is of interest.)

Bug#1068953: new upstream (10.0)

2024-04-30 Thread Daniel Baumann


On 4/30/24 12:56, David Lamparter wrote:

Ok, for the time being I've instead decided to use this as a kick in my
ass to finally do the NM procedure to become a Debian Maintainer...
https://nm.debian.org/process/1284/


hehe, nice ;)


I have no idea what kind of timescale that works on, but I probably
can't get to hppa debugging right off anyway


can take from anywhere between a few days and a couple of months, 
depending on the availability of $people and you providing/fulfilling 
the requirements.



worst case I'd ping you later?


anytime, sure.

Regards,
Daniel

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

2024-04-30 Thread Daniel Baumann


Hi David,

On 4/30/24 18:21, David Lamparter wrote:

flipped libatomic to be linked unconditionally.


it's not harmful to do so on architectures that don't need it, but imho 
its cleaner to only be linked on affected architectures (armel m68k 
powerpc sh4).



https://github.com/FRRouting/frr/commits/debian/master/


nice, thanks!


Do you want to do anything else with it or should I go mark it as -1?


my last attempt from yesterday didn't work (after a long time it took to 
build on the armel porterbox), so -1 looks good like that.


Regards,
Daniel

Bug#1068951: new upstream (6.x)

2024-04-30 Thread Daniel Baumann


Hi,

On 4/30/24 18:12, Jakub Ružička wrote:
Secondary reason for that was that there is no upgrade path from 5.x to 
6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6.


For that, the package probably needs a different name (like 
knot-resolver6)


imho this should be handled in the package (e.g. by showing a debconf 
note or so) and be included in the trixie release notes. renaming the 
binary package doesn't really solve much and is more suited for 
(library) transitions, i.e. if there were several knot-resolver-module-* 
packages or so.


also (I haven't looked at it), is it worthwile to (with users consent) 
to "try" to guess with (some parts of) the old config to generate the 
new config from?



So what do you suggest?


generally, the amount of binary packages should be limited to a minimum 
- oiow there needs to be a reason why an additional binary package is 
added. some of them are:


  * saving relative excessive amount of diskspace (e.g. large
documentation can be split into a -doc package)

  * different parts have different dependencies and/or particulary
long dependency chains (e.g. gtk parts of a cli tool)

therefore, imho the following binary packages make sense here:

  * knot-resolver
  * knot-resolver-doc
  * knot-resolver-module-dnstap
  * knot-resolver-module-http

Note that -dbg packages are generated automatically and don't need to be 
specified in control (I'll provide a commit for that).


Regards,
Daniel

Bug#1070084: libkpimgapi-data: KAddressBook, and possibly related programs, fail to integrate with Google

2024-04-29 Thread Daniel Melameth

On Mon, Apr 29, 2024 at 4:56 PM Patrick Franz  wrote:
> Hi Daniel,
>
> this is a known problem as Google deprecated the Contacts API and
> replaced it with the People API. The KDE PIM in unstable, testing and
> stable is too old to support the People API which was added for 23.04.
>
> The only option to fix this is to update the entire KDE PIM stack
> (roughly 50 packages) to 23.04 or later. However, this is sadly not
> possible right now. I cannot give you a timeline when this is going to
> happen.
>
>
> --
> Med vänliga hälsningar
>
> Patrick Franz

Thanks for the prompt reply Patrick.  I realize this bug has been in
place for quite a while, but I wasn't sure if an official bug report
was needed to help get it resolved more timely as, yes, all releases
are affected.

Bug#1070084: libkpimgapi-data: KAddressBook, and possibly related programs, fail to integrate with Google

2024-04-29 Thread Daniel

Package: libkpimgapi-data
Version: 22.12.3-1
Severity: important
X-Debbugs-Cc: dan...@melameth.com

Dear Maintainer,

   * What led up to the situation?

I'm new to Linux, and, with the popularity of Gmail and related, I attempted to 
configure KAddressBook to access my Gmail Contacts, but it did not work.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I attempted to Add a New Address Book using Google Groupware, but it does not 
work.

   * What was the outcome of this action?

I was unable to use the program as intended.

   * What outcome did you expect instead?

I expected the program to integrate with my Gmail Contacts, much like 
KOrganizer integrates with my Gmail Calendar.

This bug appears to be resolved in newer versions of the program; some details 
may be found at https://bugs.kde.org/show_bug.cgi?id=446580 and 
https://bugs.kde.org/show_bug.cgi?id=439285.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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

-- no debconf information

Bug#1068951: new upstream (6.x)


On 4/29/24 19:50, Daniel Baumann wrote:
pushing to the repo requires me to be added to the salsa project.. would 
you mind adding me?


in the meantime, I've pushed to here:
https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/

before I'll continue: what's the idea of adding knot-resolver-manager 
binary package?


I can't think of a reason why one would use kresd (knot-resolver-core) 
without the manager, and thus, would fold knot-resolver-manager and 
knot-resolver-core (back) into knot-resolver. But probably I'm missing 
something..


Regards,
Daniel

Bug#1068951: new upstream (6.x)


On 4/23/24 14:45, Jakub Ružička wrote:
Awesome, I've forwarded your words of praise to the hard-working Knot 
Resolver team :)


(jftr: we switched in 2015 from cisco ncr to unbound, and in 2016 from 
unbound to knot-resolver.. and are super happy ever since)



I'm actually quite interested in (the nightmares of) python packaging


hehe :)

Cool, I've already mental-marked you as a person I'm gonna bother with 
reviewing my v6 changes even before your willing reply :)


no problem, looking forward to it :)

IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian 
should be as close as possible.


+1

Feel free to push your changes (if any) to debian/experimental or use 
your branch as you prefer, I'm always eager to learn how other DDs do 
things.


pushing to the repo requires me to be added to the salsa project.. would 
you mind adding me?


Regards,
Daniel

Bug#1066875: devscripts: debsign tries to parse gpg version from human-readable output, should use machine-readable output

2024-04-29 Thread Daniel Kahn Gillmor

Hi Guillem--

On Sat 2024-04-27 23:13:13 +0200, Guillem Jover wrote:
> I was just modifying this code for another report I'm about to file,
> and instead wondered why have it at all! I'm proposing simply removing
> the backwards compat code given that even in oldstable gnugp1 is
> already at verison 1.4.23. See attached patch.

yes, that seems like an even better choice.  the 1.4.x line of GnuPG is
poorly supported these days, and doesn't handle modern cryptography
(including the 25519 keys that are used by a lot of DDs these days).

Thanks for looking into this, Guillem!

   --dkg

signature.asc
Description: PGP signature

Bug#1068953: new upstream (10.0)


On 4/29/24 18:31, David Lamparter wrote:

Did you run into issues that forced you up to 2.1.148?  The "officially
listed" (= in configure.ac) requirement is 2.1.128, if we(upstream)
missed something I'd look into getting that listed minimum bumped up
too.


Rechecking the frr 10 announcement.. says indeed 2.1.128 not 2.1.148. 
totally my fault, I'm very sorry about that!


(I'm running frr 10 with 2.1.148 here since some days now with no issues 
though)



Is there some way to debug this?


You can ask for (hppa) porterbox access; accounts to porterboxes are 
given to non-DD/DMs too:


  https://dsa.debian.org/doc/guest-account/

If you send me the data requested there, I'll sign it so you can get access.

Regards,
Daniel

Bug#1068953: new upstream (10.0)


Hi David,

On 4/29/24 16:56, David Lamparter wrote:

I can't do uploads myself (not a DM/DD)


no problem - I'm happy to sponsor your uploads if you want me to ;)


FRR definitely requires libyang 2.1.128.


hm, frr 10 needs libyang2 2.1.148.

which, as you noted, is already uploaded so for now - situation is fine.


I really need to merge master back
into the debian branches on the FRR repo to pick that up, I can probably
get to that today or tomorrow.


that would be nice; and again, happy to help/to sponsor any uploads.


There's also a bit of a problem in #1067077


I've fixed that already, just waiting some more minutes on the build to 
finish on the armel porterbox.


Regards,
Daniel

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'


tag 1067077 +pending
thanks

Hi,

my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've 
fixed that locally but a build to confirming on an armel porterbox is 
runnning before uploading 10.0-0.3 in some minutes..


Regards,
Daniel

Bug#1070063: Remmina fails to connect with Windows systems: Protocol Security Negotiation Failure (older release works)

2024-04-29 Thread Daniel Leidert

Package: remmina
Version: 1.4.35+dfsg-1+b1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

when I try to connect to a windows (11) system, I get errors saying something
like "check security protocol negotiation". When I set it the security protocol
negotiation to automatic detection, there is a connection attempt, but the
credentials are not accepted. As I haven't changed anything in the RDP setup, I
tried downgrading to version 1.4.34, and everything works now as expected
again. I'm not quite sure if this issue is related to
https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2062177 and/or
https://gitlab.com/Remmina/Remmina/-/issues/3090, or if this is a complete
different issue.

Regards, Daniel


- -- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_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 remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  libavahi-client3  0.8-13+b2
ii  libavahi-common3  0.8-13+b2
ii  libavahi-ui-gtk3-00.8-13+b2
ii  libayatana-appindicator3-10.5.93-1+b1
ii  libc6 2.37-19
ii  libcairo2 1.18.0-3+b1
ii  libcurl4t64 [libcurl4]8.7.1-4
ii  libgcrypt20   1.10.3-2+b1
ii  libglib2.0-0t64 [libglib2.0-0]2.78.4-7
ii  libgtk-3-0t64 [libgtk-3-0]3.24.41-4
ii  libjson-glib-1.0-01.8.0-2+b1
ii  libpango-1.0-01.52.1+ds-1
ii  libsodium23   1.0.18-1+b1
ii  libssh-4  0.10.6-2+b1
ii  libssl3t64 [libssl3]  3.2.1-3
ii  libvte-2.91-0 0.75.92-1
ii  remmina-common1.4.34+dfsg-1

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.4.34+dfsg-1
ii  remmina-plugin-secret  1.4.34+dfsg-1
ii  remmina-plugin-vnc 1.4.34+dfsg-1

Versions of packages remmina suggests:
ii  remmina-plugin-exec 1.4.34+dfsg-1
pn  remmina-plugin-kwallet  
pn  remmina-plugin-python   
ii  remmina-plugin-spice1.4.34+dfsg-1
ii  remmina-plugin-www  1.4.34+dfsg-1
pn  remmina-plugin-x2go 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmYvo20ACgkQS80FZ8KW
0F019w/+L5a7P2ISCuVfYN0TDIXNvW97noLHv0798jJ3cX2zX1DJ0CSyF5oLXLbt
ctVCobfZitMax1mUCpxgQYbEody6bZVRMdnb1SQEbiue+sx5iqsd+tYDmfwNThV9
FpLs203BuFg2CmjblhxpJ2AWlpCxQJUv39EVNtYFDnCHFW0hFbtdtIx48d6n7Byt
N4Ys0d5z9c+BeTpSMgT26DeVoxE0dIGaL2/tC1X4/mjlf23NMZyweKHS1YSo8/v7
Or6Z0tAFhdSF49320LNCqu6Y/jLwW9/gcJuzkRT6QBc6kBThOJvtSiLvREdlfytm
Ou421mvqU7nG3FKM0g987wgCZw/3ZmizsZESh4J1b2yrXc/Lr+T+XmEA8v3u5e+j
XMy7rJ7a5mWZt3iaikCxuq3RHQJM4eAhtfp1Obp5gyS06+65SB2vppWPHIjIcOfh
X6uqULCcSITwesyOWvd0w/iPmVrGaSjJCp6VrzWVXngKOdYWnyU+cV+yPVcP+GKE
T/iSDmssoeoFE1AjF8O+fSu/qP2E0VnsJ+cYpkU4LrcZ+RiLpNolTlws0Jgw1Q/n
4x3pDc01KH7aSdEqZU8DB4/CXgiPsvxEWqcTX3gTX33Q5LXXtOmZOsSnfD7X3OqG
9CQsUosvRuEQyaxFG4KGgiwnllJHcSvn1Moa1uaIGBqeJuxBgvI=
=2ZY6
-END PGP SIGNATURE-

Bug#1070030: RM: erfs -- ROM; no longer functional

2024-04-28 Thread Daniel Echeverri

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hello

The erfs service was shut down and this tool is no longer functional. It
should be removed.

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1065241: O: pylint -- Python 3 code static checker and UML diagram generator

2024-04-28 Thread Daniel Echeverri

retitle 1065241 RFA: pylint -- Python 3 code static checker and UML diagram
generator
noowner 1065241 !
thanks

Hello

I have seen that you recently uploaded the new version of pylint and added
yourself as an uploader. I had become the owner of this bug because I was
working on the package, and I was waiting to solve the tests that had been
failing, (I see that you solved it by removing the tests that are failing).
(I  am not sure if it's the best way) Anyway, you can be de maintainer,
just go ahead

Regards


-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1069995: VCSWatch: underlaying system doesn't support TLS1.3

2024-04-28 Thread Daniel Baumann


Package: qa.debian.org
Severity: wishlist

Hi,

I've switched off TLS1.2 on my git server (to see what would be 
brocken), one of them is VCSWatch:


Error: fatal: unable to access 
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/': 
gnutls_handshake() failed: Error in protocol version


It would be nice if the qa.debian.org system (I assume) could be updated 
to bullseye or newer which supports TLS1.3.


Regards,
Daniel

Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries

Package: elpa-debian-el
Version: 37.11
Severity: normal
X-Debbugs-Cc: none, d...@fifthhorseman.net, Daniel Kahn Gillmor 


When i do "M-x debian-bug P elpa-debian-el RET" i get the template you
see here.

Weirdly, X-Debbugs-Cc is pre-populated in this way.

There are at least two things wrong with X-Debbugs-Cc here:

 - the string "none" shouldn't be present.  This smells like a bug,
   where the empty string is somehow being misinterpreted as the string
   "none", but i odn't know where it's happening.


 - the two additional addresses are duplicative. Even if there is code
   that tries to re-add a duplicate address, it should notice that the
   e-mail address parts are identical, and coalesce them into a single
   address.

I don't understand the codebase well enough to be able to see how these
things are happening, but if you want me to test some changes, or report
on any other config, please let me know.

   --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.6.15-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 elpa-debian-el depends on:
ii  bzip2   1.0.8-5.1
ii  dh-elpa-helper  2.0.17
ii  emacsen-common  3.0.5
ii  reportbug   13.0.1
ii  xz-utils5.6.1+really5.4.5-1

Versions of packages elpa-debian-el recommends:
ii  emacs   1:29.2+1-2
ii  emacs-pgtk [emacs]  1:29.2+1-2
ii  wget1.21.4-1+b1

elpa-debian-el suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069905: debian-keyring: missing OpenPGP certificates for Debian archive processing software (ftpmas...@ftp-master.debian.org, ftpmas...@debian.org)

Package: debian-keyring
Version: 2024.03.24
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor , 
ftpmas...@ftp-master.debian.org, ftpmas...@debian.org

I receive e-mail messages from the debian FTP archive-processing
software are signed with F38AA24EB85F09F9923CA4949BF6A82061CCB921, and
labeled as From: ftpmas...@ftp-master.debian.org, but the associated
OpenPGP certificate is not found in /usr/share/keyrings/.

I expected to find it in /usr/share/keyrings/debian-role-keys.gpg, but
it wasn't there.

It also wasn't published on any of the common OpenPGP keyservers, that i
could find.  And it's not published via WKD or DANE in the places i'd
expect it to be for the mail addresses in the in the certificate's user
IDs (ftpmas...@ftp-master.debian.org and ftpmas...@debian.org).

It can be found (with no third-party certifications) in the "Upload
Processing Keys" section of https://ftp-master.debian.org/keys.html.

If these role keys are legitimate, then:

- they should be certified by at least a few Debian Developer's
  certificates, hopefully some folks from the FTP team who would know
  which certificate is the right one.

- they should probably be distributed in the debian-keyring package,
  perhaps as part of the debian-role-keys.gpg file.

I note that the User IDs in those keys contain a parenthesized comment
(2022).

User ID comments are generally a bad idea [0], and this is no exception.

[0] 
https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html

If you want to communicate a date range about when these keys should be
acceptable, the right way to do that is explicitly in the metadata
fields associated with the certificates (e.g. key creation time, key
expiration time).  Reasonable OpenPGP tooling should adequately report
and handle that metdata in a standardized way.

I recommend for OpenPGP certificates like this, to start off with a
2-year expiration window, and when there is 1 year left to go, if you
think the signing secret key is still valid and will be for longer,
renew the expiration to another year out.  Those moments of certificate
update are also good moments to publish the certs via hkps at
https://keyring.debian.org/ as well.

Regards,

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

debian-keyring depends on no packages.

Versions of packages debian-keyring recommends:
ii  gnupg  2.2.40-1.1

debian-keyring suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#979617: tcplay: VeraCrypt support

Hi László--

Thanks for sorting out the 3.3-1 upload for tcplay, multiarch-ifying
library along the way, and updating the packaging history in Salsa, too!

With much appreciation,

 --dkg


signature.asc
Description: PGP signature

Bug#1069889: gpg-sq-dbgsym: missing auto-load script

Package: gpg-sq-dbgsym
Version: 0.8.0-4
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I am trying to debug a performance issue with gpg-sq upstream
(https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/72) and
i attached gdb to a running gpg-sq process.

As soon as it was attached, gdb emits this warning:

warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of 
file /usr/bin/gpg-sq.

I'm not sure exactly what this means, or how it should be fixed, but
here it is in context:


```
0 dkg@alice:~$ gdb -p $(pidof gpg)
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 898919
[New LWP 898945]
[New LWP 898946]
[New LWP 898947]
[New LWP 898948]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fb3417e0872 in __gmpn_addmul_2 () from /lib/x86_64-linux-gnu/libgmp.so.10
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/bin/gpg-sq.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb)
```

As you investigate, feel free to reassign this report to gdb (if it's a
spurious warning), or to cargo (if it's a build issue), dh-cargo (if
it's a packaging issue), or anywhere else that makes sense.

Thanks for maintaining gpg-sq in debian!

--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.6.15-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 gpg-sq-dbgsym depends on:
ii  gpg-sq  0.8.0-4

gpg-sq-dbgsym recommends no packages.

gpg-sq-dbgsym suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1068174: Debian FPGA toolchain update and testing

2024-04-25 Thread Daniel Gröber

Hi Jonathan & Philipp,

On Sat, Apr 20, 2024 at 09:07:41PM +0200, J. Neuschäfer wrote:
> > @Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?
> 
> Count me in!

Excellent, thanks!

> If you find a good answer, let me know, and it's probably a good idea to
> write it down as a recommendation somewhere, so it doesn't get lost in time.
> 
> https://github.com/olofk/corescore might be an interesting option, but I
> haven't looked at it in depth.

That does look to depend on https://github.com/olofk/fusesoc which would
mean additional packaging work just to use it for testing. I'd really
prefer something stand-alone i.e. plain verilog or VHDL.

On Sun, Apr 21, 2024 at 03:00:56PM +0200, Philipp Klaus Krause wrote:
> > Neat, are the GateMates finally available on the open market then? I'd love
> > to get my hands on some dev hardware.
> 
> Yes, I got the GateMateA1-EVB board from Olimex, since it is
> substantially cheaper than the official CologneChips one, and I have no
> use for most of the extra features of the CologneChips board:
> https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB/open-source-hardware

Nice. I like the olimex pricing too :)

> I can do some testing on iCE40UP5 (iCEBreaker board) and GateMateA1
> (GateMateA1-EVB board). I run Debian on amd64, arm64, and ppc64 (but so
> far used yosys on amd64 only).

Double Nice. I only test on amd64. Maybe it's time to start looking at
whether yosys/nextpnr produce reproducible output across architectures? I'm
curious.

> My use-case is basically that: the experimental f8 CPU
> (https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/f8/f8/). I
> actually use "simple blinkies" for testing": a basic f8-based SoC, that
> runs a program on the CPU that does the blinking. However, I write
> System Verilog, so I use sv2v (not yet in Debian) as a preprocessor
> before feeding my code into yosys.

Neat. That does have the same problem as Jonathan's proposal: additional
packaging work just for testing. Unless you're volunteering for maintaining
sv2v? Happy to sponsor uploads and whatnot.

As for the blinkies on a softcore: that sure does provide a lot of test
coverage already and would be fine to start with if we can find one that
doesn't need additional tooling, but in my mind some kind of complicated
math procedure that can verify it's result and only blinks if it verifies
would be ideal :D

On Tue, Apr 23, 2024 at 01:40:48PM +0200, Philipp Klaus Krause wrote:
> I have done a quick test of the latest upstream release, yosys 0.40 on
> my Debian GNU/Linux (mixture of testing and unstable) amd64 system.

All sounds good. I'll be at mini DebConf Berlin in a couple of weeks and
I'll be working on this stuff there. Would be good if you have some time
while that's going on (14-21th May) to do testing.

> the FPGA board yet. Just like in 0.38, I had to use -nomx8, as the
> defaults generate MX8 cells that haven't been supported by the P tool
> for many months: https://github.com/YosysHQ/yosys/issues/4355

Sounds like something we could paper over with a patch, but I'm not sure we
should really.

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1069749: smistrip: Conflicts/Replaces broken after t64 transition?

2024-04-24 Thread Daniel Vacek

Package: smistrip
Version: 0.4.8+dfsg2-17
Severity: normal
X-Debbugs-Cc: neel...@gmail.com

It seems that t64 transition changed the Conflicts/Replaces while I guess it
should not have been changed?

As of 0.4.8+dfsg2-16:

  --\ Conflicts (1)
--- libsmi2ldbl (<= 0.4.8+dfsg2-1)
  --\ Replaces (1)
--- libsmi2ldbl (<= 0.4.8+dfsg2-1)

Compared to now after t64 change as of 0.4.8+dfsg2-17:

  --\ Conflicts (1)
--- libsmi2t64 (<= 0.4.8+dfsg2-1)
  --\ Replaces (1)
--- libsmi2t64 (<= 0.4.8+dfsg2-1)

If I'm not wrong this should not change. Otherwise, please close this bug.

--nX


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.8-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_OOT_MODULE, 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)
LSM: AppArmor: enabled

-- no debconf information

Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected

2024-04-23 Thread Daniel Kahn Gillmor

On Mon 2024-04-22 20:17:54 +, Holger Levsen wrote:
> fixed in git.

thanks!  I've just uninstalled the octopus, but i'll consider
reinstalling it later if this and some of the performance issues can be
ironed out (or maybe to help iron out the performance issues, visible
upstream at
https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/issues/102)

> the change seems innocent enough... (I just wasnt expected the different
> formatting styles...)

i hear you, and i've made this exact mistake myself more times than i
can count :P

> the irony is: the autopkg tests for the package had failed which I blamed
> on unstables unstableness these days, so I reviewed the diff once more,
> (again) didnt notice the introduced bug and did a source only upload,
> because the change were tiny... :/

urgh, yeah, unstable breakage makes everything harder.

I'm still thinking about what kinds of autopkgtests might be useful in
terms of ensuring that thunderbird actually works with librnp, though.
that's different from the autopkgtests generated by debcargo.

I'll report that in a different bug report, though, maybe we can
brainstorm there.

   --dkg

signature.asc
Description: PGP signature

Bug#1069727: libsequoia-octopus-librnp: Thunderbird integration autopkgtests

2024-04-23 Thread Daniel Kahn Gillmor

Package: libsequoia-octopus-librnp
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 

the octopus has a simple, superficial autopkgtest, which just confirms
that the library has the expected symbols.

It would be great to have an autopkgtest that confirms that it actually
interoperates with Thunderbird as expected.

For example, such a test might:

- set up a bogus, local-only MTA

- configure two Thunderbird profiles with OpenPGP to talk to that MTA

- send an mail from profile A to profle B, including the OpenPGP cert
  for A
  
- read the mail on profile B, and reply with a signed-and-encrypted mail
  to A.

- read the cleartext message with profile A.

Perhaps upstream could help us assemble a comparable test that would run
reliably in ci.debian.org.

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


signature.asc
Description: PGP signature

Bug#1068951: new upstream (6.x)

2024-04-23 Thread Daniel Baumann


Hi,

On 4/23/24 13:58, Jakub Ružička wrote:
but we've agreed the time has come to get extra testing & feedback 
through Debian experimental.


yay, thanks!

[ we use knot-resolver at work for the central resolvers for the 
university, and we love it. kresd 6 offers some nice improvements for 
us, so looking forward testing it (via local bookworm-backports we 
maintain) ]


The only blocker for that is missing python3-json-schema-for-humans 
needed for docs build which I intend to package later - for now I guess 
I'll just disable the docs build.


(just as an offer) I'll maintain a bunch of python modules already and 
don't mind another, so I can upload that later today if this is any help.



I'm hitting boundaries of my Debian knowledge so it's slow.


I'm happy to help if you want.

For example, upstream package uses meson directly and builds in 
meson_deb dir, but debian package uses debhelper with 
obj-x86_64-linux-gnu dir and I don't know howto properly reference it 
from d/rules without relying on shady strings.


I didn't find a branch on the salsa repo, where would I find the current 
6.x state to send patches against?


Regards,
Daniel

Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected

2024-04-22 Thread Daniel Kahn Gillmor

Package: libsequoia-octopus-librnp
Version: 1.8.1-3
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor 

Trying to install libsequoia-octopus-librnp:

/var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting 
"then")
dpkg: error processing archive 
/tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb 
(--unpack):
 new libsequoia-octopus-librnp package pre-installation script subprocess 
returned error exit status 2

Please try at least installing and uninstalling the package before
pushing it into unstable!

This also makes me wonder whether we should be doing anything in an
autopkgtest kind of way for this package.  It'd be great to get some
more automated confirmation that the things are working as expected
before we inflict them on the rest of the debian ecosystem :P

   --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.6.15-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 libsequoia-octopus-librnp depends on:
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libhogweed6t64  3.9.1-2.2
ii  libnettle8t64   3.9.1-2.2
ii  libsqlite3-03.45.1-1
ii  libssl3t64  3.2.1-3

Versions of packages libsequoia-octopus-librnp recommends:
ii  zenity  4.0.1-1

Versions of packages libsequoia-octopus-librnp suggests:
ii  thunderbird  1:115.10.1-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#979617: tcplay: VeraCrypt support

2024-04-22 Thread Daniel Kahn Gillmor

On Sun 2024-04-21 15:44:12 +0200, László Böszörményi (GCS) wrote:
>  I prefer communication first. :) Currently I'm travelling so I can
> only check it on Tuesday.

That's why i uploaded to DELAYED/15 :)  thanks for offering to take a
look at it later this week, László!

>  There were some license problems in the past at least, which
> prevented packaging. I will check the current situation.

That's good to know!  in the version i uploaded, it looked like a simple
2-clause BSD, but i'm sure you have more detailed historical knowledge.

All the best,

 --dkg

signature.asc
Description: PGP signature

Bug#1059643: RFS: wstroke/2.1-1 [ITP] -- Mouse gesture plugin for Wayfire.

2024-04-21 Thread Daniel Kondor


Control: tags -1 - moreinfo


Thank you for the review! I've addressed the issues and lintian warnings 
mentioned. Let me know if there are more issues.


Best,

Daniel

Bug#1069593: libsequoia-octopus-librnp: dpkg-divert in preinst doesn't happen on upgrade

2024-04-21 Thread Daniel Kahn Gillmor

Package: libsequoia-octopus-librnp
Version: 1.8.1-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 
Control: affects -1 thunderbird gpg-from-sq gpgv-from-sq

When i try to install thunderbird 1:115.10.1-1, i get this error:

```
Unpacking thunderbird (1:115.10.1-1) over (1:115.9.0-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/thunderbird_1%3a115.10.1-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/thunderbird/librnp.so', which is also in package 
libsequoia-octopus-librnp 1.8.1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/thunderbird_1%3a115.10.1-1_amd64.deb
```

This looks to me like the octopus's dpkg-diversion is supposed to work
to avoid this, but i don't see it happening.

This seems to be due to the way the preinst script adds the diversion:

```
if [ "$1" != "upgrade" ] ; then
  add_diversion /usr/lib/thunderbird/librnp.so
fi
```

i had version 1.8.1-1 installed before 1.8.1-2, which meant that i
upgraded, and i didn't get the diversion added:

grep octopus /var/log/dpkg.log.1 shows:

2024-03-26 06:38:49 status installed libsequoia-octopus-librnp:amd64 1.8.1-1
2024-03-28 10:27:08 upgrade libsequoia-octopus-librnp:amd64 1.8.1-1 1.8.1-2

Why does the package exclude the diversion when preinst runs on upgrade?

i see the same issue in the use of dpkg-divert in gpg-from-sq and
gpgv-from-sq also, btw.  Compare that to the use of dpkg-divert in
/var/lib/dpkg/info/perl-doc.preinst, for example, which triggers on both
"install" and on "upgrade".

I worked around this on my system by removing libsequoia-octopus-librnp,
upgrading thunderbird, and then reinstalling libsequoia-octopus-librnp,
but it seems like the goal should be to not have to make the user do
that.

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



signature.asc
Description: PGP signature

Bug#1069594: libsequoia-octopus-librnp: library diversion says "$1-thunderbid", but it probably means "$1-thunderbird"

2024-04-21 Thread Daniel Kahn Gillmor

Package: libsequoia-octopus-librnp
Version: 1.8.1-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

/var/lib/dpkg/info/libsequoia-octopus-librnp.preinst contains:


#!/bin/sh
set -e

add_diversion() {
  dpkg-divert --package libsequoia-octopus-librnp --add --rename \
--divert "$1-thunderbid" "$1"
}

# Add diversions for any non-upgrade operation
if [ "$1" != "upgrade" ] ; then
  add_diversion /usr/lib/thunderbird/librnp.so
fi



exit 0



I think "$1-thunderbid" is meant to be "$1-thunderbird" (there is a
missing "r")

  --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.6.15-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 libsequoia-octopus-librnp depends on:
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libhogweed6t64  3.9.1-2.2
ii  libnettle8t64   3.9.1-2.2
ii  libsqlite3-03.45.1-1
ii  libssl3t64  3.2.1-3

Versions of packages libsequoia-octopus-librnp recommends:
ii  zenity  4.0.1-1

Versions of packages libsequoia-octopus-librnp suggests:
ii  thunderbird  1:115.9.0-1+b1

-- no debconf information


signature.asc
Description: PGP signature

Bug#979617: tcplay: VeraCrypt support

2024-04-21 Thread Daniel Kahn Gillmor

Control: retitle 979617 tcplay: new upstream version 3.3 (includes VeraCrypt 
support)

I've just confirmed what Johannes said about tcplay 3.3 building easily
on debian.  I uploaded 3.3-0.1 to unstable as an NMU to DELAYED/15,
after cleaning up the packaging a little bit.

I've imported all the history of the tcplay package from
snapshots.debian.org into a git repo (using "gbp import-dscs --debsnap
tcplay"), and then made my packaging changes on top of that synthetic
history.

I published that git repository (history + my changes) at
https://salsa.debian.org/debian/tcplay on the debian/unstable branch.

Hopefully this NMU is welcomed in the helpful spirit i intended with it!
But if you think it's a bad idea, I don't mind it being NACK'ed.  In the
course of doing the cleanup i noticed a few weird things about the
packaging for libtcplay, that i wasn't sure how to best fix, so i just
recorded them in the BTS.

I also cleaned up upstream's manpages a bit, and reported those fixes
upstream at https://github.com/bwalex/tc-play/pull/84

There are probably more things that could be cleaned up upstream (the
modern toolchain makes a lot of complaints about the tcplay source), but
i haven't tried to fix or even report those yet.

I've also tested a backported version of 3.3-0.1 to debian stable, and
it seems to work fine to create an interoperable VeraCrypt volume
(methodology described below).  The backport to bookworm required
nothing more than a new entry in debian/changelog, which is published on
the debian/bookworm branch in salsa (but not uploaded anywhere yet).

I tested on a dual-boot x86_64 system where /dev/vda5 is a slice visible
to both a Debian stable installation with tcplay 3.3-0.1~bpo12+1 and a
Windows 11 system with VeraCrypt 1.26.7 (64-bit) installed.

On the Debian side, i did:

```
tcplay --create --device=/dev/vda5 --pbkdf-prf=SHA256-VC
cryptsetup open --type=tcrypt /dev/vda5 vera
mkfs -t vfat /dev/mapper/vera
mount /dev/mapper/vera /mnt
echo "this is a test" > /mnt/testing.txt
umount /mnt
cryptsetup close vera
```

Then i rebooted the system into Windows, and using Veracrypt, i was able
to map the volume onto the E: drive using the same password i'd entered
with tcplay and "cryptsetup open", and then read "this is a test" out of
E:\testing.txt

In my test, my password was plain 7-bit clean US-ASCII; i didn't try any
fancier passwords.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#1069588: src:tcplay: libtcplay package name doesn't match soname

2024-04-20 Thread Daniel Kahn Gillmor

Source: tcplay
Version: 1.1-6
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

In looking at cleaning up the tcplay package in debian, i noticed that
the libtcplay package name doesn't match the SONAME of libtcplay.so.1.1

It looks like upstream hasn't actually been doing normal C library
versioning (the library versioning is exactly the same as the whole
package version number), and i see no reverse dependencies on libtcplay,
so maybe this isn't a big deal.  But future package cleanup might want
to rename the library packages in some way that fits with the rest of
the C library ecosystem, if this library package is expected to be
useful.

Even tools like luckyluks and zulucrypt don't appear to depend on the
libtcplay library, instead depending on /usr/sbin/tcplay.  That suggests
that the library isn't well-integrated into the ecosystem of tools that
might manage veracrypt or truecrypt volumes.

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


signature.asc
Description: PGP signature

Bug#1069589: src:tcplay: libtcplay is not cross-platform or multi-arch in any modern way

2024-04-20 Thread Daniel Kahn Gillmor

Source: tcplay
Version: 1.1-6
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

libtcplay gets installed directly in /usr/lib, and tcplay.pc gets placed
in /usr/lib/pkgconfig.  For modern, multiarch systems, these should
probably be placed in a different location.

We're also currently patching the build system (with
debian/patches/do_not_add_lib_suffix.patch) to avoid sticking "64" on
the end of the library name -- this suggests that upstream also isn't
handling multiarch in any standard debian way.

The library doesn't actually seem to be used anywhere at the moment,
which suggests both that this isn't a big deal, but maybe also that if
the library was adapted to modern practice, maybe it would encourage
more use.

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


signature.asc
Description: PGP signature

Bug#979617: tcplay: VeraCrypt support

2024-04-20 Thread Daniel Kahn Gillmor

Retitle: 979617 tcplay: new upstream version 3.3 (includes VeraCrypt support)

On Thu 2023-02-16 15:07:10 +0100, Johannes Truschnigg wrote:
> tc-play 3.3 seems to build fairly cleanly on bullseye from its tag/release
> tarball [0]. It'd be *really* nice to have in Debian to be able to handle
> VeraCrypt volumes.

It would be great to have this updated version of tcplay in debian.

If there's some reason to not update tcplay in debian, it would be good
to know.

The package hasn't seen any updates in debian since oldoldstable.

--dkg

signature.asc
Description: PGP signature

Bug#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)

2024-04-20 Thread Daniel Gröber

Hi Philipp,

Thanks for reaching out, I rely on users to ask for FPGA toolchain updates
since I like to errr on the side of "keep the working version" with
electronics stuff until I have a reason to break it out and test it myself.

Note to self: I almost missed your email due to pre-vacation crunch.
Really need to teach my sieve scripts to flag bug mails for my packages :)

On Mon, Apr 01, 2024 at 11:48:16AM +0200, Philipp Klaus Krause wrote:
> I use yosys to synthesize for the iCE40UP and GateMate FPGAs. IMO, the
> current upstream release 0.38 has substantial improvements over the 0.33
> release currently in Debian.

Neat, are the GateMates finally available on the open market then? I'd love
to get my hands on some dev hardware.

Are you open to doing some testing for the new package version once I get
around to putting it together? I can do end-to-end testing on ICE40(HX) and
(probably) GW1N (if I can figure out how to flash this thing) maybe
@Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?

I've been meaning to look into what we could use for testing beyond simple
blinkies. Perhaps some CPU? I'd like to have something that can run
internal consistency checks. If anyone has any ideas let me know.

Thanks,
--Daniel

signature.asc
Description: PGP signature

Bug#1069349: live-build: Regression in d14306a7 leading to build failures

2024-04-20 Thread Daniel Reichelt

Package: live-build
Version: git-master
Severity: normal

Hi all,

I recently built a .deb of the current master and noticed build failures like 
this:

---8<--
P: Begin copying binary includes...
/usr/lib/live/build/binary_includes: 36: cd: can't cd to config/includes.binary
E: An unexpected failure occurred, exiting...

---8<--

...since I don't have any files stored in config/includes.binary and since 
commit d14306a7, the check for the exixtence of such files is no longer 
happening.


Partially reverting d14306a7 with respect to binary_includes resolved the issue 
for me.


Cheers

Daniel

Bug#1069202: closed by Debian FTP Masters (reply to Holger Levsen ) (Bug#1069202: fixed in rust-sequoia-chameleon-gnupg 0.8.0-3)

2024-04-18 Thread Daniel Kahn Gillmor

Control: reopen 1069202
Control: found 1069202 0.8.0-3

The symlinks in the gpg-from-sq and gpgv-from-sq packages appear to
point in the wrong direction.  That is, gpg-from-sq installs a symlink
at /usr/bin/gpg-sq, which refers to gpg.  Instead, gpg-from-sq should
install a symlink at /usr/bin/gpg, which should refer to gpg-sq.

This makes it impossible to install either *-from-sq package alongside
its *-sq partner.

--dkg


signature.asc
Description: PGP signature

Bug#1069213: elpa-rust-mode: noisy warnings when in rust-mode

Package: elpa-rust-mode
Version: 0.4.0-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 
File: /usr/share/emacs/site-lisp/elpa-src/rust-mode-0.4.0/rust-mode.el

When i enter rust-mode on a file that has no problems, i see the
following warnings in the emacs *Warning* buffer:

⛔ Warning (comp): rust-mode.el:57:2: Warning: docstring wider than 80 characters
⛔ Warning (comp): rust-mode.el:63:2: Warning: docstring wider than 80 characters
⛔ Warning (comp): rust-mode.el:300:47: Warning: ‘point-at-bol’ is an obsolete 
function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead.
⛔ Warning (comp): rust-mode.el:627:2: Warning: defvar 
`rust-builtin-formatting-macros' docstring wider than 80 characters
⛔ Warning (comp): rust-mode.el:1141:2: Warning: docstring wider than 80 
characters
⛔ Warning (comp): rust-mode.el:1229:2: Warning: docstring wider than 80 
characters
⛔ Warning (comp): rust-mode.el:1243:2: Warning: docstring wider than 80 
characters

These sound like things that should be cleaned up in rust-mode.el so
that when there is a meaningful warning it doesn't get lost in the
noise.

Thanks for maintaining elpa-rust-mode in debian!

  --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.6.15-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 elpa-rust-mode depends on:
ii  dh-elpa-helper  2.0.17
ii  emacsen-common  3.0.5

Versions of packages elpa-rust-mode recommends:
ii  emacs   1:29.2+1-2
ii  emacs-pgtk [emacs]  1:29.2+1-2

elpa-rust-mode suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069212: src:rust-sequoia-openpgp: FTBFS when any librust--dev packages that contain .lalrpop files are installed

Source: librust-sequoia-openpgp-dev
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

Hi all--

If i try building rust-sequoia-openpgp (e.g. using debuild -uc -us) as a
non-privileged user on a system that has some unnecessary dependencies
installed, i will sometimes get a failure during build.rs that looks
something like the following (this example is from building on a system
that has the previous version of librust-sequoia-openpgp-dev installed):


-
 Running 
`/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
[sequoia-openpgp 1.20.0] Selected cryptographic backend: Nettle
[sequoia-openpgp 1.20.0] processing file 
`/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`
[sequoia-openpgp 1.20.0] thread 'main' panicked at 'called `Result::unwrap()` 
on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission 
denied" }', build.rs:10:29
[sequoia-openpgp 1.20.0] stack backtrace:
[sequoia-openpgp 1.20.0]0: rust_begin_unwind
[sequoia-openpgp 1.20.0]  at 
/usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
[sequoia-openpgp 1.20.0]1: core::panicking::panic_fmt
[sequoia-openpgp 1.20.0]  at 
/usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
[sequoia-openpgp 1.20.0]2: core::result::unwrap_failed
[sequoia-openpgp 1.20.0]  at 
/usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
[sequoia-openpgp 1.20.0]3: core::result::Result::unwrap
[sequoia-openpgp 1.20.0]  at 
/usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
[sequoia-openpgp 1.20.0]4: build_script_build::main
[sequoia-openpgp 1.20.0]  at ./build.rs:10:5
[sequoia-openpgp 1.20.0]5: core::ops::function::FnOnce::call_once
[sequoia-openpgp 1.20.0]  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
[sequoia-openpgp 1.20.0] note: Some details are omitted, run with 
`RUST_BACKTRACE=full` for a verbose backtrace.
error: failed to run custom build command for `sequoia-openpgp v1.20.0 
(/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0)`

Caused by:
  process didn't exit successfully: 
`/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/target/debug/build/sequoia-openpgp-0b6c8220513fd567/build-script-build`
 (exit status: 101)
  --- stdout
  processing file 
`/tmp/cdtemp.FKNrwM/rust-sequoia-openpgp-1.20.0/debian/cargo_registry/sequoia-openpgp-1.19.0/src/cert/parser/low_level/grammar.lalrpop`

  --- stderr
  Selected cryptographic backend: Nettle
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { 
code: 13, kind: PermissionDenied, message: "Permission denied" }', 
build.rs:10:29
  stack backtrace:
 0: rust_begin_unwind
   at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
 1: core::panicking::panic_fmt
   at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
 2: core::result::unwrap_failed
   at /usr/src/rustc-1.70.0/library/core/src/result.rs:1687:5
 3: core::result::Result::unwrap
   at /usr/src/rustc-1.70.0/library/core/src/result.rs:1089:23
 4: build_script_build::main
   at ./build.rs:10:5
 5: core::ops::function::FnOnce::call_once
   at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.
dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101
make: *** [debian/rules:3: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1184:
dpkg-buildpackage -us -uc -ui failed
-

The key part of this failure appears to be during build.rs, when lalrpop
traversing into the custom "cargo_registry" that is built as a symlink
farm in debian/cargo_registry, where each symlink points to the matching
crate in the system-installed /usr/share/cargo/registry/

The relevant line in build.rs is line 10, where lalrpop::process_root()
is invoked:

 7  fn main() {
 8  crypto_backends_sanity_check();
 9  include_openssl_conf();
10  lalrpop::process_root().unwrap();
11  include_test_data().unwrap();
12  }

I think this yields a "Permission denied" error when run over a
directory that the user can't write to, but i haven't investigated
further.

It's possible that this report should be applied to one of the lalrpop
crates or something, instead, if the issue isn't something that should
be fixed in build.rs in the sequoia-openpgp crate.  Feel free to
reassign with a clear explanation.

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

Bug#1069207: src:rust-base64: rust-base64 0.22.0 is available (upgrade from 0.21.7)

Source: rust-base64
Version: 0.21.7-1
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 

rust-base64 has a new upstream version 0.22.0 available, with the
following subtle changes to the API since 0.21.7:


- `DecodeSliceError::OutputSliceTooSmall` is now conservative rather
   than precise. That is, the error will only occur if the decoded
   output _cannot_ fit, meaning that `Engine::decode_slice` can now be
   used with exactly-sized output slices. As part of this,
   `Engine::internal_decode` now returns `DecodeSliceError` instead of
   `DecodeError`, but that is not expected to affect any external
   callers.

- `DecodeError::InvalidLength` now refers specifically to the _number of
  valid symbols_ being invalid (i.e. `len % 4 == 1`), rather than just
  the number of input bytes. This avoids confusing scenarios when based
  on interpretation you could make a case for either `InvalidLength` or
  `InvalidByte` being appropriate.


In debian, we have a bunch of different packages that depend on 0.21:

Versions of rdeps of rust-base64 in unstable, that also exist in testing:
  librust-alacritty-terminal-dev   0.19.1-7 depends on  
   librust-base64-0.21+default-dev, 
  librust-bson-dev 2.10.0-1 depends on  
   librust-base64-0.21+default-dev, 
  librust-cargo-dev0.70.1-2 depends on  
   librust-base64-0.21+default-dev, 
  librust-charset-dev  0.1.3-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-cookie-dev   0.18.0-1 depends on  
   librust-base64-0.21+default-dev (>= 0.21.4-~~), 
  librust-embed-doc-image-dev  0.1.4-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-fernet-dev   0.2.0+really0.1.4-3 depends 
on librust-base64-0.21+default-dev, 
  librust-gix-transport-dev0.42.0-1 depends on  
   librust-base64-0.21+default-dev, 
  librust-headers-dev  0.3.9-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-http-auth-dev0.1.8-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-jsonwebtoken-dev 8.3.0-4  depends on  
   librust-base64-0.21+default-dev, 
  librust-oauth2-dev   4.4.1-2  depends on  
   librust-base64-0.21+default-dev, 
  librust-openssh-keys-dev 0.6.2-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-parsec-service-dev   1.3.0-5+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-parsec-tool-dev  0.7.0-4  depends on  
   librust-base64-0.21+default-dev, 
  librust-pem-dev  3.0.3-2  depends on  
   librust-base64-0.21+alloc-dev, librust-base64-0.21+std-dev, 
  librust-picky-asn1-x509-dev  0.10.0-1+b1  depends on  
   librust-base64-0.21+default-dev, 
  librust-plist-dev1.6.1-1  depends on  
   librust-base64-0.21+default-dev, 
  librust-postgres-protocol-dev0.6.6-2  depends on  
   librust-base64-0.21+default-dev, 
  librust-reqwest-dev  0.11.24-3depends on  
   librust-base64-0.21+default-dev, 
  librust-rfc2047-decoder-dev  0.2.2-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-ripasso-dev  0.6.5-2  depends on  
   librust-base64-0.21+default-dev (>= 0.21.2-~~), 
  librust-ron-dev  0.7.1-3  depends on  
   librust-base64-0.21+default-dev, 
  librust-ruma-common-dev  0.10.5-4 depends on  
   librust-base64-0.21+default-dev, 
  librust-rust-argon2-dev  1.0.0-3  depends on  
   librust-base64-0.21+default-dev, 
  librust-rustls-pemfile-dev   1.0.3-1  depends on  
   librust-base64-0.21+default-dev, 
  librust-sequoia-autocrypt-dev0.25.1-1 depends on  
   librust-base64-0.21+default-dev, 
  librust-sequoia-net-dev  0.28.0-1 depends on  
   librust-base64-0.21+default-dev, 
  librust-sequoia-openpgp-dev  1.19.0-1 depends on  
   librust-base64-0.21+default-dev, 
  librust-serde-with-dev   3.4.0-2  depends on  
   librust-base64-0.21+alloc-dev, librust-base64-0.21-dev, 
  librust-sqlx-postgres-dev0.7.3-1  depends on  
   librust-base64-0.21+std-dev, 
  librust-sshkeys-dev  0.3.2-1+b1   depends on  
   librust-base64-0.21+default-dev, 
  librust-totp-

Bug#1069205: gpg-from-sq: gpg-from-sq should Provides: gpg

Package: gpg-from-sq
Version: 0.8.0-1
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 

If i install gpg-from-sq, i'd expect it to satisfy any dependency that
exists for gpg.  That means it should probably have a Provides: header.

Given that the current chameleon sources infer the behavior from GnuPG's
version 2.2.40 release, it would also probably make sense for it to be a
versioned Provides:, mapped to the version upstream uses to sort out the
interface.

This is probably a little bit more dubious than the parallel bug for
gpgv-from-sq (#1069203) because the chameleon's gpg interface doesn't
claim feature completeness, while its gpgv interface does claim it.

--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.6.15-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 gpg-from-sq depends on:
ii  gpg-sq  0.8.0-1

gpg-from-sq recommends no packages.

gpg-from-sq suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069203: gpgv-from-sq: gpgv-from-sq should Provides gpgv (= 2.2.40)

Package: gpgv-from-sq
Version: 0.8.0-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

If i install gpgv-from-sq, i'd expect it to satisfy any dependency that
exists for gpgv.  That means it should probably have a Provides: header.

Given that the current chameleon sources infer the behavior from GnuPG's
version 2.2.40 release, it would also probably make sense for it to be a
versioned Provides:, mapped to the version upstream uses to sort out the
interface.

--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.6.15-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 gpg-from-sq depends on:
ii  gpg-sq  0.8.0-1

gpg-from-sq recommends no packages.

gpg-from-sq suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069202: gpg-sq: gpg-from-sq diverts /usr/bin/gpg but doesn't place a symlink pointing to gpg-sq

Package: gpg-from-sq
Version: 0.8.0-1
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor 

I did:

 apt install gpg-from-sq

and i expected to run `gpg --version` and see the resultant info from
the chameleon.

Instead, i see:

bash: gpg: command not found

I'm seeing the same issue with gpg-from-sq version 0.8.0-1

--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.6.15-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 gpg-sq depends on:
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15
ii  libgcc-s1   14-20240201-3
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libhogweed6t64  3.9.1-2.2
ii  libnettle8t64   3.9.1-2.2
ii  libsqlite3-03.45.1-1
ii  libssl3t64  3.2.1-3

Versions of packages gpg-sq recommends:
ii  sq  0.33.0-3

gpg-sq suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1069201: src:rust-sequoia-chameleon-gnupg: gpg-sq and gpgv-sq from 0.8.0 conflict with sequoia-chameleon-gnupg 0.5.1

Source: rust-sequoia-chameleon-gnupg
Version: 0.8.0-1
Severity: grave
X-Debbugs-Cc: Daniel Kahn Gillmor 


trying to upgrade from sequoia-chameleon-gnupg 0.5.1-1  to
sequoia-chameleon-gnupg 0.8.0-1, i see this:

```
Selecting previously unselected package gpg-sq.
Preparing to unpack .../gpg-sq_0.8.0-1_amd64.deb ...
Unpacking gpg-sq (0.8.0-1) ...
dpkg: error processing archive /var/cache/apt/archives/gpg-sq_0.8.0-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/bin/gpg-sq', which is also in package 
sequoia-chameleon-gnupg 0.5.1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Selecting previously unselected package gpgv-sq.
Preparing to unpack .../gpgv-sq_0.8.0-1_amd64.deb ...
Unpacking gpgv-sq (0.8.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/gpgv-sq_0.8.0-1_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/gpgv-sq', which is also in package 
sequoia-chameleon-gnupg 0.5.1-2
Preparing to unpack .../sequoia-chameleon-gnupg_0.8.0-1_all.deb ...
Unpacking sequoia-chameleon-gnupg (0.8.0-1) over (0.5.1-2) ...
Errors were encountered while processing:
 /var/cache/apt/archives/gpg-sq_0.8.0-1_amd64.deb
 /var/cache/apt/archives/gpgv-sq_0.8.0-1_amd64.deb
```

I think this is just missing some Replaces/Breaks annotations, as per:

https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages

This is probably worth fixing before it migrates into testing.

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


signature.asc
Description: PGP signature

Bug#1067025: dokuwiki: Please package the new upstream version 2024-02-06a "Kaos"

2024-04-15 Thread Daniel Baumann


Hi,

any news or ETA on this? do you need help?

Regards,
Daniel

Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

2024-04-15 Thread Daniel Lewart

Otto, et al,

On Sun, Apr 7, 2024 at 12:09 AM Otto Kekäläinen  wrote:
>
> Hi Daniel!
>
> Do you think this change is still needed?
>
> Do you want to participate in some open source development/testing to
> make it work?
>
> On Sun, 14 Jan 2024 at 16:03, Otto Kekäläinen  wrote:
> >
> > FYI: Discussion about this continued in
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61

Yes.  I believe that the default configuration should not generate
errors or warnings
when MariaDB is started.  Version 1:10.11.6-2 has one of each (see below).

And I agree with you that upstream option values should only be
changed if there are compelling reasons.

Thank you!
Dan
Urbana, Illinois
---
"PRIORITY" : "3",
"MESSAGE" : "2024-04-16  1:33:25 0 [Warning] You need to use --log-bin
to make --expire-logs-days or --binlog-expire-logs-seconds work.",

"PRIORITY" : "4",
"MESSAGE" : "mariadb.service: Referenced but unset environment
variable evaluates to an empty string: MYSQLD_OPTS,
_WSREP_NEW_CLUSTER",
###

Bug#1069072: new upstream (0.36)

2024-04-15 Thread Daniel Baumann


Package: nwipe

Hi,

it would be nice if you could upload the current nwipe release to Debian.

Regards,
Daniel

Bug#1069032: RM: berkeley-abc (+ qflow and graywolf) -- ROM; replaced by yosys-abc

2024-04-15 Thread Daniel Gröber

Package: ftp.debian.org
Control: affects -1 + src:berkeley-abc
Control: affects -1 + src:qflow
Control: affects -1 + src:graywolf
X-Debbugs-Cc: berkeley-...@packages.debian.org
X-Debbugs-Cc: qf...@packages.debian.org
X-Debbugs-Cc: gayw...@packages.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: d...@darkboxed.org
Severity: normal

Hi,

I've absorbed my package bekeley-abc into src:yosys, as yosys-abc.

However some unmaintained packages in Debian still depend on
berkeley-abc. I've reviewed the possibility of just swapping out the
dependencies for yosys-abc (since it's compatible) but it seems too much
effort for packages that haven't been properly maintained since 2019 and I
don't care about or use.

Unfortunately Ruben, the previous maintainer of these ASIC flow tools, said
he doesn't have time anymore back when I asked about taking over the FPGA
related tools. I don't think anything changed there. I asked if anybody
wanted to maintain qflow/opensta on the pkg-electronics-devel ML[1] but got
no response.

[1]:
https://alioth-lists.debian.net/pipermail/pkg-electronics-devel/2023-September/010490.html

Consequently I'd like to request removing berkeley-abc and all it's rdpends
(qflow and graywolf) from unstable. While graywolf only recommends qflow it
doesn't seem very useful without it.

Note: src:debian-electronics also still recommends some of these but I'm
working on an upload to remove those pkg relationships.

We may also want to consider opensta since it seems useless other than as a
dependency for qflow.

Thanks,
--Daniel

Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st


Hi Tobias,

On 4/14/24 13:55, Tobias Frost wrote:

As I have the package ready, I'd like to propose to maintain it as new
package


In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces 
(and 5 other extensions) as individual source packages as every other 
gnome-shell extension is packaged in Debian.


ftp-master rejected all of them and insisted, that I create an artifical 
package (one src producing one binary) containing all 6 extensions 
together. This is how gnome-shell-extension-vertical-workspaces is 
included in bookworm and anything newer. You can read more about this in 
#1030683.


I don't think ftp-master has changed their opinion. If they did, I'm 
happy to break it up and re-upload the extensions as individual packages 
again like I did in the first place in January 2023.


ftp-master/Thorsten: What is your current opinion, can I upload the 
extensions as individual extensions again, or do we have to keep the 
aggregation package?


Regards,
Daniel

Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st


Hi Tobias,

On 4/14/24 10:14, Tobias Frost wrote:

* Package name: gnome-shell-extension-vertical-workspaces


this is already included in src:gnome-shell-extensions-extra.

Regards,
Daniel

Bug#1062068: nvme-cli package fails to download firmware file for nvme


close 1062068
thanks

Hi Anubhav,

thank you for your report.

Unfortunately you're using a very old version of nvme-cli that can not 
be expected to work with recent firmware files.


Please upgrade nvme-cli to a more recent version (at last the one in 
stable).


Regards,
Daniel

Bug#1064390: mdadm: new upstream version 4.3 available


close 1064390 4.3-1
thanks

Hi Graham,

thanks - I've just uploaded 4.3.

Regards,
Daniel

Bug#1042906: ansible: please package new upstream version 8.x


retitle 1042906 please package new upstream version 9.x
thanks

Hi Lee,

any updates since last year? Ansible is currently at 9.x and I'd really
like to be able to use a recent enough version of ansible via debian
packages. Is there anything I could help you with?

Regards,
Daniel

Bug#1068955: incompatible with inkscape 1.3


Package: inkscape-open-symbols
Severity: wishlist

Hi,

thank you for maintaining inkscape-open-symbols.

As inkscape-open-symbols 1.2 is incompatible with inkscape 1.3 in 
experimental, it would be nice if you could upload a newer version of 
inkscape-open-symbols to experimental too.


Regards,
Daniel

Bug#1068954: bookworm-pu: package libnvme/1.3-1+deb12u1


Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

Hi,

when scanning ("nvme list") some buggy NVMe ssds that don't like blocks 
of less than 4096 bytes send to them, a buffer overflow happens.


Upstream fixed this in libnvme 1.7, I've cherry-picked this for 
bookworm, attached is the full diff for review. Please let me know if I 
can upload it to bookworm-pu.


Regards,
Danieldiff --git a/debian/changelog b/debian/changelog
index 2666b0a..d7cef38 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+  * Uploading to bookworm.
+  * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann   Sun, 14 Apr 2024 08:57:21 +0200
+
 libnvme (1.3-1) sid; urgency=medium
 
   * Uploading to sid.
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..f31922e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+upstream/0001-alloc-helper.patch
+upstream/0002-aligned-payloads.patch
diff --git a/debian/patches/upstream/0001-alloc-helper.patch b/debian/patches/upstream/0001-alloc-helper.patch
new file mode 100644
index 000..deafcae
--- /dev/null
+++ b/debian/patches/upstream/0001-alloc-helper.patch
@@ -0,0 +1,52 @@
+commit a2b8e52e46cfd888ac5a48d8ce632bd70a5caa93
+Author: Tomas Bzatek 
+Date:   Tue Oct 10 18:16:24 2023 +0200
+
+util: Introduce alloc helper with alignment support
+
+Similar to nvme-cli an alloc helper is needed for a couple
+of ioctls sent out during tree scan.
+
+Signed-off-by: Tomas Bzatek 
+
+diff --git a/src/nvme/private.h b/src/nvme/private.h
+index 6fb9784a..ee9d738b 100644
+--- a/src/nvme/private.h
 b/src/nvme/private.h
+@@ -182,6 +182,8 @@ nvme_ctrl_t __nvme_lookup_ctrl(nvme_subsystem_t s, const char *transport,
+ 			   const char *host_iface, const char *trsvcid,
+ 			   const char *subsysnqn, nvme_ctrl_t p);
+ 
++void *__nvme_alloc(size_t len);
++
+ #if (LOG_FUNCNAME == 1)
+ #define __nvme_log_func __func__
+ #else
+diff --git a/src/nvme/util.c b/src/nvme/util.c
+index 8fe094d5..20679685 100644
+--- a/src/nvme/util.c
 b/src/nvme/util.c
+@@ -7,6 +7,7 @@
+  * 	Chaitanya Kulkarni 
+  */
+ 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -1058,3 +1059,15 @@ bool nvme_iface_primary_addr_matches(const struct ifaddrs *iface_list, const cha
+ }
+ 
+ #endif /* HAVE_NETDB */
++
++void *__nvme_alloc(size_t len)
++{
++	size_t _len = round_up(len, 0x1000);
++	void *p;
++
++	if (posix_memalign((void *), getpagesize(), _len))
++		return NULL;
++
++	memset(p, 0, _len);
++	return p;
++}
diff --git a/debian/patches/upstream/0002-aligned-payloads.patch b/debian/patches/upstream/0002-aligned-payloads.patch
new file mode 100644
index 000..8c514d0
--- /dev/null
+++ b/debian/patches/upstream/0002-aligned-payloads.patch
@@ -0,0 +1,60 @@
+commit 68c6ffb11d40a427fc1fd70ac2ac97fd01952913
+Author: Tomas Bzatek 
+Date:   Tue Oct 10 18:18:38 2023 +0200
+
+tree: Allocate aligned payloads for ns scan
+
+libnvme is actually doing some namespace identification
+during tree scan, leading to stack smash on some systems.
+
+Signed-off-by: Tomas Bzatek 
+
+diff --git a/src/nvme/tree.c b/src/nvme/tree.c
+index 00cf96f7..5636aa18 100644
+--- a/src/nvme/tree.c
 b/src/nvme/tree.c
+@@ -2404,26 +2404,33 @@ static void nvme_ns_parse_descriptors(struct nvme_ns *n,
+ 
+ static int nvme_ns_init(struct nvme_ns *n)
+ {
+-	struct nvme_id_ns ns = { };
+-	uint8_t buffer[NVME_IDENTIFY_DATA_SIZE] = { };
+-	struct nvme_ns_id_desc *descs = (void *)buffer;
++	struct nvme_id_ns *ns;
++	struct nvme_ns_id_desc *descs;
+ 	uint8_t flbas;
+ 	int ret;
+ 
+-	ret = nvme_ns_identify(n, );
+-	if (ret)
++	ns = __nvme_alloc(sizeof(*ns));
++	if (!ns)
++		return 0;
++	ret = nvme_ns_identify(n, ns);
++	if (ret) {
++		free(ns);
+ 		return ret;
++	}
+ 
+-	nvme_id_ns_flbas_to_lbaf_inuse(ns.flbas, );
+-	n->lba_shift = ns.lbaf[flbas].ds;
++	nvme_id_ns_flbas_to_lbaf_inuse(ns->flbas, );
++	n->lba_shift = ns->lbaf[flbas].ds;
+ 	n->lba_size = 1 << n->lba_shift;
+-	n->lba_count = le64_to_cpu(ns.nsze);
+-	n->lba_util = le64_to_cpu(ns.nuse);
+-	n->meta_size = le16_to_cpu(ns.lbaf[flbas].ms);
++	n->lba_count = le64_to_cpu(ns->nsze);
++	n->lba_util = le64_to_cpu(ns->nuse);
++	n->meta_size = le16_to_cpu(ns->lbaf[flbas].ms);
+ 
+-	if (!nvme_ns_identify_descs(n, descs))
++	descs = __nvme_alloc(NVME_IDENTIFY_DATA_SIZE);
++	if (descs && !nvme_ns_identify_descs(n, descs))
+ 		nvme_ns_parse_descriptors(n, descs);
+ 
++	free(ns);
++	free(descs);
+ 	return 0;
+ }
+

Bug#1068953: new upstream (10.0)


Package: frr
Severity: wishlist

Hi David and Ondrej,

it would be nice if you could upload the newly released frr version. If 
you need/want help, I'm happy to do so, just let me know.


Regards,
Daniel

Bug#1067450: ttyd: does not start


close 1067450
thanks

Hi,

On 3/21/24 18:03, Daniel wrote:

Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: 
libwebsockets context creation failed
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Main process exited, 
code=exited, status=1/FAILURE
Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Failed with result 'exit-code'.


this is a stray issue because of the t64 migration when you haven't
fully updated your system. on a minimal, up2date sid ttyd works
reproducibly fine.

Regards,
Daniel

Bug#1068952: new upstream required for frr


Package: libyang2
Severity: wishlist

Hi Ondrej,

it would be nice if you could upload libyang2 >= 2.1.128 as the new frr 
release requires that. If you need/want help, I'm happy to do so, just 
let me know.


Regards,
Daniel

Bug#1068951: new upstream (6.x)