Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
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#1068174: Debian FPGA toolchain update and testing
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#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)
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#1069032: RM: berkeley-abc (+ qflow and graywolf) -- ROM; replaced by yosys-abc
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#1067754: dkim-rotate: consider raising email_lag to account for RFC timeout
Package: dkim-rotate Version: 0.4 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Ian, I'm concerned dkim-rotate's default mail_lag is too low to account for widely used sending timeouts. RFC2821 says senders SHOULD retry for at least 4-5 days https://datatracker.ietf.org/doc/html/rfc2821#section-4.5.4.1 so mails could legitimately get stuck for that long and still be delivered. Meaning that even when only one SMTP hop is involved in delivery as is admittedly typical the email_lag default of 88h (3.66 days) is a bit short. Thanks, --Daniel
Bug#1067750: dkim-rotate: confusion between config file name: .zone or .conf?
Package: dkim-rotate Version: 0.4 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Ian, The dkim-rotate docs and tool seem confused about whether the config should be in a file called .zone or .conf. As you may remember from Bug#1064452 I used --new to setup my config. While the example config is called example.zone I found I have to copy it into place as dkim.conf for --new to work. Now after leaving the setup running for a while to check if rotations are happening I find they're not. If, instead of relying on the cron job, I call `dkim-rotate --major dkim` by hand it works. It seems in "all instances" mode dkim-rotate only looks at .zone files but in specific instance mode mode dkim-rotate only considers .conf files. Which is it? I'm confused :) --Daniel -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkim-rotate depends on: ii bash 5.2.15-2+b2 ii libgetopt-long-descriptive-perl 0.111-1 ii libmime-tools-perl 5.510-1 ii openssl 3.0.11-1~deb12u2 ii perl 5.36.0-7+deb12u1 Versions of packages dkim-rotate recommends: ii curl 7.88.1-10+deb12u5 ii moreutils 0.67-1 dkim-rotate suggests no packages. -- no debconf information
Bug#1067465: yosys-plugin-ghdl builds on x86 only, but built on other architectures before
Hi Matthias, On Thu, Mar 21, 2024 at 11:16:56PM +0100, Matthias Klose wrote: > Package: src:yosys-plugin-ghdl > * Use ghdl-mcode instead of ghdl-gcc as it's more portable > > but ghdl-mcode is only available on amd64 and i386. With this choice you're > making things worse. My bad, I was under the impression mcode was an interpreter backend. Will fix this with the next upload. --Daniel signature.asc Description: PGP signature
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote: > > Are you sure you want to change the source package name? Doing so fractures > > the history of the package on tracker.d.o and it's not really necessary. > > The upstream has changed software name but it's a good point about > tracker.d.o. Right, so users will try to `apt install foolsm` in the future, but the source package name is largeley irellevant to them. > > Quick package review: > > > > - d/postinst: I don't think it's useful to print the message about editing > > the config. I've only seen packages do that in special circumstances, do > > you have a justification for it being necessary here? > Really, really not. I really would like improve that, I guess to write good > doc and manual pages is enough. I would argue users (sysadmins in this case) are going to be familiar with the concept of having to configure a package before it becomes useful and while the daemon not being started at package installation is unconventional in Debian automatic config reloading is by far not universal so any config change to make lsm useful is going to elicit a restart anyway. So I just don't see why we'd want a conspicuous message telling people what they already know :) > > - You declare Replaces+Conflicts on lsm but you don't seem to take any > > care for the new binary package to actually be compatible with the old > > one since the config location changed. > > I'm in doubt, when the old config exist, if set dpkg to copy the old config > from old location to the new one or if I just print/show up a message to > users notifying about path update requirement. I think an automatic upgrade is the way to go in this case as long as the config format is still fully compatible to the old lsm-1.0.4, but since copying will leave cruft behind for the user to cleanup manually I think we should mv the config. > If it's good/allowed do the copy, it could be applied in postinst. I think > print/show up message is rightest way. Consider that people upgrade Debian systems for many, many years without reinstalling. So every bit of cruft we leave behind due to transitions such as this accumulates. I don't see a technical need for not doing so in this case so I think we should clean up behind ourselves and move the config to the new location. You should then absoluteley print a message in the log to note this fact, but perhaps not as conspicuously as you're printing the "configure me" message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice since the package(s) involved should be obvious from the filenames. --Daniel signature.asc Description: PGP signature
Bug#1067502: ITP: nsdiff -- generate nsupdate script from DNS zone differences
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Daniel Gröber X-Debbugs-Cc: d...@darkboxed.org Severity: wishlist * Package name: nsdiff Version : 1.85 Upstream Contact: Tony Finch * URL : https://dotat.at/prog/nsdiff/ * License : 0BSD OR MIT-0 Programming Lang: Perl Description : generate nsupdate script from DNS zone differences The nsdiff program compares two versions of a DNS zone, and outputs the differences between them as a script for use with the nsupdate. This provides an elegant way to merge (hand written) static zone files into otherwise dynamic zones. nsdiff supports comparing on-disk zone-files and retreiving both sides via standard AXFR zone transfer, optionally autenticated with a TSIG key. Always happy to have co-maintainers but I will maintain this package myself. --Daniel
Bug#1067161: nftables: BUG: invalid mapping expression variable
Hi Jeremy, On Tue, Mar 19, 2024 at 06:27:11PM +, Jeremy Sowden wrote: > On 2024-03-19, at 16:00:28 +0100, Daniel Gröber wrote: > > The nftables config below triggers a BUG. > > > > $ nft -f /etc/nftables.conf > > BUG: invalid mapping expression variable > > nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed. > > Aborted > > > > Refactoring to using $srvaddr_map instead of having the anonymous map > > inline made the bug trigger. > > That assertion has since been replaced upstream by a normal > error-message: > > /space/azazel/tmp/ruleset.1067161.nft:6:58-69: Error: invalid mapping > expression variable > ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map > $srvaddr_map > ~~ > Fair enough then. I do find this a bit of an arbitrary limitation however. > Because of the way parsing works in nftables, one can't use a symbolic > variable in that context. This, however, will work: Yup, that's what I'm doing now. I just keep running into these little irritating limitations with nftables and wanted to at least document this one somewhere. Do you think it's worth forwarding this report upstream anyway? I would like to sand off sharp nftables edges such as this. In case you're curios what I was working on: a generic way to have isolated v6 service addressess for software that doesn't support SO_BINDTODEV (*cough* syncthing *cough*) without hardcoding any prefixes https://paste.debian.net/hidden/66c2ef6e/ --Daniel signature.asc Description: PGP signature
Bug#1067161: nftables: BUG: invalid mapping expression variable
Package: nftables
Version: 1.0.6-2+deb12u2
Severity: normal
Dear Maintainer,
The nftables config below triggers a BUG.
$ nft -f /etc/nftables.conf
BUG: invalid mapping expression variable
nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed.
Aborted
Refactoring to using $srvaddr_map instead of having the anonymous map
inline made the bug trigger.
Thanks,
--Daniel
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-18-amd64 (SMP w/1 CPU thread; PREEMPT)
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 nftables depends on:
ii libc6 2.36-9+deb12u4
ii libedit2 3.1-20221030-2
ii libnftables1 1.0.6-2+deb12u2
Versions of packages nftables recommends:
ii netbase 6.4
Versions of packages nftables suggests:
pn firewalld
-- Configuration Files:
/etc/nftables.conf changed:
flush ruleset
define iid_mask6 = :::::
define srvaddr_map = { ::8384 : 8384 }
table inet filter {
chain input {
type filter hook input priority filter;
}
chain prerouting {
type nat hook prerouting priority dstnat;
ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map
$srvaddr_map # s/ map.*/{ ::8384 : 8384 }/ works
}
chain forward {
type filter hook forward priority filter;
}
chain output {
type filter hook output priority filter;
}
}
-- no debconf information
Bug#1067154: dropbear-initramfs: please allow generating distinct hostkey instead of copying host's
Package: dropbear-initramfs Version: 2022.83-1+deb12u1 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Guilhem, I would like to use a fresh hostkey for dropbear running during init. You see I find it quite jarring for me to unexpectedly land in an earlyboot environment without warning when ssh'ing in (because there was a power outage, say). To fix this I configure init to use an IP address distinct from the system proper. In that setup there's really no point to reusing the hosts' private keys and expose them in the initrd unencrypted. Would you accept a patch to allow configuring the dropbear hook behaviour to generate a new host key instead of reusing the host's key? Thanks, --Daniel
Bug#1066707: ifupdown-ng: FTBFS: libifupdown/interface.c:28:9: error: implicit declaration of function ‘strlcpy’; did you mean ‘strncpy’? [-Werror=implicit-function-declaration]
On Wed, Mar 13, 2024 at 12:51:44PM +0100, Lucas Nussbaum wrote: > Source: ifupdown-ng > > During a rebuild of all packages in sid, your package failed to build > on amd64. Thanks Lucas, I'm uploading a fix right now. > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration It was due to a hardcoded path to libbsd's include directory which seems to have moved to to a multiarch location. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1065711: etckeeper: Incorrect path to README in manpage
Package: etckeeper Version: 1.18.20-1 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Antoine, just a quick report that etckeeper.8 has: /usr/share/doc/etckeeper/README.md.gz which is wrong, the file is at /usr/share/doc/etckeeper/README.mdwn.gz now. Thanks, --Daniel -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages etckeeper depends on: ii brz3.3.2-3 ii debconf [debconf-2.0] 1.5.82 ii git1:2.39.2-1.1 ii mercurial 6.3.2-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-162 Versions of packages etckeeper suggests: ii sudo 1.9.13p3-1+deb12u1 -- debconf information excluded
Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool
Hi Lucas, On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote: > * Package name : foolsm Are you sure you want to change the source package name? Doing so fractures the history of the package on tracker.d.o and it's not really necessary. Quick package review: - d/postinst: I don't think it's useful to print the message about editing the config. I've only seen packages do that in special circumstances, do you have a justification for it being necessary here? - You declare Replaces+Conflicts on lsm but you don't seem to take any care for the new binary package to actually be compatible with the old one since the config location changed. - d/foolsm.init: Still has the old $CONFIG path --Daniel signature.asc Description: PGP signature
Bug#1064452: dkim-rotate: Errors during --new leave state corrupted
Hi Ian,
On Sat, Feb 24, 2024 at 02:16:46PM +, Ian Jackson wrote:
> Daniel Gröber writes ("Bug#1064452: dkim-rotate: Errors during --new leave
> state corrupted"):
> > I'm trying to get started with dkim-rotate, but I hit an error during
> > initial provisioning with --new. I use knot for auth DNS so I don't
> > have the rndc, hence I tried to override dns_reload in the config.
>
> Thanks for the report. I'm sorry it didn't work as expected.
>
> > $ sudo dkim-rotate --status dkim
> > dkim-rotate: instance dkim: error: state corrupted!
> > /var/lib/dkim-rotate/dkim/state:5: bad key line
>
> I have reproduced this and will fix it. I agree that this is a
> serious bug and I will try to get it fixed in a stable update.
>
> I'm afraid I don't have a clear workaround for you right now but I
> will send you one as soon as I do.
After fixing the config it does go through successfully so no workaround is
really needed. I just had to wipe the state first.
> > Seems a bit of a usability problem for new users. I'd recommend not
> > commenting out directives in the example config without an
> > explaination
>
> Yes. I may change the syntax too to remove the `;` from the SERIAL,
> but that's not entirely trivial since I would want it to be backward
> compatible.
I don't think it's entirely necessary to do that. Just have to take care to
provide new users with an example that doesn't have this ambiguity. FYI:
You might also want to include an example config in the .7 manpage. I found
having to dig through the Debian package to find one a bit inconvenient ;)
Thanks,
--Daniel
signature.asc
Description: PGP signature
Bug#1064452: dkim-rotate: Errors during --new leave state corrupted
Package: dkim-rotate Version: 0.4 Severity: important X-Debbugs-Cc: d...@darkboxed.org Hi Ian, I'm trying to get started with dkim-rotate, but I hit an error during initial provisioning with --new. I use knot for auth DNS so I don't have the rndc, hence I tried to override dns_reload in the config. The example config at /usr/share/doc/dkim-rotate/examples/example.zone has ;! mta_group - so I copied that syntax for the dns_reload directive but it was ineffective. Looking at the docs/code I figured out the prefix is supposed to be just an exclamation mark. Honestly this is not very intuitive because 1) the example config has it and 2) the SERIAL directive also uses ';!'. Example understandability aside with the broken config the resulting error left the state file corrupted. Running --new (without rndc installed) I get: $ dkim-rotate --new dkim dkim - +Xreveal? no key dkim - +Ndeadvertise? no key dkim - -1advance/use? no key dkim l -1 generated. sh: 1: rndc: not found dkim-rotate: instance dkim: error: subprocess (DNS reload (rndc reload >/dev/null)) failed, exit status 127 Subsequent calls (say --status or --reinstall) will throw a state corrupted errors: $ sudo dkim-rotate --status dkim dkim-rotate: instance dkim: error: state corrupted! /var/lib/dkim-rotate/dkim/state:5: bad key line Looking at the state file the problem seems to be the 'DNS,MTA' bit in the key line which isn't handled by read_config: sel_offset 11 sel_limit 12 last_serial 2 status -1 key l DNS,MTA 797b760fd46ee2e01eb6c959ff3060af v=DKIM1; h=sha256; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxzPdpwjhd+tnMooAWxEYAhVKPI2qHKGRwXpwfSEdaijUPKchNpM79HVB1+FKDmSlFR6w30qbPAdyzl4m/+Txzmv2J/So3jJbqmlSFfN85zXJ3uIdgfePWkHWTP2DAEYDeOsc3nbDNVDHQeoJHQrVyN5tBXQ/eaNTrg6qBzE5Qc1nC+Cd0LE4T9vd9PwZSSoRhYH2yprsEtLVvI+zSDqtDbx3QWAMUvDIILiWi5J/46Qw3/hI04gAFpimSoL9YVmkCNWr+arTA4g5jZatahlzkOOmNnMXZdgSRxVByAp5RtQr8EVEG0jV31re3cgXVwJnqvcJvJzDCzS6+caGjYmpQIDAQAB status +0 status +N status +X Seems a bit of a usability problem for new users. I'd recommend not commenting out directives in the example config without an explaination and handling the intermediate DNS,MTA key state properly even outside of key generation. Thanks, --Daniel -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkim-rotate depends on: ii bash 5.2.15-2+b2 ii libgetopt-long-descriptive-perl 0.111-1 ii libmime-tools-perl 5.510-1 ii openssl 3.0.11-1~deb12u2 ii perl 5.36.0-7+deb12u1 Versions of packages dkim-rotate recommends: ii curl 7.88.1-10+deb12u5 ii moreutils 0.67-1 dkim-rotate suggests no packages. -- no debconf information
Bug#1055214: bookworm-pu: package fpga-icestorm/0~20220915gita545498-3
Hi Jonathan, On Wed, Feb 21, 2024 at 07:50:02AM +, Jonathan Wiltshire wrote: > On Thu, Nov 02, 2023 at 11:36:23AM +0100, Daniel Gröber wrote: > > [ Reason ] > > Andras Pal reported fpga-icestorm's "icebram" utility being broken in > > stable (#1055171) due to incompatible changes to yosys's output. > > Please go ahead. Done. This is my first stable update so I hope I got it right :) Lintian was complaining about E: fpga-icestorm changes: bad-distribution-in-changes-file bookworm but devref says > uploads for other supported suites should use the suite codenames, as > they avoid any ambiguity. So I'm not sure whats going on there. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1064274: bsd-mailx: Uses hardcoded /usr/sbin/sendmail path
Package: bsd-mailx Version: 8.1.2-0.20220412cvs-1 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Robert, your bsd-mailx package hardcodes sendmail to be at /usr/sbin/sendmail by default (see 02-Base-fixes-1.patch). I found myself needing to override sendmail systemwide due to an esoteric setup ask for details at your own peril ;) I found mailx will keep using /usr/sbin/sendmal despite me overriding it at /usr/local/sbin/sendmail (which comes first in $PATH). I wonder do we need to use absolute paths here? Wouldn't #define _PATH_SENDMAIL "sendmail work just as well? Thanks, --Daniel -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bsd-mailx depends on: ii exim4-daemon-heavy [mail-transport-agent] 4.96-15+deb12u4 ii libbsd00.11.7-2 ii libc6 2.36-9+deb12u4 ii liblockfile1 1.17-1+b1 bsd-mailx recommends no packages. bsd-mailx suggests no packages. -- no debconf information
Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux
noowner 1041858 thanks I've decided to focus on upstreaming a kernel based SIIT/NAT64 solution instead of packaging tundra. Initial packaging work is here if anyone wants to continue this anyhow: https://salsa.debian.org/dxld/tundra-nat64 Upstream issue asking for tagging release https://github.com/vitlabuda/tundra-nat64/issues/1 Patches: https://github.com/vitlabuda/tundra-nat64/pull/2 - adding a Makefile https://github.com/vitlabuda/tundra-nat64/pull/4 - hardening --Daniel signature.asc Description: PGP signature
Bug#988127: neomutt hangs for minutes while checking S/MIME signed mails
Hi all,
I've done some code review to figure out what we can do to
workaround/fix this issue since it has annoyed me in the past and I
just don't even want to use S/MIME ever really.
Some things I found: since I set crypt_use_gpgme=yes gpgme apparently
handles S/MIME directly (didn't know gpg supported it) and the
"backend" is /usr/bin/gpgsm.
So a very nasty hack is to get rid of this issue is to just symlink
gpgsm to /usr/bin/false somewhere on your $PATH:
# ln -s /usr/bin/false gpgsm
Looking at the code I found the original sin to be at
ncrypt/cryptglue.c:crypt_init:
#ifdef CRYPT_BACKEND_GPGME
if (c_crypt_use_gpgme)
{
crypto_module_register();
crypto_module_register();
}
#endif
this makes it so crypt_use_gpgme=yes enables both gpg and smime
support with no way to disable smime at init or message verification
time. Not even hooks will help since the crypt module registration
runs only once.
IMO this is unacceptable as I have no interest in being exposed to the
vulnerability surface area of smime despite not having any use for it,
so I'm planning to propose a patch to neomutt to move the smime
registration to a seperate rc variable.
Does anybody think the ability to toggle this per-message would be
useful? I can't think of a compelling reason to want that.
--Daniel
signature.asc
Description: PGP signature
Bug#1061314: RFS: vnstat/2.12-1 -- console-based network traffic monitor
Hi Christian, I'd be happy to sponsor vnstat (as soon as my NM process propagates through the bueraucracy). In the meantime I've had a look at the packaging and I have no notes :) I'll try to remember to upload vnstat but since it might be a while still until my key is accepted by ftp-master feel free to ping if I forget. --Daniel On Mon, Jan 22, 2024 at 03:25:52PM +0100, Christian Göttsche wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "vnstat": > > * Package name : vnstat >Version : 2.12-1 >Upstream contact : Teemu Toivola > * URL : https://humdi.net/vnstat/ > * License : GPL-2, GPL-any > * Vcs : https://salsa.debian.org/debian/vnstat >Section : net > > The source builds the following binary packages: > > vnstat - console-based network traffic monitor > vnstati - image output support for vnStat > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/vnstat/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.12-1.dsc > > Changes since the last upload: > > vnstat (2.12-1) unstable; urgency=medium > . >* New upstream version 2.12 > . >* d/patches: rebase and drop upstream applied one >* d/copyright: bump years > > Regards, >Christian Göttsche > signature.asc Description: PGP signature
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
On Wed, Dec 13, 2023 at 07:24:49PM +, Holger Levsen wrote: > On Wed, Dec 13, 2023 at 07:04:01PM +0100, Daniel Gröber wrote: > > That's fine, but in that case this fact should be documented instead no? > > Right now there's confusion across the docs what criticality levels are > > available. Britney.conf and d-policy mention critical/emergency but nothing > > else even acknowledges they exist which is just confusing. > > I believe Debian policy should be changed then and not mention a severity > which is not used in practice. Easier said than done. I see debian-policy@d.o is already CCed on this bug so, opinions? Doesn't policy document the reality that these urgency values are in fact usable? Do you not agree that britney does in fact support these? If I go ahead and upload a package with urgency=critical will this be REJECTed by ftp-master? If not they exist so why shouldn't they be documented in devref? --Daniel signature.asc Description: PGP signature
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
Hi Holger, On Wed, Dec 13, 2023 at 02:19:14PM +, Holger Levsen wrote: > On Wed, Dec 13, 2023 at 01:55:21PM +0100, Daniel Gröber wrote: > > > 6.3.2. Selecting the upload urgency > > mentions only high, medum and low urgency values. Britney also > > supports critical and emergency. These should be documented as well. > > thanks for filing this bug report, even with a patch, basically! > > I'm sorry I still closing this as documenting those severities has no > practical benefit, and in fact might confuse people thinking using those > severities would be encouraged or useful, which is both not the case. That's fine, but in that case this fact should be documented instead no? Right now there's confusion across the docs what criticality levels are available. Britney.conf and d-policy mention critical/emergency but nothing else even acknowledges they exist which is just confusing. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness
Source: developers-reference Severity: normal Hi, > 6.3.2. Selecting the upload urgency mentions only high, medum and low urgency values. Britney also supports critical and emergency. These should be documented as well. Something like: - The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low). + The delays are currently 0, 2, 5 or 10 days, depending on the urgency: critical/emergency, high, medium or low respectively. Where emergency is simply an alias for critical. Thanks, --Daniel
Bug#1057384: openresolv: Please don't change resolv.conf when it's a symlink
On Mon, Dec 04, 2023 at 11:41:57AM +0100, Daniel Gröber wrote: > This is similar to how networkmanager and systemd-resolvd handle > ownership conflicts and following this protocol will ensure only one > (or none in my case :) managment system will try to change > resolv.conf. Additional datapoint the old resolvconf package also follows this protocol. It prints a warning and doesn't touch resolv.conf: # resolvconf -u /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf It does however have logic in it's postinst to overwrite /etc/resolv.conf with it's symlink on installation. --Daniel signature.asc Description: PGP signature
Bug#1057387: openresolv: Garbles nameserver address for no apparent reason
Control: retitle 1057387 openresolv: Uses stale nameserver info from resolv.conf.bak Hi, On Mon, Dec 04, 2023 at 11:57:05AM +0100, Daniel Gröber wrote: > now 2001:678:4d8::1 used to be a valid address for my resolver but > isn't anymore, but I can't for the life of me figure where openresolv > would be getting this from? After remembering strace exists I found it's taking this from /etc/resolv.conf.bak after deleting this it now "only" overwrites my resolv.conf with an empty file ... I have some questions: 1) Why is .bak being merged into resol.conf? This seems ripe for desaster. 2) Why overwrite a perfectly good resolv.conf with an empty one? Thanks, --Daniel signature.asc Description: PGP signature
Bug#1057387: openresolv: Garbles nameserver address for no apparent reason
Package: openresolv Version: 3.12.0-3 Severity: important X-Debbugs-Cc: d...@darkboxed.org Hi Fabio, nothing on my system feeds resolvconf any data: $ find /run/resolvconf/ /run/resolvconf/ /run/resolvconf/metrics /run/resolvconf/interfaces /run/resolvconf/interfaces/lo.unbound (lo.unbound is empty) yet when I run `resolvconf -u` (which also seems to happen during system boot) it garbles my hand maintained resolv.conf: domain clients.dxld.at nameserver 2001:678:4d8:acdd::1 turns into: domain clients.dxld.at nameserver 2001:678:4d8::1 now 2001:678:4d8::1 used to be a valid address for my resolver but isn't anymore, but I can't for the life of me figure where openresolv would be getting this from? Thanks, --Daniel -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1057384: openresolv: Please don't change resolv.conf when it's a symlink
Package: openresolv Version: 3.12.0-3 Severity: important X-Debbugs-Cc: d...@darkboxed.org Hi Fabio, I manage my resolv.conf by hand and as such I don't want to excercise any daemons messing with it :) I've noticed that openresolv seems to (non-atomically) overwrite /etc/resolv.conf as the file my symlink is pointing to is getting overwritten. For one this shouldn't happen if a proper atomic rename is done but ideally when resolv.conf is a symlink to a path not owned by your package it should not touch it at all. This is similar to how networkmanager and systemd-resolvd handle ownership conflicts and following this protocol will ensure only one (or none in my case :) managment system will try to change resolv.conf. Thanks, --Daniel -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2
Hi Lucas, On Thu, Oct 26, 2023 at 09:45:53AM +0200, Lucas Nussbaum wrote: > As an additional data point, I can still reproduce this. > I cannot provide the buildinfo, as sbuild outputs it at the end of > successful builds. Doh! Didn't think of that. Something to improve in sbuild I guess :) > However, in the build log there's the list of installed packages, which > might be sufficient... Since I've sucessfully rebuilt yosys agains unstable and it's still failing for you it's pretty much moot. I just thought you'd have the buildinfos at hand. I'm essentially waiting for make 4.4 to make it into Debian as Santiago pointed out it may help track this down, but if I can't repro this (and I have still never seen this) there's not much I can do without access to a system this repros on. If you can reliably reproduce this could you try doing a -j1 rebuild? That should at least tell us if it's a concurrency issue or not. --Daniel signature.asc Description: PGP signature
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Peter,
> So now we move to VLAN level?
Yeah, but I'm still waiting for the answers to my questions from two emails
ago:
> I'd be happy to still track this bug down but I need you to investigate
> the behaviour in your environment. If you've torn down the lab already we
> can also just call it quits.
>
> If you do want to continue some questions are still pending, see quoted below.
>
> > On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > > 1) As was reported, foreign external world MAC@ does not pass into
> > > network namespace, just external border point "vlan199"
> >
> > How did you check this?
> >
> > > 2) now collecting data for you, honestly I don’t see external mac
> > > address on "inet-br" object, so my previous statement was incorrect..
> > > {ossibly I might mixed this up with another "labinet-br" (working in
> > > its limited
> > > scope) which is IP-defined, while "inet-br" in question is not.
> > >
> > > 3) so question is, if the MACs learnt via vlan199 are supposed to be
> > > paired (displayed) with "inet-br" object and all way up into NS
> >
> > I want to make sure we're on the same page, how do you check if the MAC
> > is reaching into the NS? I assume using `ip neigh`? I'd have a look at
> > tcpdump this will tell you whether ARP is even reaching the NS or not.
> >
> > Something simple like
> >
> > $ tcpdump -enli $IFACE 'arp or icmp'
> >
> > optionally you can filter by MAC (`ether host` in pcap-filter speak):
> >
> > $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> > aa:00:00:00:00:01
> >
> > Oh and one last thing: please double and tripple check that a firewall
> > isn't interfering.
--Daniel
signature.asc
Description: PGP signature
Bug#916475: [Pkg-electronics-devel] Bug#916475: ghdl: various suggestions to simplify the packaging
Hi Nicolas,
I've finally pushed your patches through to salsa after build testing and
verifying the resulting binary packages packages are equivalent using
debdiff. Differences are seem to come down to to dependency versions
changing:
```
$ debdiff ../ghdl_3.0.0+dfsg2-1_amd64.changes
../from-archive/ghdl_3.0.0+dfsg2-1_amd64.changes
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root
/usr/lib/debug/.build-id/4f/d46ef61c57d68aabc9d4cdafc5852fb899051f.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/5f/360efc6c03c7585caf925bcbea6ad8163e0b84.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/67/03f8ecaace7be7ad9c4e1c76f79f60299eb5e1.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/83/8101776d4af339a5fdbc155750b25513d70c5e.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/88/259f50a0d6125260020aed22e69837a1418d9f.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/97/1167de6d6502682678be2557a3f037fdb9a299.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/98/4a150aedbac5ecc98964a654c1f32c1a669fab.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/9d/6731573091925ccd801408416af337fb2def67.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/9f/a6e677d86433c0c55a1b305db2d5107dbbd3e3.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/af/15744ce92590cba9bf6e5f2ac3f6abdaa356d1.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/af/f5a7ca2cc39dab5444187a8ff8230d44a1f09c.debug
Files in first .changes but not in second
-
-rw-r--r-- root/root
/usr/lib/debug/.build-id/05/67e87b4f827133b5a5e6dbc1de66873eed152f.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/25/8b5853f5fb49bd900ae137b0f3ad679494d6dd.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/39/61a65390c7ff8e603734a17eea5cd8b380aa35.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/5b/560130ca4bf4ecc153a867be2c51658368f6d0.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/62/c278ed0eca6c59573e4767ed867ff9d29d7814.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/9e/a63af44bc20979afdfeac844d7878f40e35269.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/a3/e0033ddba6d7e4b75ea67608c7fbcb823f9b6d.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/a8/159ae681c2031121f3e2f41699688f4dd92510.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/b1/a96219303a0a3b5c13e3db6ee6f968282b84b9.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/b9/4ba16cde9f1c4664e87cc233027d76500603d8.debug
-rw-r--r-- root/root
/usr/lib/debug/.build-id/e1/362da76f0e7263f7173a9376c7363f9c723009.debug
No differences were encountered between the control files of package ghdl
No differences were encountered between the control files of package ghdl-common
Control files of package ghdl-gcc: lines which differ (wdiff format)
Built-Using: gcc-12 (= [-12.3.0-11)-] {+12.3.0-9)+}
Depends: ghdl-common (= 3.0.0+dfsg2-1), libc6 (>= 2.36), libgmp10 (>=
2:6.3.0+dfsg), libgnat-12 (>= 12.3.0), libisl23 (>= 0.15), libmpc3 (>= 1.1.0),
libmpfr6 (>= 3.1.3), [-libzstd1 (>= 1.5.5),-] zlib1g (>= 1:1.1.4), gcc,
zlib1g-dev
Control files of package ghdl-gcc-dbgsym: lines which differ (wdiff format)
---
Build-Ids: [-0567e87b4f827133b5a5e6dbc1de66873eed152f
3961a65390c7ff8e603734a17eea5cd8b380aa35
62c278ed0eca6c59573e4767ed867ff9d29d7814
9ea63af44bc20979afdfeac844d7878f40e35269-]
{+4fd46ef61c57d68aabc9d4cdafc5852fb899051f
5f360efc6c03c7585caf925bcbea6ad8163e0b84
838101776d4af339a5fdbc155750b25513d70c5e
aff5a7ca2cc39dab5444187a8ff8230d44a1f09c+}
Installed-Size: [-102822-] {+102828+}
No differences were encountered between the control files of package ghdl-llvm
Control files of package ghdl-llvm-dbgsym: lines which differ (wdiff format)
Build-Ids: [-b1a96219303a0a3b5c13e3db6ee6f968282b84b9
b94ba16cde9f1c4664e87cc233027d76500603d8
e1362da76f0e7263f7173a9376c7363f9c723009-]
{+6703f8ecaace7be7ad9c4e1c76f79f60299eb5e1
88259f50a0d6125260020aed22e69837a1418d9f
984a150aedbac5ecc98964a654c1f32c1a669fab+}
No differences were encountered between the control files of package ghdl-mcode
Control files of package ghdl-mcode-dbgsym: lines which differ (wdiff format)
-
Build-Ids: [-258b5853f5fb49bd900ae137b0f3ad679494d6dd
a8159ae681c2031121f3e2f41699688f4dd92510-]
{+9fa6e677d86433c0c55a1b305db2d5107dbbd3e3
af15744ce92590cba9bf6e5f2ac3f6abdaa356d1+}
No differences were encountered between the control files of package ghdl-tools
Control files of package ghdl-tools-dbgsym: lines which differ (wdiff format)
Bug#1054124: dh-ada-library: dh_ada_library output causes /usr/share/ada/packaging.mk:81: *** missing separator error
Hi Nicolas, On Tue, Oct 17, 2023 at 03:17:49PM +0200, Daniel Gröber wrote: > on my bookworm system importing dh-ada-library's packaging.mk is > causing a make error. AFAICT due to `dh_ada_library --export-versions` > including some copyright output in DEB_GNAT_VERSION: This bug is still blocking my work on ghdl, did you have a chance to look into it? Looking at the code: my $deb_gnat_version = `gnatmake --version` or error $!; $deb_gnat_version =~ s/[^\n]* (\d+)\.\d+\.\d+\n.*/$1/s; I don't really know perl but my understanding is that =~ is only a match predicate and doesn't do any replacement. Since the regex below uses a capture group without using the resulting $1 I wonder if what's missing is `$deb_gnat_version = $1`? I don't really see how this could have ever worked tho so I'm still perplexxed how ada/packaging.mk managed to not blow up previously unless gnatmake output changed? Thanks, --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Hi Martin, On Fri, Nov 24, 2023 at 09:54:30PM +0200, Martin-Éric Racine wrote: > > Looking the last your three dhcpcd revisions I wonder if you shouldn't be > > debugging these fundamental build issues on a porterbox or in a VM rather > > than through the buildds? > > I don't have access to the former and am not in a position to setup the > later. You can request access to a porterbox pretty easily, but that's only really going to help with the FTBFS part, not with testing DHCP functionality for real as that requires root which is not available on porterboxes AFAIK. I'm not very familiar with the hurd port myself, but a quick search found some pre-prepared QEMU/KVM images for hurd (with docs!) here: https://cdimage.debian.org/cdimage/ports/12.0/hurd-i386/README those should be easy enough to use. > Anyhow, doing this via the buildd has the advantage of ensuring that I > don't break anything for existing ports. I don't think this is a good use of your time (or your sponsors'!). The cyle time is just too long, please consider developing in a VM and uploading once you get it working. You should likely submit your porting changes upstream for review before even integrating them into Debian though as I expect they'll be substantial as they amount to supporting a new OS. I'm following the dhcpcd project so I'll likely review your PR(s) anyway. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
On Fri, Nov 24, 2023 at 09:03:37PM +0200, Martin-Éric Racine wrote: > On Fri, Nov 24, 2023 at 8:59 PM Daniel Gröber wrote: > > On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > > > dhcpcd (1:10.0.5-4) unstable; urgency=medium > > > . > > >* Attempt to fix the GNU/Hurd build. > > > + 003_fix_FTBFS_on_Hurd.patch > > > > Does upstream even support hurd? Looking at ./configure: > > > > gnu*) OS=hurd;; # No HURD support as yet > > Upstream never attempted to support it. I am. Looking the last your three dhcpcd revisions I wonder if you shouldn't be debugging these fundamental build issues on a porterbox or in a VM rather than through the buildds? --Daniel signature.asc Description: PGP signature
Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client
Hi Martin, On Fri, Nov 24, 2023 at 06:55:44PM +0200, Martin-Éric Racine wrote: > dhcpcd (1:10.0.5-4) unstable; urgency=medium > . >* Attempt to fix the GNU/Hurd build. > + 003_fix_FTBFS_on_Hurd.patch Does upstream even support hurd? Looking at ./configure: gnu*) OS=hurd;; # No HURD support as yet doesn't look promising. --Daniel signature.asc Description: PGP signature
Bug#1056631: unbound: Please package 1.19.0 release for DNS64 improvements
Source: unbound Severity: wishlist Tags: ipv6 X-Debbugs-Cc: d...@darkboxed.org, debian-i...@lists.debian.org Hi Michael, unbound 1.19.0 includes a small patch of mine aimed at allowing people stuck behind IPv4-only ISPs to still deploy monostack-IPv6 (using v6 tunneling and NAT64) without getting hit by the downsides of tunneled IPv6 internet access. I'd appreciate it if you could package it :) Thanks, --Daniel
Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm
Hi Nicolas, On Sat, Nov 18, 2023 at 06:27:42PM +0100, Nicolas Boulenguez wrote: > Have you seen this? > https://lists.debian.org/debian-devel/2023/08/ What exactly are you referring to? That's the whole month's archive :) Yes I do read d-devel so I've likely seen whatever you're pointing to :p > > I've been toying with the idea of setting up a Debian-wide system to nag > > maintainers about out-of-date, inconsistent or plain broken packaging git > > repos. This logic to diff the dsc against one built from unstable could be > > part of that effort. > > Some will probably argue that you are trying to influence their > priorities, that non-git .dsc formats are obsolete, and so on. And that's a bad thing because ... ? There's a huge difference between nudging and forcing :) > Moreover, even if you guess the git tag and whether patches are > applied, there is probably no deterministic way to tell if .gitignore > matches the workflow of upstream, Debian or both. Sounds like a job for a new config option in debian/source/ or similar, this is conceptually no different than lintian false-positives. As long as there's a way to override I don't see a problem. > For the avoidance of doubt, I would appreciate such alerts, a Debian > policy about tags and patches, and that .gitignore is only allowed for > self defense... I for sure don't have all this thought yet, I'm happy to collaborate on designing this system if you're interested. BTW: are you at ccc congress? > > Even with git what may be missing is a hook in dpkg-buildpackage to abort > > the (source) build when the worktree is unclean, > > I often build with manual changes in debian/ that I want tested before > committed. Right yeah same. So that wouldn't really help. gbp's --git-ignore-new is already annoying me enough :) > The script I am using is too lazy for public exposure. You can always send me those shameful scripts directly, I don't judge.sh. > Here are the parts unrelated with pbuilder. > > # After a successful build, clean and compare the source directory > # with the contents extracted by dpkg-source. > # The diff must match debian/clean.diff if it exists, else be empty. > # Example: > # Only in ../dsc: Makefile.in > # Only in ../dsc: config.h > # Only in ../dsc: configure > # If lots of files are removed, repackaging with Files-Excluded is > # probably a better option, see uscan(1). > > #!/bin/sh > set -Ceux > > source=$(dpkg-parsechangelog -SSource) > version=$(dpkg-parsechangelog -SVersion) > dsc_dir=../dsc > > debian/rules clean > dpkg-source -x ../$source_$version.dsc $dsc_dir > if ! (diff -qr $dsc_dir . || true) | diff -N debian/clean.diff -; then > # Display a full diagnostic while $dsc_dir is available. > diff -ru $dsc_dir . || true > # When -ru is empty, -N above already reported the obsolete clean.diff. > fi > rm -fr $dsc_dir I see, this is actually really clever. I don't see why we couldn't do this diff on the buildds to get reporting for this Debian wide. I've been meaning to give sbuild some love anyhow. --Daniel signature.asc Description: PGP signature
Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm
Hi Nicolas, Sorry for taking so long to get back to you I've had some family issues to deal with. On Thu, Oct 19, 2023 at 12:42:18PM +0200, Nicolas Boulenguez wrote: > > would it be possible to get dh-builtusing backported for bookworm? We > > want to use dh-builtusing in ghdl (as you know ;), but I run my > > package builds on bookworm, inside an sbuild chroot, so gbp breaks > > when building the source package it's going to hand to the chroot. > > Please first consider a simple solution that I have been using for > years. > > Dpkg-buildpackage --build=source (run by $tool) cleans the source tree > before preparing the .dsc (that $tool then copies into the chroot). Incidentally, I've done some light code review of dpkg-dev a while ago. I was looking at how/when patches are applied/unapplied but the cleaning logic is close by. > The motivation for the cleaning was probably to prevent objects > embedded into the .dsc, but I think it might also be related to the automatic patch generation some source formats support. From that perspective: if you don't clean up before building the dsc the generated patch could contain build cruft. Of course there's extend-diff-ignore to prevent this so I'm not entirely sure this tracks. > * dpkg-buildpackage now (source format 3.0) aborts when it detects a > file present in the source tree but missing or different in the > .orig tarball I had this same throught "why can't we just disable pre-clean for 3.0 (quilt)" but that's forgetting about debian/. Build products end up there so we need to clean those up or we could include build cruft in the dsc and potentially change the behaviour of the build that way. > The clean step may even be harmful. > * It requires build dependencies outside the chroot >(your issue with dh-builtusing). > * Even if these are installed, the versions and behaviour may differ. >(probable cause of your issue with dh-ada-library) I suppose in theory this behavioural difference could reflect in the dsc content. I don't think that's a really a huge problem, it's just another of a number of reasons why a dsc freshly built from packaging git may differ from whats in the archive. I kind of see this (source) build diversity to be a good thing. It means I'm going to encounter (and fix) issues users doing their own ghetto backports (like I used to ;) are going to encounter. Perhaps it would be worthwhile to setup some system (salsa CI?) to detect this case tho. I've been toying with the idea of setting up a Debian-wide system to nag maintainers about out-of-date, inconsistent or plain broken packaging git repos. This logic to diff the dsc against one built from unstable could be part of that effort. > * The upstream clean process may execute surprising commands like > find . -name '*~' -delete > git reset --hard >or make applied debian/patches hard to revert. > * Various packages require incompatible Build-Dependencies. > * ... > > You can disable the clean with > # dpkg-buildpackage -nc > # pdebuild --debbuildopts -nc > or a similar gbp-buildpackage option. I enabled this on my workstation by way of $ echo no-pre-clean > ~/.config/dpkg/buildpackage.conf and after using it for a while I can't say I enjoy it or consider it safe. It's wayyy too easy to forget to clean this way. Even with git what may be missing is a hook in dpkg-buildpackage to abort the (source) build when the worktree is unclean, but even then I'm not sure gbp export-orig will apply debian/.gitignore if it exists, which could be another pitfall. > In case you want to keep a basic check of the clean target, the right > place is a pbuilder script cleaning inside the chroot after the build, > then reporting any difference between the source and the .dsc. > The output is almost always either > * trivial to work-around in Debian >(echo '*.o' > debian/clean) >(fixing upstream may be another story) > * short enough to be easily ignored >(./configure), > * or a real issue. I never really used pbuilder, I went straight to sbuild so I'm not sure what this setup would look like, could you elaborate or show an example? --Daniel signature.asc Description: PGP signature
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Peter,
On Mon, Nov 13, 2023 at 09:40:46AM +, peter.gasparo...@orange.com wrote:
> In the meantime, I was stubborn to find a solution to what I need in
> order to progress and MACVLAN tech actually delivered it (private mode
> enough),
I used to love macvlan too but now I do L3 instead ;P
> something newer than VETH tech what I could read about, and it's
> just perfect avoiding bridge itself. So no problem to cooperate on this
> fix, I will be glad, just it can get lower priority on your side if you
> even attributed it some
I'd be happy to still track this bug down but I need you to investigate the
behaviour in your environment. If you've torn down the lab already we can
also just call it quits.
If you do want to continue some questions are still pending, see quoted below.
> On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > 1) As was reported, foreign external world MAC@ does not pass into
> > network namespace, just external border point "vlan199"
>
> How did you check this?
>
> > 2) now collecting data for you, honestly I don’t see external mac
> > address on "inet-br" object, so my previous statement was incorrect..
> > {ossibly I might mixed this up with another "labinet-br" (working in
> > its limited
> > scope) which is IP-defined, while "inet-br" in question is not.
> >
> > 3) so question is, if the MACs learnt via vlan199 are supposed to be
> > paired (displayed) with "inet-br" object and all way up into NS
>
> I want to make sure we're on the same page, how do you check if the MAC is
> reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
> this will tell you whether ARP is even reaching the NS or not.
>
> Something simple like
>
> $ tcpdump -enli $IFACE 'arp or icmp'
>
> optionally you can filter by MAC (`ether host` in pcap-filter speak):
>
> $ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
>
> Oh and one last thing: please double and tripple check that a firewall isn't
> interfering.
--Daniel
signature.asc
Description: PGP signature
Bug#1040393: msmtp: please reintroduce SetGID permission as an optional package
Hi Emannuel, Just a ping on this issue. I'd be happy to work on a patch and I intend to (get around to) preparing an NMU for this issue if you don't act on it. Thanks, --Daniel On Wed, Jul 05, 2023 at 01:10:58PM +0200, Daniel Gröber wrote: > I've just upgraded my workstation to Bookworm and the upgrade broke my > (outgoing) mail setup where I'm using msmtp due to permission errors > involving files owned by msmtp:msmtp. I see from your NEWS entry that > SetGID support was removed because it conflicts with passwords > retrieved through libsecret. > > Problem is in my deployment I'm not using passwords but rather TLS > client certificates, which AFAICT the libsecret integration simply > does not support so I cannot migrate my config to the non-setgid > msmtp. > > I'd like to request a new package, say msmtp-sysconfig, that will make > /usr/bin/msmtp setgid again on installation. I'd be happy to provide a > patch if you agree this is a reasonable idea. > > Thanks, > --Daniel > > -- System Information: > Debian Release: 12.0 > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-security'), (500, > 'stable-debug'), (500, 'proposed-updates-debug') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages msmtp depends on: > ii adduser3.134 > ii debconf [debconf-2.0] 1.5.82 > ii libc6 2.36-9 > ii libgnutls303.7.9-2 > ii libgsasl18 2.2.0-1 > ii libsecret-1-0 0.20.5-3 > ii ucf3.0043+nmu1 > > Versions of packages msmtp recommends: > ii ca-certificates 20230311 > > Versions of packages msmtp suggests: > ii msmtp-mta 1.8.23-1 > > -- debconf information excluded signature.asc Description: PGP signature
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Peter,
looking at the ip/bridge dumps I don't see anything obviously broken so I
started by building a reproducer using two netns'en and a bridge on the
host to simulate your setup, leaving out the vlan stuff for now.
I setup two namespaces ns0/ns1 with a veth pair each connected to br0 on
the host. I assign MAC addresses statically to make looking at `bridge fdb`
easier (grep ^aa:). The script looks like this (trimmed, full version
attached):
ip netns add ns0
ip link add veth0 type veth \
peer name veth0 address aa:00:00:00:00:00 netns ns0
ip netns add ns1
ip link add veth1 type veth \
peer name veth1 address aa:00:00:00:00:01 netns ns1
ip link add br0 address aa:bb:bb:bb:bb:bb type bridge forward_delay 0
#^ forward_delay=0 to disable STP as this delays interfaces coming up
ip link set dev veth0 master br0
ip link set dev veth1 master br0
ip -n ns0 addr add 10.0.0.100/24 dev veth0
ip -n ns1 addr add 10.0.0.101/24 dev veth1
iplink set br0 up
iplink set dev veth0 up
ip -n ns0 link set dev veth0 up
iplink set dev veth1 up
ip -n ns1 link set dev veth1 up
ip -n ns0 link set dev lo up
ip -n ns1 link set dev lo up
ip netns exec ns0 ping -c4 10.0.0.101
Seems to work fine. So we can establish the basic functionality does work
and we need to go deeper.
Peter, can you confirm this script works on your system? If so the next
step is introducing vlans.
On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> 1) As was reported, foreign external world MAC@ does not pass into
> network namespace, just external border point "vlan199"
How did you check this?
> 2) now collecting data for you, honestly I don’t see external mac address
> on "inet-br" object, so my previous statement was incorrect.. {ossibly I
> might mixed this up with another "labinet-br" (working in its limited
> scope) which is IP-defined, while "inet-br" in question is not.
>
> 3) so question is, if the MACs learnt via vlan199 are supposed to be
> paired (displayed) with "inet-br" object and all way up into NS
I want to make sure we're on the same page, how do you check if the MAC is
reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
this will tell you whether ARP is even reaching the NS or not.
Something simple like
$ tcpdump -enli $IFACE 'arp or icmp'
optionally you can filter by MAC (`ether host` in pcap-filter speak):
$ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
Oh and one last thing: please double and tripple check that a firewall
isn't interfering.
--Daniel
repro.sh
Description: Bourne shell script
signature.asc
Description: PGP signature
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge
On Thu, Nov 09, 2023 at 09:12:57PM +0100, Marco d'Itri wrote: > Duplicate of #1055413. Did you perhaps mean #1055066 (usrmerge: Cannot update to version 38 on sbuild) that one describes exactly the issue I was seeing. --Daniel signature.asc Description: PGP signature
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge)
On Fri, Nov 10, 2023 at 05:51:05PM +, Luca Boccassiwrote: > Please stop playing ping-pong with the bug tracker. It's already been > explained to you what you need to do. Luca, thanks your response. However I would appreciate it if we could just simply let a discussion come to a conclusion before slamming it shut on a whim. Doing so is just bad manners and doesn't contribute to making Debian better. Thanks. After some more poking I found /etc/unsupported-skip-usrmerge-conversion somhow got created in this chroot and removing it seems to have helped to allow usrmerge to be installed but I'm still not happy about the fact that manual intervention is needed here. I might have tracked down why/how this got created how to do better here but given the lack of tact displayed by the both of you I really just don't feel like it. Please do consider being a bit more friendly in the future, such short/harsh responses really aren't conducive to encouraging people to contribute to making Debian better for all of us. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge
Control: reopen 1055665 Hi Marco, On Fri, Nov 10, 2023 at 04:00:13PM +0100, Marco d'Itri wrote: > On Nov 10, Daniel Gröber wrote: > > > I can't say that it is. The other bug is about keeping an unmerged > > system. I'm trying to switch this chroot to *be* usr-merged but the problem > > is that installing usrmerge fails as usr-is-merged still errors and > > prevents installation of usrmerge. See bottom part of log in my initial > > report. > > No, same thing. You obviously have to make sure that usrmerge is > installed before you attemp to update usr-is-merged. Where is that obviousness documented? I find that highly counter-intutive. Do note that I didn't intentionally install usr-is-merged, this is a minimal build chroot we're talking about after all. It got pulled in by something: $ apt-cache rdepends usr-is-merged usr-is-merged Reverse Depends: dbus init-system-helpers usrmerge I have dbus=1.14.10-1 and init-system-helpers=1.65.2. I can't say I entirely understand the purpose of usr-is-merged other than to brick systems with unattended upgrades. Could you explain? Thanks, --Daniel signature.asc Description: PGP signature
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge
Control: reopen 1055665 Hi Marco, On Thu, Nov 09, 2023 at 09:12:57PM +0100, Marco d'Itri wrote: > Duplicate of #1055413. I can't say that it is. The other bug is about keeping an unmerged system. I'm trying to switch this chroot to *be* usr-merged but the problem is that installing usrmerge fails as usr-is-merged still errors and prevents installation of usrmerge. See bottom part of log in my initial report. Are users expected to perform usr-merging manually in this case? That can't be true. How is this upgrade supposed to work for (end) users once this gets released anyhow? This change would seems to brick upgrades for systems that are still unmerged, no? Thanks, --Daniel signature.asc Description: PGP signature
Bug#1055667: nextpnr: prevent testing migration when embedded chipdbs are out-of-date
Source: nextpnr Severity: wishlist X-Debbugs-Cc: d...@darkboxed.org s...@debian.org Note to self, we should find a way to prevent testing migration of FPGA description packages (fpga-icestorm/apycula/prjtrellis) when nexpnr still embeds older version in it's chipdb binpkgs. Autopkgtests in the decriptor packages that fail when this is the case would probably work. Any other ideas welcome. --Daniel
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge
Package: usr-is-merged Version: 38 Severity: important X-Debbugs-Cc: d...@darkboxed.org Hi Marco, usr-is-merged=38 errors out in my unstable chroot since it's not merged yet, but this error also seems to prevent installing usrmerge: ``` (unstable-amd64)root@Janet:~# apt-get full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libfile-find-rule-perl libnumber-compare-perl libtext-glob-perl Use 'apt autoremove' to remove them. The following packages will be upgraded: usr-is-merged 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/5504 B of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 11489 files and directories currently installed.) Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) (unstable-amd64)root@Janet:~# apt-get install usrmerge Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: usr-is-merged The following NEW packages will be installed: usrmerge The following packages will be upgraded: usr-is-merged 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/18.5 kB of archives. After this operation, 39.9 kB of additional disk space will be used. Do you want to continue? [Y/n] debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 11489 files and directories currently installed.) Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks, --Daniel
Bug#1055171: fpga-icestorm: icebram incompatible with yosys 0.23
Hi Andras, On Thu, Nov 02, 2023 at 08:44:31AM +0100, Andras Pal wrote: > sure, please find attached this simplistic example for this issue. Just > enter `make`. Under bullseye, it should print: > > Found and replaced 1 instances of the memory. > > Under bookworm, it prints: > > Found and replaced 0 instances of the memory. Yup, I can reproduce the issue. I've sent a request to the release team and uploaded the proposed fpga-icestorm=0~20230218gitd20a5e9-1~deb12u1 to my repo at https://dxld.at/localdebs/ (sources.list instructions within) please test. Note to self: the upstream discussion is at https://github.com/YosysHQ/icestorm/issues/301 https://github.com/YosysHQ/icestorm/pull/309 --Daniel signature.asc Description: PGP signature
Bug#1055214: bookworm-pu: package fpga-icestorm/0~20220915gita545498-3
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: fpga-icest...@packages.debian.org, d...@darkboxed.org Control: affects -1 + src:fpga-icestorm [ Reason ] Andras Pal reported fpga-icestorm's "icebram" utility being broken in stable (#1055171) due to incompatible changes to yosys's output. [ Impact ] Users will not be able to easily embed ROM images into their FPGA designs during or after netlist build. [ Tests ] I've tested the updated version against Andras' reproducer and confirmed it fixes the issue. [ Risks ] The risk of breakage is low, icebram is already broken in stable so a rewrite wont hurt. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] Upstream fixed this by rewriting the icebram utility as a major refactoring was needed to fix it. The version in unstable differs from the stable version in this respect and some minor hardware enablement additions in icebox. I belive simply updating the version in stable is warrented here. [ Other info ] Upstream discussion: https://github.com/YosysHQ/icestorm/issues/301 https://github.com/YosysHQ/icestorm/pull/309 --Daniel diff -Nru fpga-icestorm-0~20220915gita545498/debian/changelog fpga-icestorm-0~20230218gitd20a5e9/debian/changelog --- fpga-icestorm-0~20220915gita545498/debian/changelog 2022-11-16 23:51:42.0 +0100 +++ fpga-icestorm-0~20230218gitd20a5e9/debian/changelog 2023-11-02 11:10:26.0 +0100 @@ -1,3 +1,23 @@ +fpga-icestorm (0~20230218gitd20a5e9-1~deb12u1) bookworm; urgency=medium + + * Fix yosys incompatibility (Closes: #1055171) + + -- Daniel Gröber Thu, 02 Nov 2023 11:10:26 +0100 + +fpga-icestorm (0~20230218gitd20a5e9-1) unstable; urgency=medium + + * New upstream version 0~20230218gitd20a5e9 + + -- Daniel Gröber Tue, 13 Jun 2023 14:52:48 +0200 + +fpga-icestorm (0~20220915gita545498-4) unstable; urgency=medium + + * autopkgtest: Fix missing icetime command + * Refresh patches + * Add patch fixing up5k_rgb icetime failure + + -- Daniel Gröber Tue, 13 Jun 2023 11:56:01 +0200 + fpga-icestorm (0~20220915gita545498-3) unstable; urgency=medium * Fix autopkgtest, examples-compile now needs nextpnr diff -Nru fpga-icestorm-0~20220915gita545498/debian/patches/0003-Fix-examples-icemulti-all-target.patch fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0003-Fix-examples-icemulti-all-target.patch --- fpga-icestorm-0~20220915gita545498/debian/patches/0003-Fix-examples-icemulti-all-target.patch 2022-10-29 20:42:04.0 +0200 +++ fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0003-Fix-examples-icemulti-all-target.patch 2023-11-02 11:10:08.0 +0100 @@ -7,7 +7,7 @@ 1 file changed, 2 insertions(+) diff --git a/examples/icemulti/Makefile b/examples/icemulti/Makefile -index d8a8320..1e38f9c 100644 +index a7ce692..96b31e1 100644 --- a/examples/icemulti/Makefile +++ b/examples/icemulti/Makefile @@ -1,3 +1,5 @@ diff -Nru fpga-icestorm-0~20220915gita545498/debian/patches/0004-Fix-up5k_rgb-failing-timing-analysis.patch fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0004-Fix-up5k_rgb-failing-timing-analysis.patch --- fpga-icestorm-0~20220915gita545498/debian/patches/0004-Fix-up5k_rgb-failing-timing-analysis.patch 1970-01-01 01:00:00.0 +0100 +++ fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0004-Fix-up5k_rgb-failing-timing-analysis.patch 2023-11-02 11:10:08.0 +0100 @@ -0,0 +1,18 @@ +From: =?utf-8?q?Daniel_Gr=C3=B6ber?= +Date: Wed, 17 May 2023 21:09:31 +0200 +Subject: Fix up5k_rgb failing timing analysis + +--- + examples/up5k_rgb/rgb.pcf | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/examples/up5k_rgb/rgb.pcf b/examples/up5k_rgb/rgb.pcf +index 0954260..19a93d1 100644 +--- a/examples/up5k_rgb/rgb.pcf b/examples/up5k_rgb/rgb.pcf +@@ -1,3 +1,4 @@ + set_io RGB0 39 + set_io RGB1 40 + set_io RGB2 41 ++set_frequency clk 32 +\ No newline at end of file diff -Nru fpga-icestorm-0~20220915gita545498/debian/patches/0004-Remove-hard-coded-path-in-icebox_vlog.py.patch fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0004-Remove-hard-coded-path-in-icebox_vlog.py.patch --- fpga-icestorm-0~20220915gita545498/debian/patches/0004-Remove-hard-coded-path-in-icebox_vlog.py.patch 2022-03-27 16:45:36.0 +0200 +++ fpga-icestorm-0~20230218gitd20a5e9/debian/patches/0004-Remove-hard-coded-path-in-icebox_vlog.py.patch 2023-11-02 11:10:08.0 +0100 @@ -6,6 +6,8 @@ icebox/icebox_vlog.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) +diff --git a/icebox/icebox_vlog.py b/icebox/icebox_vlog.py +index 74ac3d3..9ba2e30 100755 --- a/icebox/icebox_vlog.py +++ b/icebox/icebox_vlog.py @@ -384,7 +384,7 @@ def seg_to_net(seg, default=None): diff -Nru fpga-
Bug#1055208: yosys-plugin-ghdl: missing dependency on ghdl-gcc
Source: yosys-plugin-ghdl Version: 0.0~git20230419.5b64ccf-1 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Dear me, yosys-plugin-ghdl should depend on ghdl-gcc as otherwise the std lib is missing. warning: ieee library directory '/usr/lib/ghdl/gcc/vhdl/ieee/v08/' not found error: cannot find "std" library We could do this directly in yosys-plugin-ghdl but adding the dependency to libhghdl may be more correct. --Daniel
Bug#1055171: fpga-icestorm: icebram incompatible with yosys 0.23
Package: fpga-icestorm Version: 0~20220915gita545498-3 X-Debbugs-Cc: Andras Pal Hi Andras, On Wed, Nov 01, 2023 at 04:52:25PM +0100, Andras Pal wrote: > I'm using the yosys/nextpnr/icestorm toolchain regularly under Debian and > after upgrading to bookworm i noted (after some debugging) that in some > cases yosys-0.23 tends to generate memory instances whose initialization > values cannot be replaced with the `icebram` utility in a similar way like > in the previous (and in the following) releases. Do you have a reproducer/example for this? I haven't had the need to use icebram in my projects yet so having a regression test in the package would be good. > By checking the source code on github, i found that `icebram` underwent a > significant refactoring, likely after freezing the bookworm release (i.e. > sometimes in between Sept '22 and Feb '23). And indeed, after manually > downloading installing the trixie version (20230218gitd20a5e9-1) of the > fpga-icestorm and fpga-icestrom-chipdb packages, the toolchain started to > work again as it is expected. > > Is it possible to backport this upgraded version of `icebram` to bookworm as > well in order to be compatible with the shipped yosys version? I don't know > what is the severity of this bug - it is indeed not a security issue, but > otherwise the packeges are broken in this sense. And it might be beneficial > for another users and projects as well. Sholdn't be a problem. There's two ways to go, either we find a (small) patch that fixes the issue in the version from stable or (with some negotiation with the release team) we get permission to upgrade the version in stable. --Daniel
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Peter, On Mon, Oct 30, 2023 at 10:43:39AM +, peter.gasparo...@orange.com wrote: > Would it be possible to join a Webex session setup by me to check this > out quickly? It's all lab environment. I don't think that would help with reproducing your environment in this case, besides I only offer synchronous debugging sessions for paid consulting engagements. > If not I will proceed per your instructions Please do. --Daniel
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Peter, On Fri, Oct 27, 2023 at 09:29:25AM +, peter.gasparo...@orange.com wrote: > No attempt at all? Then it's against your own rules I've read before > submitting this. I think Luca was a bit harsh here, I'd be happy to help debug this. From a first look it seems unlikely this is related to iproute2, smells more like a kernel issue to me, but either way we need a reproducer. So first step to move this forward is to put together a self contained set of instructions to reproduce the problem. Your original report is a bit sparse on context and details. If you don't feel up to compiling the reproducer script yourself you could start by showing us your system state using $ ip -d addr show # on the host and inside the NS if you could $ bridge -d link; bridge fdb snippets from /etc/network/interfaces or similar relevant config would help too. --Daniel signature.asc Description: PGP signature
Bug#1054620: bcachefs-tools: Issues in packaging and git repo
Source: bcachefs-tools Severity: minor X-Debbugs-Cc: d...@darkboxed.org Hi Jonathan, while building the bcachefs-tools package from git I noticed that there are a couple of problems: - gbp.conf doesn't disable pristine-tar but no pristine-tar branch is available, making gbp export-orig fail - debian/files was committed to the git repo when it shouldn't be. - The upstream version 24~really1.2 should likely have been s/~/+/ 24+really1.2. Currently it compares as less than what's in unstable "24". See https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly TBH it seems to me +really isn't appropriate here as it's never going to go away. You should use an epoch instead, after posting on d-devel obv. Thanks, --Daniel
Bug#1054613: bcachefs-tools: Please upload version 1.2
Package: src:bcachefs-tools Severity: wishlist Hi Jonathan, the bcachefs-tools version currently in unstable (0.)24-1 is almost a year old. I see that you pushed packaging for (24~really)1.2-1 to git some weeks ago, but it looks like you never uploaded the package? I'd appreciate an upload :) Thanks, --Daniel -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-bcachefs-2023-10-25 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=C, 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 Versions of packages bcachefs-tools depends on: ii libaio1 0.3.113-5 ii libblkid1 2.39.2-4 ii libc6 2.37-12 ii libkeyutils1 1.6.3-2 ii liblz4-1 1.9.4-1 ii libsodium23 1.0.18-1 ii liburcu8 0.14.0-2 ii libuuid1 2.39.2-4 ii libzstd1 1.5.5+dfsg2-2 ii zlib1g1:1.2.13.dfsg-3 Versions of packages bcachefs-tools recommends: ii initramfs-tools [linux-initramfs-tool] 0.142 bcachefs-tools suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps
On Wed, Oct 18, 2023 at 09:24:11PM +0200, László Böszörményi (GCS) wrote: > On Wed, Oct 18, 2023 at 5:45 PM Daniel Gröber wrote: > > dot appears to embed CreationDate in the pdf and this cannot be > > controlled with SOURCE_DATE_EPOCH. > Can you please test it with the Graphviz version 9.0 in experimental? > I don't expect it to be different, but I would like to be sure. Seems -Tpdf doesn't work for with 9.0 some reason, is a configure option for that missing perhaps?: $ SOURCE_DATE_EPOCH=60 dot -T pdf test.dot -o test.pdf Format: "pdf" not recognized. Use one of: canon cmap cmapx cmapx_np dot dot_json eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg json json0 mp pic plain plain-ext png pov ps ps2 svg svgz tk vrml wbmp xdot xdot1.2 xdot1.4 xdot_json --Daniel signature.asc Description: PGP signature
Bug#1054173: schroot: manpages mention bouncing mailinglist
Package: schroot Version: 1.6.13-3+b2 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Christoph, The schroot manages mention the buildd-tools-de...@lists.alioth.debian.org mailinglist all over the place, but it doesn't seem to exist anymore and mail bounces. Is there a new ML? If so please update the address in the documentation. Thanks, --Daniel
Bug#797781: schroot: /dev/shm line is commented out by default but it's required by a lot of stuff
Hi, I'd like to add here that I just ran into this in a different way. I do my development in profile=destkop chroots which are also missing the /dev/shm line in fstat like the default profile. In my case upstream was using faketime(1) to tame some unreproducibility, but this needs access to /dev/shm to function at all. Curiously the permissions of /dev/shm were such that only root could write there: (unstable-amd64-dekstop):~$ ls -ld /dev/shm drwxr-xr-x 2 root root 40 Oct 16 10:36 /dev/shm Adding the fstab line fixes this as tmpfs seems to set the mount point to mode 777. FYI: I build my sbuild and "desktop" chroots with sbuild-createchroot(8). --Daniel
Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps
Package: graphviz
Version: 2.42.2-7+b3
Severity: normal
X-Debbugs-Cc: d...@darkboxed.org
Hi Laszlo,
my package yosys uses `dot` as part of it's documentaion build, I've
been battling reproducibility issues in that part of the packaging for
a while now and I think I've finally tracked it down to a problem in
graphviz.
dot appears to embed CreationDate in the pdf and this cannot be
controlled with SOURCE_DATE_EPOCH.
Repro:
$ echo 'digraph { a -> b }' > test.dot
$ SOURCE_DATE_EPOCH=60 dot -Tpdf test.dot -o test.pdf
$ dumppdf -adt test.pdf 2>/dev/null | grep 'CreationDate' -A1
CreationDate
D:20231018173926+0200
Note: dumppdf is from python3-pdfminer.
Thanks,
--Daniel
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages graphviz depends on:
ii libann01.1.2+doc-9+b1
ii libc6 2.36-9+deb12u3
ii libcdt52.42.2-7+b3
ii libcgraph6 2.42.2-7+b3
ii libexpat1 2.5.0-1
ii libgcc-s1 12.2.0-14
ii libgd3 2.3.3-9
ii libglib2.0-0 2.74.6-2
ii libgts-0.7-5 0.7.6+darcs121130-5+b1
ii libgvc62.42.2-7+b3
ii libgvpr2 2.42.2-7+b3
ii liblab-gamut1 2.42.2-7+b3
ii libstdc++6 12.2.0-14
ii libx11-6 2:1.8.4-2+deb12u1
ii libxaw72:1.0.14-1
ii libxmu62:1.1.3-3
ii libxt6 1:1.2.1-1.1
Versions of packages graphviz recommends:
ii fonts-liberation2 2.1.5-1
Versions of packages graphviz suggests:
pn graphviz-doc
ii gsfonts 2:20200910-7
-- no debconf information
Bug#968683: wireguard-tools: missing dependency in wireguard-tools resolvconf - wg-quick up
Hi Mathias,
On Mon, Oct 16, 2023 at 09:33:14AM +0200, Mathias Behrle wrote:
> > What is your exact use-case? I assume it's for a desktop VPN, in which case
> > adding systemd-resolved support to wg-quick might be less
> > problematic.
>
> Yes, indeed my use case is a desktop VPN.
>
> FWIW both resolvconf and systemd-resolved broke immediately my DNS, while
> openresolv worked.
Right, so there's the real root-cause. I think we should take the time to
debug and fix your systemd-resolved problem instead of bypassing it.
In case you're not aware systemd-resolved has a resolvconf compatibility
interface[1] now, so this will actually fix your wg-quick problem too. We
should likely do a push to get all openresolv|resolvconf dependencies
updated to add systemd-resolvd across Debian.
[1]: https://github.com/systemd/systemd/issues/7202
Unlike openresolv/resolvconf systemd-resolved actually has a data/config
model that has the potential to work for all use-cases I'm aware of without
hacks, so as much as I lament relying on yet another thing from under the
systemd umbrella it's the only reasonably modern solution capable of being
the default I'm aware of.
> I don't know for which reasons Recommends for the resolve tools were
> dropped to Suggests.
Unit 193, any explaination?
commit 324d375b79fab138f0c83af022bbe9e795d5e696
Author: Unit 193
Date: Fri May 15 18:32:09 2020 -0400
d/control: Lower 'openresolv | resolvconf' to suggests.
diff --git a/debian/control b/debian/control
index 09513a2..9093d4b 100644
--- a/debian/control
+++ b/debian/control
@@ -40,8 +40,8 @@ Depends:
${shlibs:Depends},
Recommends:
nftables | iptables,
- openresolv | resolvconf,
wireguard-modules (>= 0.0.20171001) | wireguard-dkms (>= 0.0.20191219),
+Suggests: openresolv | resolvconf,
Description: fast, modern, secure kernel VPN tunnel (userland utilities)
WireGuard is a novel VPN that runs inside the Linux Kernel and uses
state-of-the-art cryptography (the "Noise" protocol). It aims to be
> The issue for me is that
>
> 1) First the description in control
>
> This package contains command-line tools to interact with the
> WireGuard kernel module. Currently, it provides only a single tool:
> .
> wg: set and retrieve configuration of WireGuard interfaces
>
> is no more appropriate. It ships now wg-quick, too.
That's unrelated open a seperate bug for that please.
> 2) The decision to downgrade resolve tools to Suggests may perhaps date back
> to
> a time where wg was indeed the only binary shipped in the package?
I doubt it wg-quick has existed for a good long while. My guess is the
recommends was demoted because of DNS problems with openresolv/resolvconf ;)
> Now wg-quick failed from the beginning which is a major annoyance and a
> really bad user experience.
Right, but you have to admit that by using a commandline tool you're
already well into poweruser territory so IMO you (or anyone doing that) is
expected to be able to debug this.
See I would expect most desktop users to deploy their wg VPN tunnels using
NetworkManager integration or some such. If DNS is broken in that case I'd
consider that a big problem as, say, my mum can't be expected to debug
this, haha.
> I think it could be a very common use case to use wireguard
> configurations with DNS entries. Thus the package should work
> out-of-the-box in a default Debian installation.
It's just not that clear-cut due to the brokenness of the
openresolv/resolvconf approach. I would agree if there were no known
downsides to installing them but alas..
> As a thought: if it makes substantial problems to install by default a resolv
> conf tool on servers would it perhaps improve things a little bit, if wg-quick
> would be phased out into a separate package?
Unfortunately the firewall functionality of wg-quick is still important on
servers. There just aren't any easy solutions here. To move things forward
we have to do the (hard) work of debugging why systemd-resolvd is broken in
your case and fixing it. I'm happy to help with that tho.
> Finally, if that all is yet not applicable for you then please document the
> current situation in README.Debian where my next source of information for the
> package is when I run into problems. It would have helped me lot ;)
Was there not a reasonable error message pointing at the missing
resolvconf? If so I think we may want to patch wg-quick to make the problem
a bit more verbose.
--Daniel
signature.asc
Description: PGP signature
Bug#916475: [Pkg-electronics-devel] Bug#916475: ghdl: various suggestions to simplify the packaging
Hi Nicolas, On Wed, Oct 11, 2023 at 10:58:22PM +0200, Nicolas Boulenguez wrote: > > honestly the whole link script looks like a hack to me, I prefer the > > way it was before. > > I agree that an executable debian/libghdl-dev.links is a last resort, > but a reader discovering the package does not need to [...]. Well at least the new version has more docs and works, I'll take it. Let's see if Andreas just reverts it or not ;) More comments inline below. > Subject: [PATCH 07/14] Delegate computation of Built-Using to dh-builtusing This breaks the build for me since I build the source package on bookworm (via gbp). I might hold off on this one until dh-builtusing is backported. > From caf2fa626289a1850da5d0c46431b009f30c793c Mon Sep 17 00:00:00 2001 > From: Nicolas Boulenguez > Date: Thu, 5 Oct 2023 14:39:35 +0200 > Subject: [PATCH 12/14] Various minor improvements in the test driver > > Enable more alerts by the shell. > > Check the argument count. > > Replace test cascades with 'case' constructs. > > There is no need to create RUNDIR because the script is called after a > 'make install'. > > There is no need to check that the RUNDIR variable is not empty, it is > set in all branches of the previous construct. > --- > debian/tests/ghdl-tests | 34 +++--- > 1 file changed, 15 insertions(+), 19 deletions(-) > > diff --git a/debian/tests/ghdl-tests b/debian/tests/ghdl-tests > index 5868e16c..871d594b 100755 > --- a/debian/tests/ghdl-tests > +++ b/debian/tests/ghdl-tests > @@ -1,39 +1,35 @@ > #!/bin/sh > > -set -e > +set -C -e -f -u > > # The pyunit tests are not run here. These parts are not activated in > # Debian yet. > TESTS="sanity gna vests synth vpi vhpi" > > +test $# = 2 This is kind of obscure, think of the (lack of an) error message. If we skip this we'll get an "undefined $2" error due to set -u, which I find is more helpful than a quiet exit rv>0. > -if [ "$2" = mcode ]; then > - BACKEND=mcode > -elif [ "$2" = llvm ]; then > - BACKEND=llvm > -elif [ "$2" = gcc ]; then > - BACKEND=gcc > -else > +case "$2" in > +gcc|llvm|mcode) > + BACKEND=$2 > + ;; > +*) > echo >&2 "Invalid backend specification" > exit 1 > -fi > +esac > > -if [ "$1" = buildtest ]; then > +case "$1" in > +buildtest) > RUNDIR=testrundir/$BACKEND > - mkdir -p "$RUNDIR" > GHDL="$PWD/$RUNDIR/usr/bin/ghdl-$BACKEND" > -elif [ "$1" = autopkgtest ]; then > + ;; > +autopkgtest) > RUNDIR="$AUTOPKGTEST_TMP" > GHDL=/usr/bin/ghdl-$BACKEND > -else > + ;; > +*) > echo >&2 "Invalid test environment specification" > exit 1 > -fi > - > -if [ -z "$RUNDIR" ]; then > - echo >&2 "RUNDIR is empty string" > - exit 1 > -fi > +esac > > # Copy testsuite into $RUNDIR to execute there, so that no cleanup is > necessary > # (entire $RUNDIR will be deleted later). Also copy src/grt as at least one > test > -- > 2.39.2 --Daniel signature.asc Description: PGP signature
Bug#1054125: dh-builtusing: Please backport dh-builtusing to bookworm
Source: dh-builtusing Version: 0.0.5 Severity: wishlist X-Debbugs-Cc: d...@darkboxed.org Hi Nicolas, would it be possible to get dh-builtusing backported for bookworm? We want to use dh-builtusing in ghdl (as you know ;), but I run my package builds on bookworm, inside an sbuild chroot, but gbp breaks when building the source package it's going to hand to the chroot. ``` dh /usr/share/ada/packaging.mk dh: error: unable to load addon builtusing: Can't locate Debian/Debhelper/Sequence/builtusing.pm in @INC (you may need to install the Debian::Debhelper::Sequence::builtusing module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at (eval 15) line 1. BEGIN failed--compilation aborted at (eval 15) line 1. debian/rules:10: /usr/share/ada/packaging.mk: No such file or directory make: *** [debian/rules:65: /usr/share/ada/packaging.mk] Error 255 E: Failed to clean source directory /home/dxld/share/dev/deb/pkg/ghdl (/home/dxld/share/dev/deb/pkg/ghdl_3.0.0+dfsg2-1.dsc) gbp:error: 'sbuild -d unstable --anything-failed-commands %SBUILD_SHELL' failed: it exited with 1 ``` I've reported the dh-ada-library error seperately, I think either of those problems would break the srcpkg build. Thanks, --Daniel
Bug#1054124: dh-ada-library: dh_ada_library output causes /usr/share/ada/packaging.mk:81: *** missing separator error
Package: dh-ada-library Version: 8.6 Severity: normal X-Debbugs-Cc: d...@darkboxed.org Hi Nicolas, on my bookworm system importing dh-ada-library's packaging.mk is causing a make error. AFAICT due to `dh_ada_library --export-versions` including some copyright output in DEB_GNAT_VERSION: ``` $ dh_ada_library --export-versions DEB_ADA_SOURCE_DIR:=usr/share/ada/adainclude DEB_LIB_DIR:=usr/lib/x86_64-linux-gnu DEB_ADA_LIB_INFO_DIR:=usr/lib/x86_64-linux-gnu/ada/adalib DEB_GNAT_PROJECT_DIR:=usr/share/gpr DEB_GNAT_VERSION:=GNATMAKE 10.2.1 20210110 Copyright (C) 1995-2020, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` I'm not sure what changed to break this, ghdl has been using dh-ada-library for a while now and this wasn't a problem before. Thanks, --Daniel -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-ada-library depends on: ii debhelper 13.11.4 ii gnat-1010.2.1-6 ii perl 5.36.0-7 dh-ada-library recommends no packages. Versions of packages dh-ada-library suggests: pn gprbuild -- no debconf information
Bug#1012722: wireguard-tools: wg-quick DNS server setup should remove existing /etc/resolv.conf lines
Hi Celejar, Mathias,
On Thu, Oct 12, 2023 at 03:36:12PM +0200, Mathias Behrle wrote:
> On Sun, 12 Jun 2022 17:13:29 -0400 Celejar wrote:
> > I would think that the correct behavior would be for wg-quick to *replace*
> > the existing contents of resolv.conf, rather than just *prepending*
>
> For you this behavior is the desired one, for me not ;). Because I am losing
> my
> local DNS configuration poiting to my local hosts.
Since you both seem to have a sense of what you want your DNS config to
look like you may want to consider cutting out the middleman and asserting
control of resolv.conf directly. The state of resolv.conf managment on
Linux is unfortunately a huge mess. Me personally I've lost confidence and
patience in the current crop of common tools
(resolvconf/openresolv/systemd-resolved) and so I feel it's worth it for my
purposes.
Here's two approaches I've used to bypass them with caveats and
workarounds:
1) Hand edit /etc/resolv.conf plus chattr +i
This works very well in my testing, none of the managment tools try to lift
the "i" (immutable) fs attribute so the contents stay the way you want them
and any rogue tool just fails to replace/write-to resolv.conf.
One nasty caveat is the current dhclient-script that fails to cleanup the
resolv.conf.tmpXXX file it uses to atomically replace resolv.conf. This can
cause serious blowup in /etc and ENOSPC problems (ask me how I know ;). I
dealt with this by installing a dhclient-enter-hook like so:
$ cat /etc/dhcp/dhclient-enter-hooks.d/disable-resolv-conf
#!/bin/sh
# NOP out function updating resolv.conf as our upstreams like to force DNS
# related dhcp options on us despite not asking for them. Woohoo.
make_resolv_conf() :
Ofc. other tools may fail in similarly hilarious ways, but at least they
wont break DNS ;)
2) Install a symlink to your config at /etc/resolv.conf
AFAICT most mangmagment tools seem to back off when resolv.conf is a
symlink to a location they don't recognize (I've only really tested with
systemd-resolved). This works ok, but the main problem is apparmor (which
only affects some programs). /etc/apparmor.d/abstractions/nameservice has
an explicit list of files programs may read and this doesn't really
allocate any namespace for local system additions:
@{etc_ro}/resolv.conf r,
# On systems where /etc/resolv.conf is managed programmatically, it is
# a symlink to @{run}/(whatever program is managing it)/resolv.conf.
@{run}/{resolvconf,NetworkManager,systemd/resolve,connman,netconfig}/resolv.conf
r,
@{etc_ro}/resolvconf/run/resolv.conf r,
@{run}/systemd/resolve/stub-resolv.conf r,
/mnt/wsl/resolv.conf r,
This can be fixed by installing a drop-in such as
$ cat /etc/apparmor.d/abstractions/nameservice.d/local-resolv-conf
abi ,
@{etc_ro}/resolv.conf.local.* r,
3) apt-get purge-with-a-vengeance resolvconf openresolv systemd-resolveconf &&
apt-pinning
I've had the problem that the offending DNS managment tools get installed
through recommends even though I don't intend for them to be used, I
haven't worked this out yet but I think it'd be reasonably easy to write an
apt preferences snippet to prevent them being installed in all cases.
A final note: I use ifupdown for my network interface managment needs:
ethernet, wifi, vpn (on/off switch) etc. This way I can easily integrate
hooks to configure the DNS on a per-network basis, but if you use something
like NetworkManage as-is this approach means you have to have one static
config you're happy with -- well you can always just copy/symlink
per-network templates into place manually but that seems a hassle.
Let me know your use cases though maybe I can figure something out even for
that case.
--Daniel
signature.asc
Description: PGP signature
Bug#968683: wireguard-tools: missing dependency in wireguard-tools resolvconf - wg-quick up
Hi Mathias, On Thu, Oct 12, 2023 at 11:14:58AM +0200, Mathias Behrle wrote: > I also ran into this problem, a resolvconf command is required for > wg-quick Saying that resolvconf is _required_ for wg-quick is a bit of a stretch, it's only needed when a DNS= line is present in the config. > Please promote the Suggests for the resolvers to at least Recommends. The problem I see with a recommends is that wireguard is frequently used on servers/routers but openresolv/resolvconf have various problems on such systems. I've personally had problems with them breaking an unbound server, but #761050 "openresolv sets local bind to always forward requests, even when local bind is authoritative" discusses a similar problem with BIND. What is your exact use-case? I assume it's for a desktop VPN, in which case adding systemd-resolved support to wg-quick might be less problematic. --Daniel signature.asc Description: PGP signature
Bug#1053819: recutils: Please install bash-builtin into default load path
Package: recutils Version: 1.8-1 Severity: wishlist X-Debbugs-Cc: d...@darkboxed.org Hi Sven, your recutils package currently installs the recutils.so bash builtins into /usr/lib/recutils/bash-builtins/readrec.so While looking for the best place to put the builtins lib for one of my packages I found that bash has an (apparently) undocumented default load path for builtins: DEFAULT_LOADABLE_BUILTINS_PATH defined as /usr/local/lib/bash /usr/lib/bash /opt/local/lib/bash /usr/pkg/lib/bash /opt/pkg/lib/bash So it may be a good idea to put all bash builtins in Debian into /usr/lib/bash. Naturally it would be good to install a symlink at the old location. I would certainly appreciate being able to get rid of the ugly hardcoded path in one of my other other projects using recutils :) Let me know what you think. Thanks, --Daniel
Bug#916475: [Pkg-electronics-devel] Bug#916475: ghdl: various suggestions to simplify the packaging
Hi Nicolas, On Wed, Oct 11, 2023 at 09:03:16AM +0200, Nicolas Boulenguez wrote: > Source: ghdl > Followup-For: Bug #916475 > > A rebased and extended list of suggestions is attached. Thanks for taking the time. > Debdiff reports no change in the binary packages. Unfortunately 0003-Install-development-symbolic-link-to-shared-library-.patch is broken because the builtin dash basename only takes one argument. I'm not sure how you got this to build? You likeley wanted to use `command basename -a` for coreutils basename, but honestly the whole link script looks like a hack to me, I prefer the way it was before. Not picking that patch makes the series fail to apply, so please resend. Prefereably with git send-email (to me directly, not sure BTS will like the mail flood), I don't enjoy manually picking 14 patches individually :] Thanks, --Daniel signature.asc Description: PGP signature
Bug#1051817: unbound: local_datas without \4\n reuses last read buffer(?) and produces infinite error output
Hi, On Mon, Oct 09, 2023 at 05:01:00PM +0200, наб wrote: > [...] But come on, don't berate users for doing the right (and > hard-fought-for) thing. I didn't mean to berate you. I'm trying to point out, respectfully, that there's not much of a point in doing a round trip through Debian in cases like this. Perhaps I'm missing something hence the "is there a reason" question. I might also remind you of the Debian Code of Conduct: 2. Assume good faith > Phrasing this as "reporting a bug in debian to the appropriate debian > maintainers burdens them greatly" is baffling. Please don't put words in my mouth. --Daniel PS: While I find your unfriendly response disappointing, you should still feel free to CC me on your upstream report (@DanielG on GH) so I can update the Debian bugs. --Daniel signature.asc Description: PGP signature
Bug#1051817: unbound: local_datas without \4\n reuses last read buffer(?) and produces infinite error output
Hi,
> In trying to reduce another bug, I got the following:
>
> $ { printf '%s\n' 'UBCT1 local_datas' ';; a' 'abc.def. 3600 in txt testupa'
> ';; b'; } | sudo socat - UNIX-CONNECT:/run/unbound.ctl
> error parsing local-data at line 1 position 4 ';; a': Syntax error, could not
> parse the RR
Is there a reason you're not reporting this dirctly uptream? AFAICT the
(few) Debian patches we have don't touch any of this code and 1.18.0 is the
latest upstream release so there should be no reason to burden the Debian
maintainers here.
This also applies to your #1051818. I'd suggest submitting the bugs here
https://github.com/NLnetLabs/unbound/issues/new/choose
or the unbound-users ML if you prefer not to use GH
https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
--Daniel
signature.asc
Description: PGP signature
Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2
Hi Santiago, On Fri, Sep 29, 2023 at 05:50:54PM +0200, Santiago Vila wrote: > Well, "yosys" was one of the packages which FTBFS for me. > It was version 0.23-6, and it failed in a different way. > > But something tells me that this bug reported by Lucas > could easily be another Makefile bug. > > So, instead of trying to reproduce the problem by building > the package in your machine, I suggest that you take the provided > build log, collate it with the current Makefiles, and try to > determine how could it happen at all. I tried to diff the logs but latex is hillariously good at outputting random interleaved chunks of text in an unpredictable order so that wasn't really any help in seeing whats going on. > For example, the build log says this: > > I can't find file `verilog_flow.aux'. > > The interesting question here would be: > > Are you sure that the Makefiles are correctly written in > such a way that the verilog_flow.aux file is always created > before some other process tries to use it? Upstream uses latexmk for calling pdflatex. That should usually take care of such things properly, at least I haven't seen it fail like this before. It's possible this is a make level concurrency issue but before I go down that rabbit hole I want to exclude any of the more easily debugged problems, like: different dependency versions which is trivial to diff given the buildinfo file. IMO these should be included in MBF FTBFS filings as a matter of course as it's easily the most likeley reason for breakage. Thanks, --Daniel signature.asc Description: PGP signature
Bug#916475: ghdl: various suggestions to simplify the packaging
Hi Nicolas, On Wed, Dec 21, 2022 at 06:12:09PM +0100, Nicolas Boulenguez wrote: > Four were ignored, probably because you are busy with the build > failures. > > Just in case, a rebased version is attached. It's been a while since you submitted these patches and Andreas changed a lot of the packaging since. Could you do me a favor and re-check if your improvements were included in spirit/whole? Me and Simon have put in some work to get ghdl_3.0.0 packaged and I'd love to apply any of your changes that are still relevant. Thanks, --Daniel
Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2
Hi Lucas, On Tue, Sep 26, 2023 at 03:43:28PM +0200, Lucas Nussbaum wrote: > Source: yosys > Version: 0.33-5 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > The full build log is available from: > http://qa-logs.debian.net/2023/09/25/yosys_0.33-5_unstable.log Is the buildinfo file for the rebuild available somewhere too? I'd like to diff the build environment against what the buildds had. Thanks, --Daniel signature.asc Description: PGP signature
Bug#1052194: ITP: sby -- SymbiYosys -- formal hardware verification frontend for yosys
Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org Hi, * Package name: sby Version : 0.33 Upstream Author : YosysHQ GmbH et al. * URL : https://github.com/YosysHQ/sby * License : ISC Programming Lang: Python Description : SymbiYosys -- formal hardware verification frontend for yosys SymbiYosys (sby) is a front-end driver program for Yosys-based formal hardware verification flows. SymbiYosys provides flows for the following formal tasks: - Bounded verification of safety properties (assertions) - Unbounded verification of safety properties - Generation of test benches from cover statements - Verification of liveness properties -- The test suite for yosys-plugin-ghdl has started to depend on sby so I figure it's time to package it in Debian if only for test coverage. Currently upstream uses a custom Makefile based approach to Python packaging but I was assured they are planning to migrate to a more standardised approach (eventually). I'm unsure if it would be better to put this package in electronics-team or python-team, but it doesn't look too crazy complicated at first glance so I'm tending towards electonics. I don't actually have a use for hardware verification tools currently so if anyone is interesting in that area I'd be happy to have someone to help with testing against real world projects and such. I will likely need a sponsor for this package unless my DD application goes though before I end up doing the packaging work ;) --Daniel
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Hi Nicholas, On Sun, Sep 17, 2023 at 02:56:47PM -0400, Nicholas D Steeves wrote: > Thank you for working on this! One note: where is it documented how > ipupdown and ipupdown-ng interact? You just install the ifupdown-ng package and it kicks ifupdown out the door :) More seriously: ifupdown-ng now Recommends:ifupdown-ng-compat (the bit that conflicts with ifupdown) so for testing I can do --no-install-recommends and get both at once but the old package in stable just straight up conflicts with traditional ifupdown. I'm intending to do a good amount of testing/integration work to make sure ifupdown-ng can handle an upgrade without breaking the network but that hasn't happened yet. Though I keep switching back and forth between them and haven't noticed any severe breakage yet so maybe it's already fine :3 Testers welcome. I'd also appreciate people send me weird stuff they have in /etc/network/interfaces I can try out. A bit of background: The way I see it ifupdown-ng's integration into Debian isn't complete yet. Unfortunately the very first (pretty incomplete) upload landed in stable. Part of the reason being that Thomas seems to have lost interest and I was peeved by his essentially snatching the package out from under me, re-doing my packaging work with some weirdly broken openstack-pkg specific git packaging scripts I didn't want to deal with. So I neglected the package for a while. > For example using the alternatives system, or a different config file > location, or some sort of tagging mechanism in network/interfaces. I > would appreciate it if this was in the changelog, at a minimum, and maybe > other people would too? A brief "...by using $method" seems like it > would be enough. Since the interaction amounts to "one replaces the other" I think this is mild overkill. The package description already covers how it's supposed to be a drop-in replacement, maybe you missed that. Though ATM this still seems a bit more aspirational than practical[1], but maybe I'm just pedantic about compatibility. [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/216 For a high-level overview of the project goals and how it compares to ifupdown2 etc have a look at Maximilian's DebConf-21 talk: https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/ --Daniel
Bug#1052127: RFS: ifupdown-ng/0.12.1-1 -- network interface configuration tool
Package: sponsorship-requests Severity: normal Hello mentors, I am looking for a sponsor for my package ifupdown-ng, it's a promising modern alternative for ifupdown with support for dependencies and a lot more interface types. The headline change in this revision is that I've split a new binpkg from the package to support co-installability with traditional ifupdown. This will enable easier migration and compatibility testing. Full changelog below. * Package name : ifupdown-ng Version : 0.12.1-1 * URL : https://github.com/ifupdown-ng/ifupdown-ng * Vcs : https://salsa.debian.org/debian/ifupdown-ng * License : MIT-like Section : admin The source builds the binpkgs: ifupdown-ng - network interface configuration tool ifupdown-ng-compat - network interface configuration tool -- ifupdown compat The gbp source repo lives at https://salsa.debian.org/debian/ifupdown-ng.git please use the git repo for uploading but the package is also on mentors for linting results: https://mentors.debian.net/package/ifupdown-ng/ Changes since the last upload: ifupdown-ng (0.12.1-1) UNRELEASED; urgency=medium . [ Debian Janitor ] * Bump debhelper from old 12 to 13. * Set upstream metadata fields: Repository-Browse. * Update standards version to 4.6.1, no changes needed. * Set upstream metadata fields: Repository. . [ Daniel Gröber ] * New upstream release * Fix nonsense janitor commits * Fix d/watch * Add patch to support ifupdown compatible 'source' include patterns * Fix bogus ExecRestart systemd unit stanza (Closes: #1006817) * Align systemd service dependencies with ifupdown * Drop support for kfreebsd/hurd * Remove deprecated lsb-base dependency * Promote rdnssd to recommends for IPv6-only support by default * Fix co-installability with ifupdown * Ensure all make targets run under the same environment * Fix conflicting files in /usr/share/man * Fix networking script perms * Add autopkgtest for coinstallability with traditional ifupdown * Fix some pedantic lintian complaints * Fix upgrade path from stable not installing ifupdown compat Thanks, --Daniel signature.asc Description: PGP signature
Bug#1051847: iproute2 ships configuration files in /usr/lib violating debian-policy
Package: iproute2 Version: 6.1.0-3 Severity: serious Justification: Policy 10.7.2 X-Debbugs-Cc: d...@darkboxed.org Dear Maintainer, your iproute2 6.5.0-3 package installs configuration files in /usr/lib/iproute2. This is a blatant violation of debian-policy section 10.7.2. "Configuration files / Location" which states as follows: > Any configuration files created or used by your package must reside > in /etc. If there are several, consider creating a subdirectory of > /etc named after your package. As I've mentioned in Bug#1051577 this is related to upstream commit commit 0a0a8f12fa1b03dd0ccbebf5f85209d1c8a0f580 Read configuration files from /etc and /usr Add support for the so called "stateless" configuration pattern (read from /etc, fall back to /usr), giving system administrators a way to define local configuration without changing any distro-provided files. In practice this means that each configuration file FOO is loaded from /usr/lib/iproute2/FOO unless /etc/iproute2/FOO exists. but moving the config files from /etc/iproute to /usr/lib is misguided and should be overriden in your Debian package. Thanks, --Daniel
Bug#1051577: iproute2: obsolete conffiles
Hi Luca, On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote: > > I want to question whether removing these conffiles is a good idea at > > all. I'm probably one of the few people that actually muck around in there > > but it seems like this is going to break things for any users that do. > > As far as I understand dpkg's conffile machinery should recognize if > you changed anything, and leave it in place. Upstream moved the > default ones to /usr, so we just follow what they do. Right. Think of an admin having to adjust these config files though: previously they could just `editor /etc/iproute2/rt_tables` and get on with things. Now anyone needing to do that will have to do a doubletake, figure out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2 now, copy that over and finally edit. Is that friction really warrented to cater to a specialized niche use-case? Please consider overriding upstream's decision here. --Daniel signature.asc Description: PGP signature
Bug#1051577: iproute2: obsolete conffiles
Hi, On Mon, Sep 11, 2023 at 08:32:10AM +0200, Sven Joachim wrote: > > After upgrading to 6.5.0-1 adequate shows: > > > > adequate found packaging bugs > > - > > > > iproute2: obsolete-conffile /etc/iproute2/rt_tables.d/README > > iproute2: obsolete-conffile /etc/iproute2/rt_protos.d/README > > iproute2: obsolete-conffile /etc/iproute2/rt_protos > > iproute2: obsolete-conffile /etc/iproute2/rt_dsfield > > iproute2: obsolete-conffile /etc/iproute2/nl_protos > > iproute2: obsolete-conffile /etc/iproute2/ematch_map > > iproute2: obsolete-conffile /etc/iproute2/bpf_pinning > > There are a few more leftovers still present in 6.5.0-2: > > , > | $ adequate iproute2 > | iproute2: obsolete-conffile /etc/iproute2/group > | iproute2: obsolete-conffile /etc/iproute2/rt_realms > | iproute2: obsolete-conffile /etc/iproute2/rt_scopes > | iproute2: obsolete-conffile /etc/iproute2/rt_tables > ` > > There are also the directories /etc/iproute2/rt_protos.d, > /etc/iproute2/rt_tables.d and /etc/iproute2 which are no longer shipped > in the package. Unfortunately dpkg-maintscript-helper does not clean > those up automatically (see #584185). I want to question whether removing these conffiles is a good idea at all. I'm probably one of the few people that actually muck around in there but it seems like this is going to break things for any users that do. Is it really sensible to move these files to /usr/lib in the standard Debian installation? It seems to me upstream only wants to better support /usr-only deployments without /etc: commit 0a0a8f12fa1b03dd0ccbebf5f85209d1c8a0f580 Read configuration files from /etc and /usr Add support for the so called "stateless" configuration pattern (read from /etc, fall back to /usr), giving system administrators a way to define local configuration without changing any distro-provided files. In practice this means that each configuration file FOO is loaded from /usr/lib/iproute2/FOO unless /etc/iproute2/FOO exists. So why not simply keep the conffiles in /etc for regular admins and let people that want to do image based deployments create /usr/lib/iproute2 if they want to override or remove /etc? --Daniel signature.asc Description: PGP signature
Bug#1051565: unbound: Please backport unbound 1.18.0 for bookworm to enable NAT64 support
Source: unbound Version: 1.17.1-2 Severity: wishlist Tags: ipv6 X-Debbugs-Cc: d...@darkboxed.org Dear Maintainer, I would like to run an unbound resolver on an IPv6-only network. This is problematic because many nameservers on the internet are only reachable over IPv4. Starting with 1.18.0 unbound provides NAT64 support on the recursor side. Meaning when it encounters an IPv4 only NS it will try to reach it though a NAT64 prefix instead. I've rebuilt and tested 1.18.0-2 on bookworm and it works fine, could you upload a backport for bookworm please so other users can benefit from this new feature too? Thanks, --Daniel -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1037506: Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Simon, I've pushed apycula 0.9.0 to https://salsa.debian.org/electronics-team/apycula/ A test build with my updated nextpnr package checks out. This release adds PLL support for Gowin apparently so that will be useful. Please upload it when you get a chance. FYI: prjtrellis is also waiting for another upload to appease ftp-master review https://salsa.debian.org/electronics-team/prjtrellis/ Thanks, --Daniel signature.asc Description: PGP signature
Bug#1050397: 1: yosys-src is huge
Hi,
On Thu, Aug 24, 2023 at 03:00:36AM +0200, Daniel Gröber wrote:
> As long as nobody installs this package at least it won't waste space in
> the archive as the deb is compressed anyway. Post mortem wise, I'm not sure
> what's going on here. When I unpack the tarball the directory only ends up
> being around 50M (as it should be).
Ok so the deb(s) are actually still around 350-400M depending depending on
the architecture, because I also forgot to set Arch:all (ouch) and the
buildd built amd64 deb is actually 2.2G when unpacked.
The yosys-src I had build locally didn't end up that large tho.
I'm not entirely sure why the tarball got so big. Due to a misplaced
dependency the tarball was packed after dh_auto_build/_test, but I used
--files-from to prevent including any build artifacts.
This is the d/rule that builds yosys.tar:
ORIG_TARBALL := ../$(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM).orig.tar.gz
debian/yosys-src/usr/src/yosys/yosys.tar: SHELL := /bin/bash
debian/yosys-src/usr/src/yosys/yosys.tar: FORCE
mkdir -p debian/yosys-src/usr/src/yosys
tar --files-from <(tar -taf $(ORIG_TARBALL) | sed -r -e
's,[^/]+/,,') \
--ignore-failed-read --transform 's,^,yosys/,' \
--sort=name --mtime=@"$$SOURCE_DATE_EPOCH" \
--owner=0 --group=0 --numeric-owner --format=gnu \
-cf $@ \
debian/{control,changelog,source,patches,rules}
Testing this again now on a dirty build tree that's 2.6G in size I get a
yosys.tar that's 70k. What the hell went wrong on the buildds?
Looking at the amd64 log I see no (relevant) errors and the expanded tar
command looks right:
make[1]: Entering directory '/<>'
mkdir -p debian/yosys-src/usr/src/yosys
tar --files-from <(tar -taf ../yosys_0.30.orig.tar.gz | sed -r -e
's,[^/]+/,,') \
--ignore-failed-read --transform 's,^,yosys/,' \
--sort=name --mtime=@"$SOURCE_DATE_EPOCH" \
--owner=0 --group=0 --numeric-owner --format=gnu \
-cf debian/yosys-src/usr/src/yosys/yosys.tar \
debian/{control,changelog,source,patches,rules}
tar: tests/simple_abc9/abc9.v: Warning: Cannot stat: No such file or
directory
The abc9.v thing is expected, hence --ignore-failed-read. Yet yosys.tar
ends up huge.
-rw-r--r-- root/root 2289633280 2023-08-23 14:40 ./usr/src/yosys/yosys.tar
Looking at the file sizes of top offenders inside the buildd built amd64
yosys-src:
$ tar -tvf ./usr/src/yosys/yosys.tar | sort -n -k3 -r | head -n20
-rwxr-xr-x 0/022706286 2023-08-23 16:40
yosys/tests/bram/temp/tb_00_03.tb
-rw-r--r-- 0/019693600 2023-08-23 16:40 yosys/passes/sat/sim.o
-rw-r--r-- 0/018143464 2023-08-23 16:40 yosys/kernel/rtlil.o
-rw-r--r-- 0/016335168 2023-08-23 16:40 yosys/passes/sat/qbfsat.o
-rw-r--r-- 0/015009576 2023-08-23 16:40 yosys/passes/opt/share.o
-rw-r--r-- 0/014109856 2023-08-23 16:40
yosys/backends/cxxrtl/cxxrtl_backend.o
-rw-r--r-- 0/014010040 2023-08-23 16:40
yosys/passes/sat/recover_names.o
-rw-r--r-- 0/013766864 2023-08-23 16:40 yosys/passes/opt/opt_expr.o
-rw-r--r-- 0/013337960 2023-08-23 16:40 yosys/passes/techmap/abc.o
-rw-r--r-- 0/013268272 2023-08-23 16:40
yosys/passes/techmap/abc9_ops.o
-rw-r--r-- 0/013182088 2023-08-23 16:40 yosys/backends/smt2/smt2.o
-rw-r--r-- 0/012897840 2023-08-23 16:40
yosys/passes/memory/memory_libmap.o
-rw-r--r-- 0/012610552 2023-08-23 16:40
yosys/passes/pmgen/xilinx_dsp.o
-rw-r--r-- 0/012223360 2023-08-23 16:40
yosys/passes/pmgen/test_pmgen.o
-rw-r--r-- 0/012123208 2023-08-23 16:40
yosys/passes/techmap/flowmap.o
-rw-r--r-- 0/012104440 2023-08-23 16:40
yosys/passes/techmap/techmap.o
-rw-r--r-- 0/012051072 2023-08-23 16:40
yosys/libs/subcircuit/subcircuit.o
-rw-r--r-- 0/011872992 2023-08-23 16:40 yosys/passes/sat/sat.o
-rwxr-xr-x 0/011443185 2023-08-23 16:40
yosys/tests/bram/temp/tb_01_03.tb
-rwxr-xr-x 0/011413171 2023-08-23 16:40
yosys/tests/memlib/t_async_big_block.out/t_async_big_block_tb_syn0
That's all build output that shouldn't have been included because of the
explicit --files-files.
I'm mystified.
--Daniel
Bug#1050397: 1: yosys-src is huge
Hi Samuel, On Thu, Aug 24, 2023 at 02:01:16AM +0200, Samuel Thibault wrote: > The yosys-src package is huge, it contains a 2.2GiB tarball, perhaps it > should at least be compressed? Yowza! something definetly went wrong there, thanks for pointing this out. I'm about to remove this binpkg again anyhow, it was intended to be used to run the testsuite in the autopkgtests of yosys' most flaky/critical dependency (berkeley-abc) but I didn't realise rdepends with broken autopkgtests will block migration anyhow. So this shouldn't actually be necessary. As long as nobody installs this package at least it won't waste space in the archive as the deb is compressed anyway. Post mortem wise, I'm not sure what's going on here. When I unpack the tarball the directory only ends up being around 50M (as it should be). I'll have a closer look tomorrow. Thanks, --Daniel
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
Hi,
On Sat, Aug 19, 2023 at 04:53:09PM +0200, Raphael Hertzog wrote:
> > The problem is that regex is NOT supported at the moment.
>
> Urgh, and you did not complain that the release notes actually encourage
> users to do that?
Yeah, that seems less than ideal. Brings me back to thinking we should
change the security codename to something that's not going to need these
hacky regexes then.
Since $release/security is not well liked for unclear ("dak") reasons
(please someone elaborate if possible), perhaps an approach based on
Ubuntu's is less controvertial.
In debian-security/bookworm-security we have this right now
Origin: Debian
Label: Debian-Security
Suite: stable-security
Version: 12
Codename: bookworm-security
and we need the regex becuase $codename/$suite doesn't match "bookworm",
"bookworm/*" or stable, stable/* resp. Compare this to what Ubuntu uses:
Origin: Ubuntu
Label: Ubuntu
Suite: kinetic-security
Version: 22.10
Codename: kinetic
Here APT::Default-Release "kinetic" would match just fine. Just seems they
don't support the "stable" alias like we do. Could we use this to cover
both use-cases:
Origin: Debian
Label: Debian-Security
Suite: stable
Codename: bookworm
Now no weird hacks are neceessary APT::DefaultRelease "bookworm" or
"stable" will match the security repos just fine.
Users that _really_ want to do weird things to the security repo can still
use a "label" match in apt/preferences like `Pin: release
l=Debian-Security`. I think you'd be able to combine this with a codename
match to be specific about which release too: `Pin: release
l=Debian-Security n=bookworm` but don't quote me on that until someone
tests it.
I don't see any real downsides to this approach other than "ugh more
change".
--Daniel
Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Simon, On Wed, Jul 26, 2023 at 11:45:32AM +0900, Simon Richter wrote: > Hi Daniel, > > On 7/25/23 22:53, Daniel Gröber wrote: > > > FYI: It seems you didn't do a source-only upload for apycula so it's > > BLOCKED from migrating to testing now. We have to do another source-only > > upload to get it unstuck. > > Yes, known problem. I dimly remember that NEW uploads require binaries for > some reason. Ah yes, you're right, https://wiki.debian.org/SourceOnlyUpload says: NEW uploads and uploads with NEW binary packages currently cannot be source-only. This is also true for backports-NEW. This means you need to upload a source+binary package in these situations. After your package has passed the checks and is in the archive, you need to do a source-only upload to allow the package to migrate to testing. The source+binary package you did initially will NOT be allowed to migrate. > > > Did you make any changes either of the the packages? If so don't forget to > > > commit and push to salsa please. You should have push access to > > > electronics-team, right? > > No changes, IIRC. I'm not sure if I have push access, I will have to check > at home. If you didn't make any changes it's not necessary. I can probably reconstruct the tags myself then. Don't worry about it. > > Also a reminder on pushing the tags if you could: > > Right, I'll have to learn how to do that, I seldom use git-buildpackage, and > I verify packages by building them in pbuilder. You should be able to have gbp use pbuilder for building, see --git-builder= or --git-pbuilder=. > BTW, I have ghdl 3.0.0 packages at https://deb.simonrichter.eu/ and am > successfully using the ghdl yosys plugin with those, this might be another > goal for the next months. Neat, now we just have to get Andreas to upload it. Can you submit a BTS patch / salsa PR or something? I'm still wating for prjtrellis to clear NEW before the updated nextpnr can go in, is there anyone we can poke to accellerate things? It's been sitting around a good while now :) yosys_0.30 on the other hand is giving me a hard time since I started trying to package it's testsuite as an autopkgtest. I had to take a break from that but I'll get back to that soon and then it'll (hopefully) have migration blocked if a berkeley-abc upload breaks it. Upstream yosys has also been kind enough to tag releases on yosys-abc so we could package that to make breakage due to mismatch between their fork and bekeley-abc less likely (https://github.com/YosysHQ/yosys/issues/3827) --Daniel
Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Simon, On Sat, Jun 24, 2023 at 10:50:24PM +0200, Daniel Gröber wrote: > > Will look at apycula now. > > I see you already uploaded it now. Great! FYI: It seems you didn't do a source-only upload for apycula so it's BLOCKED from migrating to testing now. We have to do another source-only upload to get it unstuck. Also a reminder on pushing the tags if you could: > Did you make any changes either of the the packages? If so don't forget to > commit and push to salsa please. You should have push access to > electronics-team, right? > > Also I see the debian/* tags are still missing please don't forget to push > them. > > If you forgot to run gbp-buildpackage with --git-tag it's best to use `gbp > import-dsc` to import the source package you just uploaded and push > that. IIRC this will create the debian/* tag too. > > You can push everything using `gbp push origin` and if that doesn't work > (it fails sometimes for me): > > git push --tags && git push origin master upstream Thanks, --Daniel
Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux
Hi Andrej, On Mon, Jul 24, 2023 at 07:38:13PM +0200, Andrej Shadura wrote: > On Mon, 24 Jul 2023, at 16:16, Daniel Gröber wrote: > > tundra-nat64 is a new userspace implementation of SIIT, NAT64 and > > [CLAT]. It's multithreaded as opposed to tayga so my hope is the > > performance will be much better. > > > > I plan on maintaining tuntra-nat64 myself but I do need a sponsor :) > > As the maintainer of tayga, I’ll be happy to sponsor tundra too :) My cup runneth over on this ITP. You're just a smidge too late, I think me and Paul got this. First come first sponsored I guess? :) Thanks for the offer nonetheless, --Daniel PS: You can expect a crunchy new Tayga PMTU/fragmentation bug within the fortnight if I don't forget :P
